MaxKB는 도구가 활성화된 모든 어시스턴트에 셸 도구를 연결했지만, 이에 대한 접근을 전혀 제한하지 않았다

GitHub 조직 1Panel-dev에서 공개한 오픈소스 엔터프라이즈 어시스턴트 플랫폼인 MaxKB는 셸 기능을 갖춘 백엔드가 전달될 때마다 조용히 셸 도구를 추가하는 프레임워크 위에 채팅 에이전트를 구축했으며, MaxKB는 그 도구를 제거하지도 않았고 누구에게도 그 사용을 승인하도록 요청하지도 않았다. 이 결함은 CVE-2026-77521로, GitHub 보안 권고 GHSA-f36j-f34j-h3rx로 2026년 9월 2일 게시되었고 공개 또는 내장 어시스턴트의 경우 CVSS 3.1 기준 10.0점 만점에 10.0점을 받았다. Lasso Security는 이를 발견하고 보고했으며, 채팅 메시지나 어시스턴트가 검색 또는 업로드된 문서를 통해 단순히 수집하는 텍스트만으로도 모델이 명령을 실행하도록 유도할 수 있음을 입증했다. 베어메탈 배포에서는 호스트에서 직접, 공식 컨테이너에서는 연구진이 세미콜론으로 우회할 수 있다고 말하는 래퍼를 통해 가능하다. 인용된 어떤 출처도 이 결함이 실제 환경에서 악용된 사례를 기록하지 않는다. 해당 기록 자체의 심각도 등급, 신뢰도 평가 및 출처 목록은 AI 사고 아카이브에 있으며, 같은 공개 배치에서 나온 인접한 MaxKB 및 에이전트 도구 관련 항목들과 함께 있다.

MaxKB는 검색 증강 어시스턴트를 구축하기 위한 자체 호스팅 제품이다. 운영자는 어시스턴트를 만들고 여기에 도구, Model Context Protocol 서버, 스킬, 하위 애플리케이션 같은 기능을 연결하며, 업로드한 문서나 크롤링한 웹사이트로 구축한 지식 베이스를 연결한 다음, 인증된 콘솔을 통해 또는 공개적으로 임베드 가능한 채팅 위젯으로 어시스턴트를 노출한다. 그 다재다능함이 곧 노출 지점이다. 권고문의 트리거 조건은 특이한 구성이 아니라 일반적인 구성이다. 하나 이상의 기능이 연결된 모든 어시스턴트는 채팅을 영향을 받는 에이전트 경로로 라우팅하지만, 기능이 연결되지 않은 채팅은 그렇지 않다. Lasso의 글은 이 프로젝트를 해당 범주에서 비교적 널리 채택된 프로젝트 중 하나로 설명하며, MaxKB가 일반적으로 멀티테넌트 서비스로 배포된다는 점을 지적한다. 이는 애플리케이션 사용자로 실행되는 명령을 테넌시 모델 내부가 아니라 그 아래에 놓이게 한다.

셸 도구는 제품이 아니라 프레임워크와 함께 제공되었습니다

MaxKB는 LangChain의 deepagents 라이브러리로 이들 에이전트를 구축하며, 프로젝트의 pyproject.toml에서 취약한 태그와 현재 태그 모두에서 버전 0.6.11로 고정되어 있습니다. apps/application/flow/tools.py의 v2.10.3-lts 태그 467번째 줄에서 프로젝트는 backend를 SandboxShellBackend로 설정하여 create_deep_agent를 호출하는데, 이는 호스트에서 명령을 실행하는 MaxKB 하위 클래스입니다. 권고에 따르면 deepagents는 이러한 방식으로 셸 백엔드가 전달될 때마다 execute, ls, read_file, write_file, edit_file, glob 및 grep 도구 세트를 자동으로 주입합니다. 이들은 운영자 자체 도구, MCP 도구 및 스킬 도구만 포함하는 tools=list 인수의 일부가 아닙니다. 이들은 인터페이스에서 또는 구성을 통해 제거할 수 없습니다.

MaxKB도 excluded_tools를 전달하지 않는데, 이는 해당 도구들을 제거했을 라이브러리 인수입니다. 권고문은 그것이 해결책이면서도 왜 중요한지에 대해 세심하게 다룹니다. excluded_tools는 "모델이 전달받는 내용에서 도구를 제거할 뿐, 실행기에서는 제거하지 않습니다". 모델이 인지하지 못하는 도구와 실행될 수 없는 도구 사이의 구분이 바로 이 버그의 전체를 축소해 놓은 것입니다.

