MaxKB: 에이전트 디스패치 경로에서는 도구 사용이 거부된 사용자도 여전히 해당 도구를 호출하고 자격 증명을 읽을 수 있습니다.

1Panel-dev가 유지 관리하는 오픈소스 엔터프라이즈 AI 어시스턴트인 MaxKB는 사용자별·도구별 권한 목록을 제공하여, 관리자가 워크스페이스 구성원에게 한 도구는 허용하고 다른 도구는 거부할 수 있게 한다. 2026년 9월 2일 공개된 보안 권고에 따르면, 해당 거부 조치는 도구 자체의 라우트에서는 적용되었지만 에이전트나 워크플로가 같은 도구를 호출하는 경로에서는 적용되지 않았다. 최하위 역할을 가진 워크스페이스 구성원은 워크플로를 구성할 때 거부된 도구의 식별자를 지정하고 해당 워크플로를 실행함으로써, 도구의 출력뿐 아니라 MaxKB가 그 도구를 실행하기 위해 서버 측에서 복호화하는 자격 증명까지 받을 수 있었다. 2.0.0부터 2.9.2까지의 버전이 영향을 받으며, 권고에는 패치된 버전이 명시되지 않았다. 이 기록, 즉 MaxKB 도구 디스패치 인가 우회는 OrcaRouter AI Incident Archive, 이 아카이브에는 전체 기록 세트와 이 사건의 인접 항목이 포함되어 있다.

이 사례를 주의 깊게 읽을 가치가 있는 이유는 점수가 아니다. 제품이 이미 올바른 검사를 갖추고 있었고, 그 검사를 명백한 문에 적용했으며, 동일한 기능으로 이어지는 두 번째 문은 감시하지 않은 채 남겨두었다는 점이다. 보안 권고문 GHSA-383v-fx78-pphm은 이를 발견한 연구자가 작성해 2026년 9월 2일 07:43 UTC에 GitHub의 권고 시스템을 통해 게시했으며, Matteo Panzeri(@matte1782)의 공로를 인정했다. CVE 기록 CVE-2026-77516은 2026년 9월 21일에 뒤따랐다.

권고안이 규정하는 사항

MaxKB의 도구별 모델은 WorkspaceUserResourcePermission이며, 권고문에서 요청 시점에 확인되는 기본 거부 방식의 허용 목록으로 설명됩니다. 전용 도구 라우트가 이를 강제합니다. 권고문은 apps/tools/views/tool.py에서의 강제 적용을 나열하며, 여기서 Operate.put, Operate.get, Debug.post, Export.get 및 Delete는 각각 호출자의 워크스페이스 도구 권한에 대한 보기 권한 검사를 수행합니다. Debug.post는 단순히 도구를 실행하는 것에 가장 가까운 라우트이며, 게이트로 보호됩니다.

에이전트 및 워크플로 디스패치 경로는 해당 검사를 다시 적용하지 않습니다. 권고문은 이 검사가 누락되는 세 군데 지점을 추적합니다. apps/application/serializers/application.py에서 애플리케이션 직렬화기는 tool_ids, skill_tool_ids 및 mcp_tool_ids를 요청 입력으로부터 도구별 권한 부여 없이 그대로 바인딩합니다. 그리고 권고문은 동일한 파일에서 그 비대칭성이 드러난다고 지적하는데, knowledge_id_list는 몇 줄 아래에서 사용자가 접근할 수 있는 지식 베이스에 대해 검증되는 반면 도구는 그렇지 않기 때문입니다. apps/common/utils/shared_resource_auth.py에서 filter_authorized_ids는 호출자 자신의 워크스페이스에 있는 모든 도구를 무조건 통과시키며, 이 함수가 의존하는 교차 워크스페이스 게이트는 커뮤니티 에디션에는 존재하지 않는 엔터프라이즈 전용 훅이고, WorkspaceUserResourcePermission을 참조하지도 않습니다. 그리고 싱크 지점에서 apps/application/flow/step_node/tool_lib_node/impl/base_tool_lib_node.py는 도구에 저장된 코드를 실행하는데, 이때 해당 init_params가 rsa_long_decrypt에 의해 애플리케이션의 ID로 복호화되며 도구별 권한 부여 확인은 전혀 없습니다

