CVE-2026-123022는 AgentScope 2.0.11 이하 버전의 MCP Workspace API에서 command 인자 조작이 운영체제 명령 주입으로 이어지는 취약점입니다. 공격이 원격에서 개시될 수 있고 익스플로잇이 공개돼 사용될 수 있다고 기록돼 있어, 운영 환경에서는 즉시 점검해 볼 대상입니다. 특히 실제 재현 검증에서 HTTP 응답이 오류 또는 시간 초과로 반환됐음에도 AgentScope 호스트에 공격자가 의도한 산출물이 남았다는 점이 확인됐습니다. 오류 응답이 곧 실행 실패를 뜻하지 않는다는 점이 실무적으로 중요합니다.
CVE-2026-123022 개요: 취약점 위치와 공격 개시 조건
CVE-2026-123022는 agentscope-ai AgentScope 2.0.11까지의 버전에 영향을 주는 운영체제 명령 주입 취약점으로 기록돼 있습니다. 기록이 지목하는 발생 지점은 MCP Workspace API를 담당하는 src/agentscope/mcp/_config.py 파일의 subprocess.Popen 호출이며, command 인자의 조작이 운영체제 명령 주입으로 이어진다고 적혀 있습니다. 공격은 원격에서 개시할 수 있다고 명시돼 있고, 익스플로잇이 공개돼 사용될 수 있다고도 밝히고 있습니다.
수정 상태를 보면 stdio MCP 명령용 선택형(opt-in) 허용목록을 추가하는 pull request가 열려 있는 것으로 전해지나, 공식 수정 버전의 존재 여부와 수정안의 수용 여부는 2026년 11월 8일 기준 제공된 근거만으로는 확인되지 않습니다.
먼저 짚어 둘 기본 사실
- 취약점 유형: 운영체제 명령 주입
- 기록상 영향 범위: AgentScope 2.0.11까지
- 발생 지점:
src/agentscope/mcp/_config.py의subprocess.Popen호출과command인자 - 공격 개시 조건: 원격 개시 가능, 익스플로잇 공개
- 수정 상태: 허용목록 pull request 열려 있으나 수용 여부 미확인
기록상 영향 범위(2.0.11 이하)와 실제 검증 범위(v2.0.4, LocalWorkspace)의 구분
이 취약점을 논할 때는 기록상 영향 범위와 실제 재현 검증 범위를 구분해서 시작해야 합니다. 두 범위가 일치하지 않아서, 위험 평가와 대응 우선순위 산정 시 혼동이 생기기 쉽습니다.
| 구분 | 내용 | 근거 |
|---|---|---|
| 기록상 영향 범위 | AgentScope 2.0.11까지 | |
| 실제 검증 버전 | AgentScope v2.0.4 | |
| 검증 운영체제 | Windows 11 | |
| 검증 워크스페이스 | 기본 LocalWorkspace 배포 | |
| 검증 구성 | pip install -e ".[service,storage]", Redis 7 | |
| 에이전트 서비스 | examples/agent_service/main.py가 0.0.0.0:8000에 바인딩 | |
| 공격 개시 조건(기록) | 원격에서 개시 가능 |
연구자는 2026년 7월 8일 위 구성에서 동적으로 취약점을 검증했고, 기록된 성공 기준 세 가지가 모두 통과했다고 합니다. 다만 Windows 11, AgentScope v2.0.4, 기본 LocalWorkspace 구성 외의 배포, 즉 다른 운영체제, 다른 버전, 샌드박스형 백엔드, 검증 버전 이후 릴리스에서의 재현 가능성은 제공된 근거로 입증되지 않았습니다. 기록상 범위가 2.0.11까지라는 사실과 검증이 특정 구성에서 수행됐다는 사실은 별개의 정보입니다.
재현 결과: 오류 응답 뒤에 남는 호스트 실행의 흔적
재현 결과에서 주목할 점은 응답과 실행 결과가 엇갈렸다는 사실입니다. 호출자에게는 HTTP 응답이 오류 또는 시간 초과로 보였지만, AgentScope 호스트에는 의도한 표식 파일이 남았고 그 내용도 기대한 표식 문자열과 일치했습니다. 이 결과는 침해 대응 관점에서 의미가 두 가지입니다. 첫째, 공격 시도의 성공 여부는 API 응답 코드만으로는 판단되지 않습니다. 둘째, 공격자는 응답 수신 없이 실행 결과만 확보하면 되므로 오류 반환을 방어 수단으로 기대하기 어렵습니다.
공개된 재현 수단과 입증되지 않은 영역의 경계
익스플로잇이 공개됐다는 기록과 실제 악용은 다른 문제입니다. 입증 범위와 입증되지 않은 범위를 나누면 다음과 같습니다.
- 입증된 범위: 위 재현 구성에서 명령이 실행되고 의도한 산출물이 호스트에 남았다는 사실
- 입증되지 않은 범위: 샌드박스 이탈, 권한 상승, 지속화, 데이터 유출, 다른 운영체제나 배포 형태에서의 성공, 검증 버전 이후 릴리스에서의 성공, 실제 환경 악용
공개된 재현 수단이 존재한다는 것은 사실이지만, 그것이 모든 배포 형태에서 동일하게 작동하거나 실제 환경에서 이미 악용됐다는 의미는 아닙니다. 반대로 입증되지 않았다는 이유로 방치할 수 있는 성질의 것도 아니며, 재현 수단이 공개된 상태라는 점 자체가 위협 수준을 높이는 요인입니다.
AgentScope 워크스페이스 아키텍처: LocalWorkspace와 샌드박스 백엔드의 노출면 차이
AgentScope 공식 문서는 워크스페이스를 에이전트의 실행 환경으로 정의하고, LocalWorkspace(호스트 파일시스템)를 포함해 7가지 구현을 제공한다고 설명합니다. 아키텍처에 따라 MCP 서버의 실행 위치와 노출면이 달라집니다. 그래서 자체 배포의 워크스페이스 유형 확인이 위험 평가의 출발점이 됩니다.
| 구분 | MCP 서버 실행 위치 | 특징 |
|---|---|---|
| LocalWorkspace | 호스트 파일시스템 기반 | 문서가 제시하는 7가지 워크스페이스 구현 중 하나 |
| 샌드박스형 백엔드(Bubblewrap, Docker, E2B, Daytona, K8s, OpenSandbox) | 격리 환경 내부 | 호스트는 in-workspace 게이트웨이를 통해 접근 |
| 샌드박스형의 MCP 게이트웨이 | 워크스페이스 내부의 FastAPI 프로세스 | 워크스페이스별 베어러 토큰으로 보호되는 단일 인증 엔드포인트 제공, 호스트에서 접근 가능한 네트워크 포트로 노출되지 않음 |
| BubblewrapWorkspace | 격리 환경 내부(예외적 특성) | 호스트 네트워크 네임스페이스를 공유하며 베어러 토큰과 인스턴스 논스 안전장치가 적용됨 |
다만 이 문서는 아키텍처 설명일 뿐, CVE-2026-123022의 영향이 특정 백엔드에서 제한된다는 확인 근거는 아닙니다. 실제 재현은 기본 LocalWorkspace 배포에서 이뤄졌고, 다른 배포 형태에서의 재현 가능성은 입증되지 않았다는 점을 함께 두고 판단할 문제입니다.
지금 확인할 것: 버전, MCP Workspace API 노출 범위, 접근 통제
AgentScope 기반 에이전트 서비스를 운영 중이라면 다음 항목을 우선 확인하십시오.
- 사용 중인 AgentScope 버전이 2.0.11 이하에 해당하는지부터 확인합니다. 기록상 영향 범위에 포함됩니다.
- 워크스페이스가 기본 LocalWorkspace로 배포됐는지 확인합니다. 재현 검증이 이 구성에서 수행됐습니다.
examples/agent_service/main.py와 같은 예시 에이전트 서비스가0.0.0.0:8000에 바인딩돼 외부 접근 가능 상태로 노출돼 있지 않은지 확인합니다. 재현 환경이 바로 이 구성이었습니다.POST /workspace/mcp엔드포인트의 인증과 접근 통제 상태를 점검합니다. 연구자는 이 엔드포인트에 인증된 관리자 접근을 요구해야 한다고 제안했습니다. 다만 재현 환경에서 해당 엔드포인트의 실제 인증 구성 상태는 제공된 근거로 확정할 수 없으므로, 자체 환경에서 직접 확인하는 수밖에 없습니다.- 공식 수정 버전의 존재 여부와 허용목록 pull request의 수용 상태를 AgentScope 공식 채널에서 직접 확인합니다. 현시점 근거로는 미확인 상태입니다.
구조적 완화 논의: stdio MCP 허용목록의 한계와 프로세스 격리
연구자가 제시한 수정 기대는 세 갈래입니다. API 호출자가 임의의 로컬 프로세스 실행을 유발해서는 안 되고, stdio 명령은 사전 승인된 MCP 서버의 서버 측 허용목록이나 레지스트리로 제한해야 하며, POST /workspace/mcp는 인증된 관리자 접근을 요구해야 한다는 것입니다.
열려 있는 pull request는 stdio MCP 명령에 선택형 허용목록을 추가하는 안인데, 이 안은 opt-in 방식이므로 운영자가 설정하기 전까지 기존 배포에 보호 효과를 주지 않으며, 생성된 프로세스를 샌드박스로 격리하지도 않습니다. 허용목록이 수용·적용되더라도 프로세스 격리는 별개의 과제로 남습니다. 대응 계획에는 이 점을 반영해 둬야 합니다. 참고로 타 사례를 다룬 전문 분석에서는 MCP 아키텍처의 보안 문제를 컨텍스트 오염, 검증 없는 권한 상속, 지시 체이닝 등 신뢰 경계 붕괴로 설명한 사례가 있으며, 이는 본 취약점과 동일한 사안은 아니지만 유사한 구조적 문제를 이해하는 참고 자료가 될 수 있습니다.
탐지 관점: MCP API 호출과 예상 밖 호스트 프로세스의 연관 검토
탐지 관점에서 재현 결과가 주는 교훈은 명확합니다. 오류 또는 시간 초과 응답이 반환된 호출이라도 호스트에서 실행이 발생했을 수 있으므로, MCP Workspace API 호출 기록과 호스트에서의 예상 밖 프로세스 생성·파일 생성 시점을 대조하는 연관 분석이 필요합니다. 특히 0.0.0.0에 바인딩된 에이전트 서비스의 로그는 외부 접근 경로 확인의 출발점이 됩니다. 다만 제공된 근거에는 구체적인 탐지용 로그 필드나 침해 지표가 포함돼 있지 않으므로, 시그니처 기반 대응보다는 위 행위 연관 관점의 로그 검토가 현재로서는 실현 가능한 접근입니다.
CVE-2026-123022의 위험성은 원격 개시 가능성과 공개된 익스플로잇, 그리고 오류 응답 뒤에도 실제 호스트 실행이 남는다는 검증 결과에서 나옵니다. 수정 상태가 확정되지 않은 현시점에서는 버전 확인, LocalWorkspace 및 0.0.0.0 바인딩 여부 점검, POST /workspace/mcp 접근 통제 강화가 운영자가 즉시 수행할 수 있는 실무 대응입니다.