세 가지 도구를 나열하고 네 번째 도구는 빠뜨리는 게이트

같은 호출에서의 휴먼 인 더 루프 제어는 한 줄이며, 세 가지 작업을 열거합니다: interrupt_on={"write_file": False, "read_file": False, "edit_file": False}. 파일 쓰기, 파일 읽기, 파일 편집이 명명됩니다. 명령 실행은 사전의 키로 전혀 존재하지 않습니다. 권고문의 해석에 따르면, 이는 execute에 대해 승인을 구하지 않는다는 뜻입니다. 세 가지 파일 시스템 작업은 명명되어 있고 명시적으로 중단하지 않도록 설정되어 있으며, 셸 도구는 전혀 명명되지 않았습니다.

종합하면 경로는 다음과 같습니다. 신뢰할 수 없는 텍스트가 모델에 도달하고, 모델이 execute를 호출하며, 명령이 실행됩니다. 이 권고문은 신뢰할 수 없는 텍스트가 유입되는 두 가지 방식을 제시합니다. 직접적인 방식은 채팅입니다. 공개 또는 임베디드 위젯, 또는 다른 테넌트의 대화입니다. 간접적인 방식은 어시스턴트가 수집하는 콘텐츠입니다. RAG 문서, 업로드된 파일, 또는 플랫폼이 지식 베이스로 크롤링하는 웹 페이지입니다. Lasso의 게시물은 두 번째 경로를 구체화하며, "모델 앞에 텍스트를 놓을 수 있는 사람의 집합은 모델과 채팅할 수 있는 사람의 집합보다 크다"라고 지적합니다.

베어메탈 설치에서는 해당 명령은 그저 명령일 뿐입니다.

MaxKB가 격리와 관련해 수행하는 일은 모두 apps/application/flow/backend/sandbox_shell.py에서 일어나며, v2.10.3-lts에서는 기본값에서 시작합니다. 9행은 _enable_sandbox = bool(int(CONFIG.get("SANDBOX", 0)))이며, SANDBOX는 apps/maxkb/conf.py의 Config.defaults에 나타나지 않습니다. 명시적인 MAXKB_SANDBOX 설정이 없으면 값은 0이고, 65행의 래퍼 분기는 건너뛰며, execute는 서비스를 실행하는 사용자로서 — 권고문의 표현대로 서비스가 root로 실행되면 root로서 — 호스트에서 직접 shell=True로 subprocess.run에 도달합니다.

그것이 연구자들이 호스트 개념 증명에 사용한 구성이다. 그들은 MAXKB_SANDBOX를 설정하지 않은 채 소스에서 MaxKB의 실제 코드를 실행했고, 도구 하나를 연결한 어시스턴트를 만든 뒤 단일 채팅 메시지로 시스템 정보 명령을 실행하도록 요청했다. execute 도구가 작동해 파일을 작성했으며, 그 내용은 호스트 자체의 uname, id, sw_vers 출력이었다. 권고문에 따르면 이 출력은 어떤 컨테이너 내부에도 없음이 확인되었다. Lasso는 또한 이를 막은 것의 한계도 기록한다. 노골적인 이름의 증명 파일은 모델이 거부했지만, 무해한 운영상 표현은 거부하지 않았다. 그들의 표현대로 모델 정렬은 "부분적인 제동 장치일 뿐, 통제 수단은 아니다"이다.

공식 이미지에서는 샌드박스가 실행되었음에도 여전히 누출되었습니다.

공식 컨테이너는 베이스 이미지의 installer/Dockerfile-base 48번째 줄에서 MAXKB_SANDBOX=1을 설정하므로, 그곳에서는 래퍼가 활성화되어 있습니다. 그리고 래퍼가 두 번째 결함입니다. 이 래퍼는 하나의 문자열을 만들었습니다. env -i LD_PRELOAD=/opt/maxkb-app/sandbox/lib/sandbox.so 뒤에 gosu sandbox를 붙이고, 그다음 모델이 제공한 명령을 붙여 root로 실행 중인 셸에 넘겼습니다. 명령이 텍스트로 보간되었기 때문에 그중 첫 번째 토큰만 gosu 아래에 있었습니다. 모델 출력에 있는 세미콜론, 파이프, 리다이렉트 또는 명령 치환은 샌드박스가 보기도 전에 외부 root 셸에 의해 평가되었습니다.