권고문은 이 결과를 혼동된 대리인 실행(confused-deputy execution)이라고 부릅니다: 워크플로 디스패치는 동일한 호출자가 도구 자체의 경로에서는 거부되는 도구와 그 저장된 비밀을 실행합니다. 자격 증명 노출은 일반적인 무단 도구 사용을 넘어서는 부분입니다. 도구의 init_params는 저장 시 RSA로 암호화되고 실행 시에만 서버 측에서 복호화되므로, 해당 실행을 트리거한 호출자는 자신이 보유한 적도 없고 제공할 수도 없었던 값을 받게 됩니다.

연구자 자신의 수치로 본 입증

권고문은 공식 올인원 이미지인 1panel/maxkb:v2.9.2에서 실행한 v2.9.2의 동적 확인을 보고합니다. 구성은 워크스페이스 하나, 관리자 한 명, 그리고 USER 역할을 가진 두 번째 구성원 한 명이었습니다. 관리자는 Tool A와 Tool B를 생성하고, Tool B의 init_params에 새로운 임의 시크릿을 넣었으며, 실행 시 해당 시크릿을 반환하도록 Tool B의 본문을 작성했습니다. 그런 다음 구성원에게는 Tool A에 대해서만 도구별 권한이 부여되었고, 권고문에 따르면 실행 후 데이터베이스에서 Tool B의 권한 미부여 상태가 다시 확인되었습니다.

테스트의 거부된 절반은 제품이 약속한 결과를 반환했습니다. 멤버로서 Tool B의 디버그 라우트는 403을 반환했고, 업데이트 라우트는 403, 내보내기 라우트는 403을 반환했으며, 권한이 부여된 Tool A는 정상 동작 확인용으로 200을 반환했습니다. 그다음 우회 절반은 도구 라이브러리 노드를 통해 Tool B를 워크플로 애플리케이션에 바인딩했으며 — 바인딩은 HTTP 200으로 수락되었고 도구별 검사는 없었습니다 — 워크플로를 실행하자 도구 이름, 센티널 시크릿, 키 목록 ["api_key"]을 포함한 본문과 함께 HTTP 200을 반환했습니다.

권고문에 따르면 해당 비밀은 세 계층에서 드러났습니다: 워크플로 API 응답, 상태가 SUCCESS인 도구 실행 기록, 그리고 Tool B의 init_params가 344바이트 RSA 암호문으로 저장된 데이터베이스 행입니다 — 연구자는 이를 근거로 해당 값이 호출자가 제공한 것이 아니라 애플리케이션 아이덴티티로 서버 측에서 복호화되었다고 주장합니다. 도구의 실행 경로에서 거부당한 동일 구성원이 해당 도구를 워크플로에 바인딩하여 복호화된 비밀을 획득했습니다.

한 점수는 공개되었고, 더 높은 점수는 주장되고 있다

CVE-2026-77516에 부여된 점수는 CVSS 3.1 5.4, 중간(Medium)이며, 벡터는 AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N입니다. NVD 기록에 따르면 해당 점수는 NVD 자체 분석이 아니라 GitHub의 권고 피드에서 제공된 것이며, 항목 상태는 Deferred로, NVD가 이를 보강하지 않았음을 의미합니다. 아카이브 자체 분류는 공개된 점수를 따릅니다: 중간 심각도, 기록된 실제 피해 없음.

권고문 자체의 영향 섹션은 더 높은 점수를 주장한다. 이는 기밀성 영향도를 높음으로 끌어올리는 벡터에서 심각도 7.1, High라고 밝히며, 디스패치된 도구가 애플리케이션 ID로 권한 있는 쓰기를 수행할 때 그 수치가 8.1로 올라간다고 말한다. 이는 자격 증명 노출을 어떻게 계산할지에 대한 이견이지, 우회가 존재하는지에 대한 이견이 아니다. 같은 문서가 결함을 입증하면서 동시에 그것이 과소평가되고 있다고 주장하는 셈이다. 공개 기록 어디에도 어느 수치가 맞는지 판가름하는 내용은 없으며, 아카이브의 중간 등급은 권고문의 주장이 아니라 공개된 CVE 점수를 따른다.

