AgentScope의 MCP Workspace API를 열어 두고 운영하는 배포라면, 이번 건은 버전 문자열 하나로 답이 갈리는 종류의 문제가 아니다. 같은 버전이라도 그 API에 누구의 자격으로 도달할 수 있는지, 그리고 오류로 보이는 응답 뒤에 호스트에서 무엇이 실행됐는지를 함께 봐야 한다.
개요
CVE-2026-123022는 agentscope-ai AgentScope 2.0.11까지의 버전에 영향을 받는 것으로 기록된 운영체제 명령 주입 취약점이다. 기록이 지목하는 지점은 MCP Workspace API를 담당하는 src/agentscope/mcp/_config.py 파일의 subprocess.Popen 호출이며, command 인자의 조작이 운영체제 명령 주입으로 이어진다고 적혀 있다. 공격은 원격에서 개시할 수 있다고도 명시돼 있다.
CVE 기록은 익스플로잇이 공개돼 사용될 수 있다고 밝히고, 수정을 위한 pull request는 아직 수용을 기다리는 상태라고 전한다. 다만 공식 수정 버전과 수정안의 수용 여부는 제공된 근거만으로는 확인되지 않는다. 재현 수단이 이미 공개된 상태로 다뤄야 한다는 뜻이지, 침해가 이미 발생했다고 보기는 어렵다.
영향 범위
범위는 기록상 범위와 검증된 범위로 나눠 읽는다.
- 취약점 기록이 지목하는 범위: AgentScope 2.0.11까지.
- 실제로 검증된 범위: Windows 11 호스트에서 기본 LocalWorkspace 배포로 동작하는 AgentScope v2.0.4. 연구자는
pip install -e ".[service,storage]"구성과 Redis 7, 예시 에이전트 서비스examples/agent_service/main.py가0.0.0.0:8000에 바인딩된 환경에서 재현했다.
제공된 인용이 확인하는 재현은 위 구성에서 이뤄진 것이다. 재현에 쓰인 예시 서비스가 0.0.0.0:8000에 바인딩돼 있었다는 기록은, 그 구성에서 서비스가 여러 네트워크 인터페이스에 열려 있었음을 나타내는 주소 표기로 읽힌다. 반대로 이 구성에서 확인된 결과를 근거로 그 밖의 모든 배포에서 같은 공격 경로가 성립한다고 옮길 수도 없다. 어느 방향으로든 결론을 확정하려면 각 배포의 버전과 API 노출 및 접근 통제 상태를 따로 확인해야 하며, 여기가 현재 근거의 한계다.
그래서 점검은 버전 문자열 확인에서 끝나면 안 된다. 같은 버전이라도 MCP Workspace API가 어디에 노출돼 있고 어떤 접근 통제를 지나 도달할 수 있는지가 실제 노출면을 결정하기 때문이다. 사용 중인 AgentScope 버전, API의 접근 범위, 이 엔드포인트를 호출할 수 있는 주체를 함께 확인해야 한다.
기술적 분석
취약점 기록이 밝히는 인과는 지목된 범위 안에서 정리된다. MCP Workspace API 구성요소 가운데 src/agentscope/mcp/_config.py의 subprocess.Popen이 영향받는 요소로 명시됐고, command 인자를 조작하면 운영체제 명령 주입이 발생하며, 공격은 원격에서 개시할 수 있다고 기록돼 있다. 반면 command 값이 코드 내부에서 어떤 경로로 전달되는지, 어떤 입력 검증이 선행되는지 같은 구현 세부와, 모든 배포 환경의 인증 및 접근 통제 상태는 제공된 근거로 확인할 수 없다.
재현 결과와 해석
연구자는 2026-07-08 위 구성에서 동적으로 검증했고, 기록된 성공 기준 세 가지가 모두 통과했다. HTTP 응답은 기대대로 오류 또는 시간 초과였고, AgentScope 호스트에는 표식 파일이 생성됐으며, 그 내용도 기대한 표식 문자열과 일치했다.
실무적으로 중요한 것은 응답과 실행 결과가 엇갈렸다는 점이다. 호출자에게는 오류 또는 시간 초과로 보였지만, 호스트에는 의도한 표식 파일이 남았다. 오류 응답이 떴으니 실행이 없었다는 추론은 이 유형에서 통하지 않는다. API 응답 패턴만 모니터링하는 환경이라면 통과할 수 있는 신호이므로, 오류 응답을 무해한 항목으로 분류하는 기준을 두고 있었다면 그 기준 자체를 다시 살펴볼 필요가 있다.
공개 PoC·익스플로잇 분석
먼저 CVE 기록 자체가 익스플로잇이 공개돼 사용될 수 있다고 명시한다. 연구자가 공개한 보안 권고에는 검증이 수행된 재현 환경과 성공 기준이 보고돼 있다. 같은 연구자는 AgentScope 저장소 issue에서 이 동작을 기대 동작의 위반으로 규정했고, stdio MCP 명령용 선택형 허용목록을 추가하는 pull request도 별도로 열려 있다.
검증이 수행된 환경은 권고가 밝힌 구성과 같다. Windows 11 호스트에 기본 LocalWorkspace 배포, AgentScope v2.0.4, Redis 7, 예시 에이전트 서비스가 0.0.0.0:8000에 바인딩된 상태에서 검증이 이뤄졌다. 이는 연구자가 실제로 재현에 성공한 환경의 기록이며, 이 구성이 공격에 필수적인 사전 조건임을 뒷받침하는 근거는 제공된 자료에 없다. 같은 이유로, 검증된 환경에서 해당 엔드포인트의 인증 동작이 실제로 어떻게 구성돼 있었는지도 제공된 인용만으로 확정할 수 없다.
입증 범위는 위 구성에서 명령이 실행되고 의도한 산출물이 호스트에 남았다는 사실까지다. 샌드박스 이탈, 권한 상승, 지속화, 데이터 유출, 다른 운영체제나 배포 형태, 검증 버전 이후 릴리스에서의 성공, 그리고 실제 환경 악용은 제공된 근거로 입증되지 않았다. 공개 재현과 실제 악용은 같은 문장이 아니다.
운영상 의미는 응답과 실행 결과가 갈라진 지점에서 시작한다. 재현 수단이 공개된 이상, 공식 수정이 확인되기 전까지의 노출은 조건부로 실행 가능하게 취급하는 편이 안전하다. 점검 초점도 버전 확인에만 둘 수 없다. 검증에 쓰인 구성과 내 구성이 얼마나 겹치는지 살피면서, AgentScope 버전과 MCP Workspace API의 노출 범위 및 실제 접근 통제 상태를 함께 확인하게 된다.
수정 방향과 남은 조건
연구자가 issue에서 제시한 기대는 세 갈래다. API 호출자가 임의의 로컬 프로세스 실행을 유발해서는 안 되고, stdio 명령은 사전 승인된 MCP 서버의 서버 측 허용목록이나 레지스트리로 제한해야 하며, POST /workspace/mcp는 인증된 관리자 접근을 요구해야 한다는 것이다. 이는 그렇게 되어야 한다는 제안이지, 현재 배포가 그렇게 구성돼 있다는 뜻은 아니다.
제안된 수정안 중에는 stdio MCP 명령에 선택형 허용목록을 추가하는 pull request가 있다. 이 안은 opt-in이므로 운영자가 설정하기 전까지 기존 배포에 보호 효과를 주지 않으며, 생성된 프로세스를 샌드박스로 격리하지도 않는다. 안전한 기본값을 켠 쪽으로 바꿀지는 유지보수자의 판단으로 남겨져 있다. 허용목록을 적용해도 실행된 프로세스의 격리라는 별개의 문제가 남는다는 점이 제안 문서에 함께 적혀 있다.
대응 방안
지금 확인할 것
- 구동 중인 AgentScope 버전이 기록상 영향 범위인 2.0.11 이하인지 확인한다.
- MCP Workspace API가 내부망이나 로컬 루프백에 머무르는지, 외부에 노출되는지 확인한다. 재현에 쓰인 예시 서비스처럼 광범위한 주소에 바인딩된 상태는 아닌지 살펴본다.
- 이 API에 인증 및 접근 통제가 어떻게 구성돼 있는지, 누구의 자격으로 호출 가능한지 점검한다.
접근 통제
API를 사용할 필요가 없다면 노출면 자체를 줄이는 것이 가장 단순한 방향이다. 사용이 필요하거나 접근 경로가 넓다면, 호출을 인증된 관리자로 제한하는 방안을 검토한다. 인증과 접근 통제의 실제 동작은 문서나 기본값이 아니라 현재 배포의 실제 설정으로 확인해야 한다.
구조적 조치
서버 측에서 사전 승인된 MCP 서버의 stdio 명령만 허용하는 방향이 원인에 가깝다. 다만 보호 효과는 허용목록을 실제로 켰는지에 달려 있고, 앞서 정리한 대로 이 안은 선택형(opt-in)이며 프로세스 격리는 별도 문제로 남는다. 공식 수정안이 수용됐는지, 수용됐다면 어느 버전에서 어떤 조건으로 동작하는지는 현재 근거로 확인되지 않으므로, 영구 조치는 벤더 안내가 확인된 뒤 적용 범위를 확정하는 편이 안전하다.
탐지 관점
가능한 범위에서 MCP Workspace API 요청과 그 직후 발생한 예상 밖의 호스트 프로세스 실행을 연관해 검토한다. 이 유형에서는 오류나 시간 초과 응답도 실행 없음을 의미하지 않으므로 검토 대상에서 제외하지 않는다. 구체적인 로그 필드나 침해 지표는 제공되지 않았으므로, 위 두 신호를 어떻게 짝지을지는 각 환경의 판단 영역으로 남아 있다.
남은 공백
공식 수정 버전과 수정안의 수용 상태, 그리고 실제 환경에서의 악용 여부는 확인되지 않았다. 따라서 패치 버전으로 올리면 해결된다는 안내도, 실제 공격이 관측됐다는 경고도 지금은 할 수 없다. 확인된 재현이 Windows 11의 기본 LocalWorkspace 배포를 대상으로 기록돼 있는 만큼, 다른 구성에 이 결론을 옮기려면 각 환경의 버전과 API 노출·접근 통제 상태를 따로 대조해야 한다. 위 대응은 모두 현재 공개된 재현과 제안된 통제 방안을 기준으로 한 조건부 판단으로 이해해 주기 바란다.
참고자료
- CVE-2026-123022
- AgentScope MCP stdio workspace unauthenticated process execution
- AgentScope unauthenticated arbitrary process execution via MCP stdio workspace configuration
- add opt-in allowlist for stdio MCP commands
함께 읽으면 좋은 글
- CVE-2026-122160: AIlice HuggingFace 모델 래퍼의 비신뢰 모델 경로 처리 점검
- CVE-2026-12411: LXD DevLXD 장치 패치로 열리는 게스트 간 볼륨 접근
- CVE-2026-122159: Audio8_TTS 모델 경로 해석의 경로 순회 취약점 점검
본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.
댓글 (0)
댓글을 작성하려면 로그인이 필요합니다.
로그인아직 댓글이 없습니다.
첫 번째 댓글을 작성해보세요!