Lasso의 write-up은 그것의 실제 동작 형태를 보여준다: env -i LD_PRELOAD=... PATH="$PATH" gosu sandbox ls; whoami; id라는 페이로드인데, 여기서 ls는 격리되고 whoami는 격리되지 않으며 그 뒤의 모든 것은 자유롭게 실행된다. 테스트에서 연구자들은 샌드박스된 내부 명령이 차단된 상태에서 리디렉션으로 root 소유 파일을 작성했다. 설상가상으로 installer/Dockerfile과 installer/Dockerfile-base 어디에도 USER 지시문이 없어서 애플리케이션 이미지는 UID 0으로 실행된다 — 권고문은 런타임에 root임을 확인했다고 보고한다. 따라서 컨테이너는 그와 무관하게 명령을 실행했고, 샌드박스는 어떤 명령이 겉으로만 저권한 사용자에게 귀속되는지를 결정했을 뿐이다.

Lasso가 설명하는 전체 공격 흐름은 대상에 전혀 접근할 필요가 없습니다. 공격자는 웹 페이지에 명령을 넣고, 피해자의 에이전트가 이를 지식 베이스로 크롤링하기를 기다린 뒤, 피해자가 평범한 질문을 합니다. 답변은 정확하고 정상적으로 돌아오지만, 주입된 curl은 이미 공격자의 서버에서 실행된 상태입니다. 권고문은 연구진이 자체 배포 환경만 테스트했으며 타사 또는 호스팅된 MaxKB 인스턴스는 테스트하지 않았다고 언급합니다.

출처가 입증하는 것과 그저 측정되지 않은 것

메커니즘, 두 가지 배포 모드, 크레딧, 수정 릴리스는 네 문서에서 일치한다. GitHub 권고, 2026년 9월 21일 게시된 NVD 기록, 2026년 9월 10일 Lasso 자체 기술 문서, 그리고 2026년 9월 22일 GBHackers 보도가 그것이며, GBHackers 보도는 이 CVE에 대해 발견된 유일한 독립 언론 보도이다. 어떤 출처도 이 발견의 어느 부분에도 이의를 제기하지 않으며, 아카이브는 해당 항목을 최고 신뢰 등급에서 이견 없음으로 기록한다.

출처에는 노출을 측정한 어떤 수치도 없다. MaxKB 배포 수 집계도 없고, 인터넷에 노출되었거나 내장된 어시스턴트 수 집계도 없으며, 스캔 결과도, 텔레메트리도, 이름이 밝혀진 피해자도 없다. 기록상 이 결함이 누군가를 대상으로 사용된 정황은 없으며, CISA 자체의 악용 평가도 이와 일치한다. 2026년 9월 22일 NVD 레코드에 첨부된 SSVC 블록은 악용을 'poc'로, 자동화 가능성을 'yes'로, 기술적 영향을 'total'로 평가한다. FIRST의 EPSS 모델은 2026년 10월 27일 기준 향후 30일 내 악용 확률을 1.05퍼센트, 64백분위수로 산정했고, 해당 CVE는 2026년 10월 27일자 CISA Known Exploited Vulnerabilities 목록에 나타나지 않는다. 아카이브 자체의 등급도 같은 증거를 반영한다: 심각도 높음, 실제 피해 없음.

10.0에는 그 적용 범위를 분명히 밝혀 둘 만한 이유가 있습니다. 이 점수는 공개 또는 내장형 어시스턴트 사례에 대한 점수로, 여기서 CVSS 벡터는 AV:N/AC:L/PR:N/UI:N/S:C로 표시됩니다. 즉 네트워크 도달 가능, 권한 없음, 사용자 상호작용 없음이며, 어시스턴트 내부의 명령이 호스트 운영 체제로 넘어가기 때문에 범위 변경이 있습니다. 이 점수는 CNA의 점수이며, 여기서 CNA는 GitHub의 권고 프로그램으로, CVE 레코드의 소스 식별자가 가리키는 곳이기도 합니다. NVD는 동일한 벡터를 보조 지표로 싣고 있으며, 2026년 10월 28일 기준 해당 항목을 "Deferred" 상태로 표시하는데, 이는 NVD가 자체 분석이 아니라 할당자의 분석을 게시했음을 의미합니다.

패치는 보안 권고문보다 한 달 앞서 배포되었습니다