추가 평가 두 건이 기록에 남아 있다. 2026년 9월 28일 NVD 항목에 추가된 CISA의 SSVC 결정 지점은 악용을 "poc"로, 자동화 가능을 "no"로, 기술적 영향을 "partial"로 기록한다 — "poc" 값은 개념 증명이 존재함을 반영하며, 실제로 권고문 자체에 존재한다. 이는 실제 환경에서의 악용 발견이 아니다. FIRST의 EPSS 모델은 2026년 10월 27일자 추정에서 향후 30일 내 악용 확률을 0.242%, 15.2번째 백분위수로 산정했다.

권고보다 앞선 수정이며, 영향을 받는 범위 내에는 없습니다.

권고문의 버전 표에는 영향을 받는 버전이 2.0.0부터 2.9.2까지로 나와 있고, 패치된 버전은 없으며, 본문에는 검토 시점 기준으로 수정된 버전이 제공되지 않는다고 되어 있습니다. 또한 태그가 지정된 릴리스에서 수정 사항이 나오면 CVE가 이를 기준으로 삼을 수 있다고 덧붙입니다. 공급업체의 저장소는 약간 다른 이야기를 하며, 그 차이는 무엇을 실행할지 결정하는 누구에게나 중요합니다.

MaxKB 저장소에서 디스패치 경로를 차단하는 함수인 validate_bound_tool_permissions와 get_authorized_tool_ids는 apps/application/serializers/application.py에 있으며, v2.9.2 태그와 v2.10.2-lts, v2.10.3-lts, v2.10.4-lts에는 없고 v2.10.5-lts부터 존재합니다. 해당 릴리스는 보안 권고보다 4주 전인 2026년 8월 6일에 게시되었습니다. 같은 태그는 WorkspaceUserResourcePermission을 활용하여 base_tool_lib_node.py에 사용자별 도구 검사를 추가하고, shared_resource_auth.py에 사용자 인식 필터를 추가합니다. 즉, 이는 나중에 보안 권고가 권장하는 세 가지 교정 조치를 개략적으로 구현한 것입니다.

그 연관성을 공개적으로 밝힌 사람은 아무도 없다. v2.10.5-lts 릴리스 노트는 도구 권한 수정을 언급하지 않으며, 서로 무관한 보안 항목 네 건과 기능 및 버그 작업 묶음을 나열한다. 권고문은 2.10.5를 명시하지 않고, 영향을 받는 범위는 2.9 계열의 마지막 릴리스인 2.9.2에서 그대로 끝난다. 릴리스 이력에는 권고문 이후의 2.9.x 패치가 없으므로, 2.9.2에 배포한 경우 해당 계열 안에는 수정된 빌드가 없다. 현재 릴리스는 2026년 10월 22일에 게시된 v2.10.8-lts이며, 그 노트에는 커뮤니티 에디션의 디스패치 경로에 관한 어떤 내용이 아니라 공유 도구 권한 부여에 대한 X-Pack 수정 사항이 설명되어 있다.

무엇이 확립되지 않았는가

이번 시연과 구분해서 볼 만한 세 가지가 있다. 첫째, 해당 우회 기법이 누군가를 대상으로 사용되었다는 공개 보고는 없다. 기록은 조사된 침해가 아니라 발견된 취약점이다. 피해자도, 귀속된 행위자도, 피해도 없으며, 권고문의 개념 증명은 연구자가 통제된 작업 공간에서 실행한 것이다. 둘째, 어떤 언론 기관, 규제 기관 또는 두 번째 연구 팀도 이 결함을 분석한 것으로 보이지 않는다. 존재하는 보도는 취약점 데이터베이스와 집계 사이트들, 그중에서도 VulDB, Rapid7의 데이터베이스, Armis, SOCRadar, openCVE 등에 국한되어 있으며, 이들은 CVE를 나열하고 권고문의 설명을 게재할 뿐, 어느 곳도 코드에 대한 독립적인 평가를 제공하지 않는다. 따라서 여기서 설명된 메커니즘은 하나의 권고문과 공급업체 자체의 소스 코드에 기반한다. 셋째, 영향을 받는 범위에 속하는 MaxKB 배포가 몇 개인지에 대한 수치는 존재하지 않으며, 공급업체나 연구자 모두 이를 발표하지 않았다.