연대기는 발행 시점에서 거꾸로 거슬러 올라가며, 이는 기록에서 가장 직관적이지 않은 부분이다. Lasso는 2026년 7월 8일 GitHub의 권고 채널을 통해 이 결함을 비공개로 보고했다. MaxKB는 다음 날 답변하며 보고 범위를 공식 이미지로 한정하고 컨테이너 개념 증명을 요청했고, 연구진은 7월 10일에 그 개념 증명과 샌드박스 우회를 제공했다. 수정 커밋 594f50f2는 보고 하루 뒤인 7월 9일에 반영되었으며, sandbox_shell.py를 재작성하여 모델의 명령 문자열을 먼저 구문 분석한 뒤 gosu 접두사를 첫 번째 단순 명령에만이 아니라 모든 단순 명령에 적용하고, 각 인자 목록을 다시 인용하여 치환이 부모 셸로 빠져나갈 수 없도록 했다. Lasso의 분석 글은 이 변경을 gosu 접두사를 "첫 번째 명령에만이 아니라 모든 단순 명령에" 적용하는 것으로 설명한다.

이를 포함한 릴리스인 v2.10.5-lts는 2026년 8월 6일에 게시되었다. GitHub 권고문은 9월 2일에 올라왔고, NVD는 9월 21일에 CVE를 게시했으며, CISA의 SSVC 블록이 추가되고 GBHackers가 보도한 것은 9월 22일이었다. 그리고 Lasso가 직접 작성한 글은 9월 10일에 나왔는데, 이는 해당 순서의 중간이었지 시작이 아니었다. 권고 피드 대신 릴리스 태그를 추적하던 운영자는 경고보다 약 4주 전에 패치를 갖고 있었던 셈이다.

버전 경계는 권고문이 쏟은 주의보다 더 주목할 가치가 있습니다. 두 주요 출처가 서로 다르고, 저장소가 이 문제를 확정하기 때문입니다. 권고문 양식 필드는 영향을 받는 버전을 “<= 2.10.3-lts”로 기록하며, 이는 2.10.3-lts에서 검증되었고 취약 경로가 이런 방식으로 에이전트를 빌드하는 모든 버전에 “아마도” 영향을 미친다는 주석을 달고 있습니다. Lasso 자체 설명 문서는 영향을 받는 범위를 “<= 2.10.4-lts”로 명시합니다. 태그는 더 넓은 범위를 뒷받침합니다. 2026년 7월 16일에 릴리스된 v2.10.4-lts에는 v2.10.3-lts와 동일한 75줄짜리 sandbox_shell.py가 포함되어 있으며, 다시 작성된 311줄짜리 파일은 v2.10.5-lts에서 처음 등장합니다. 권고문의 범위만 읽은 2.10.4-lts 운영자는 자신이 그 범위 밖에 있다고 결론지었을 것입니다. 그러나 그들은 범위 밖이 아니었습니다.

이 수정이 하지 않은 것

2.10.5-lts가 수정하는 것은 래퍼입니다. 더 이상 root 아래에서 하나의 셸 문자열을 구성하지 않습니다. 그것이 하지 않는 일은 도구 자체에 관해서는 아무것도 하지 않는다는 점입니다. 2026년 10월 22일에 공개된 태그 v2.10.8-lts의 저장소를 직접 읽어 보면, 에이전트는 여전히 backend=SandboxShellBackend로 구성되며 interrupt_on에는 여전히 정확히 세 개의 키 — write_file, read_file, edit_file — 가 있고 execute는 없습니다. 권고문의 처음 두 가지 개선 제안, 즉 기본적으로 비실행 백엔드 위에 구축하고 승인 맵에 "execute": True를 추가하라는 제안은 해당 릴리스에 존재하지 않습니다.

fail-closed 권고는 나중에 v2.10.7-lts에 반영되었으며, 가장 취약했던 배포 모드에 중요하다. 2026년 10월 15일에 게시된 이 변경은 sandbox_shell.py의 해당 줄을 CONFIG.get("SANDBOX", 0)에서 CONFIG.get("SANDBOX", 1)로 바꾼다. 변수를 한 번도 설정하지 않은 소스 또는 베어메탈 설치는 이제 래퍼가 기본적으로 꺼져 있는 대신 켜져 있으며, 이는 좁은 의미에서 "비컨테이너 배포에서 fail closed" 권고에 해당한다. 권고문은 같은 항목 아래에서 그 이상을 요구했다. 즉 실행 기능이 있는 흐름이 샌드박스 런타임을 사용할 수 없을 때 시작을 거부할 것, 그리고 별도로 래퍼가 루트 셸용 명령 문자열을 절대 구성하지 않을 것을 요구했다. 컨테이너 측에서는 권고가 아니라 사실이다. v2.10.8-lts 태그에서 installer/Dockerfile도 installer/Dockerfile-base도 USER 지시문을 포함하지 않으므로 애플리케이션 이미지는 여전히 루트로 시작한다.

종합해 보면, 2026년 10월 28일 기준 기록의 상태는 다음과 같다. 취약점의 후반부, 즉 세미콜론이 빠져나온 샌드박스는 닫혔고, 호스트 배포에서의 fail-open 기본값도 닫혔다. 전반부, 즉 백엔드 객체와 함께 도착하지만 승인 맵의 키가 아닌 execute 도구는 여전히 MaxKB가 도구 지원 어시스턴트를 구성하는 방식이다. 연구진 자신의 완화 조언은 좁은 범위였다. 2.10.5-lts 이상으로 업그레이드하고, 샌드박스를 활성화한 상태로 Docker 버전을 실행하라는 것이었다. GBHackers는 같은 지침과 함께 관리자를 위한 더 광범위한 목록을 전했다. 코드 실행이 명시적으로 필요하지 않은 한 셸 실행이 가능한 에이전트 백엔드를 비활성화하고, 모든 execute 작업 전에 사람의 승인을 요구하고, 컨테이너를 비루트로 실행하고, 크롤링한 페이지와 RAG 문서 및 업로드를 신뢰할 수 없는 입력으로 취급하라는 것이다.

같은 9월 배치의 다른 MaxKB 레코드

이번 배치에서 아카이브의 두 번째 MaxKB 항목은 결말이 더 나쁜 다른 버그입니다. 2026년 9월 21일 NVD에도 게시된 CVE-2026-77516은 명령 주입이 아니라 권한 우회입니다. 버전 2.0.0부터 2.9.2까지, 최하위 역할의 워크스페이스 구성원이 WorkspaceUserResourcePermission을 통해 특정 도구에 대한 접근을 명시적으로 거부당해도 tool_ids, skill_tool_ids 또는 mcp_tool_ids를 통해 해당 도구의 식별자를 바인딩하고 에이전트 또는 워크플로 디스패치 경로를 통해 실행할 수 있었습니다. 디스패치 경로는 전용 도구 라우트가 적용하는 도구별 권한 부여를 다시 적용하지 않으며, 도구 실행은 서버 측 init_params를 복호화하므로 호출자는 자신이 거부당한 도구가 지닌 자격 증명을 받게 됩니다. 점수는 5.4이며, NVD 설명은 CVE-2026-77521이 담을 필요가 없는 문장으로 끝납니다: "이 검토 시점에 사용 가능한 수정 버전은 없습니다."

이 두 취약점을 분류하는 사람에게는 대비가 유용한 부분이다. 10.0점을 받은 결함은 하루 안에 수정 사항이 커밋되었고 공개되기 한 달 전에 릴리스되었다. 5.4점을 받은 결함은 해당 CVE 시점에 공개된 수정 버전이 없었다.

실질적으로 남아 있는 미해결 부분은 점수가 시사하는 것보다 작고, 패치 노트가 암시하는 것보다 크다. 발견 자체는 논란이 없으며, 그 메커니즘은 이를 발견한 팀에 의해 두 배포 모드 모두에서 처음부터 끝까지 검증되었다. 노출 규모는 전혀 측정되지 않았다 — MaxKB 어시스턴트 중 얼마나 많은 것이 도구를 탑재하고 있는지, 그중 얼마나 많은 것이 신뢰할 수 없는 주체에게 접근 가능한지, 또는 얼마나 많은 것이 샌드박스가 없는 호스트에서 실행되는지는 아무도 공개하지 않았다 — 따라서 이 결함의 실제 영향은 인용된 어떤 출처도 집계하지 않는 배포 관행의 함수다. 그리고 점수를 최대로 끌어올린 설계의 일부는 현재 릴리스에도 여전히 남아 있다: 명령을 실행하는 기능이 기본적으로 연결되어 있으면서, 사람에게 먼저 승인을 묻는 맵에는 빠져 있다.