영향을 받는 대상은 좁지만 그 수를 세는 일이 사소하지는 않습니다. 즉, 2.0.0부터 2.9.2까지의 셀프 호스팅 커뮤니티 에디션 MaxKB 설치 중 워크스페이스 구성원이 둘 이상이고, 관리자가 자격 증명을 가진 도구를 도구별 권한으로 차단해 둔 경우입니다. 이 결함은 원격 코드 실행이 아니며 유효한 저권한 계정이 필요합니다. 그래서 공격 경로보다 기밀성 영향이 점수를 좌우합니다. 공격자가 얻는 것은 차단된 도구가 보유한 것, 즉 API 키, 토큰, 그리고 그것들이 잠금 해제하는 모든 것에 의해 제한됩니다. 이는 또한 권고문 작성자들이 그 영향이 낮은 기밀성 등급이 시사하는 것보다 크다고 주장하는 이유이기도 합니다.

운영자가 할 수 있는 일

이 권고의 해결 조치는 운영자가 아니라 유지관리자를 대상으로 하며, 그 세 단계는 v2.10.5-lts에 등장한 코드에 대응합니다. 즉, 도구 라이브러리 및 도구 노드 구현에서 도구를 실행하기 전에 도구별 권한 부여를 적용하고, 모든 바인딩된 tool_ids, skill_tool_ids 및 mcp_tool_ids를 knowledge_id_list가 이미 그러하듯이 바인딩 시점에 검증하며, filter_authorized_ids가 워크스페이스 멤버십만이 아니라 도구별 권한 부여를 참조하도록 만드는 것입니다.

영향을 받는 빌드를 실행 중인 팀이라면, 권고문 자체의 설명에서 도출되는 실질적인 단계는 다음과 같습니다.

• 영향을 받는 배포에서 도구의 init_params에 저장된 모든 비밀 정보는 최하위 역할을 포함한 모든 워크스페이스 구성원이 접근할 수 있는 것으로 간주하고, 도구별 거부가 해당 정보를 보호했다고 가정하지 말고 해당 자격 증명을 교체하십시오.

• 워크스페이스 멤버십을 감사하세요. 이 우회는 워크스페이스 내 인증된 계정이 필요하므로, 휴면 상태이거나 신뢰할 수 없는 멤버를 제거하면 코드를 패치할 수 없는 경우에도 노출 위험이 줄어듭니다.

• 자격 증명을 포함하는 도구를 어떤 워크플로와 에이전트가 바인딩하는지 검토하세요. 권고안에서는 바로 그 바인딩 단계가 도구별 점검 없이 수용된다고 명시하기 때문입니다.

• 업그레이드하는 경우, 사용자별 검사가 v2.10.5-lts부터 리포지토리에 나타나며, 권고문에서 어떤 릴리스도 수정 버전으로 지정되지 않았다는 점에 유의하십시오 — 업그레이드에 의존하는 운영자는 벤더의 패치 성명이 아니라 태그된 소스에 의존하는 것입니다.

이 모든 것이 그 결함을 극적으로 만드는 것은 아니다. 그것은 특정하고 교훈적인 방식으로 그 결함을 평범하게 만든다. 권한 부여 모델은 올바르게 설계되었고, 올바르게 문서화되었으며, 누군가 게이트를 걸어 두는 것을 기억한 라우트에서만 강제되었다. 디스패치 경로는 워크플로가 무엇을 할 수 있어야 하는지를 생각한 사람들이 작성한 것이지, 누가 요청하고 있는지를 생각한 사람들이 작성한 것이 아니다. 그리고 에이전트 플랫폼에서는 실제로 대부분의 요청이 그 경로를 통해 이뤄진다.

이 기록의 교훈은 수치적이라기보다 구조적이다. 리소스별 권한은 가장 보호가 약한 진입점만큼만 강력하며, 에이전트 플랫폼은 진입점을 빠르게 축적한다. 디버그 경로, 내보내기 경로, 워크플로 노드, 채팅 트리거처럼. MaxKB에는 권한 부여 목록과 검사가 있었지만, 2.0부터 2.9까지의 라인에서 그것에 없었던 것은 모든 문 앞에서 같은 질문을 던지는 습관이었다.