AgentScope v2.0.4의 Agent Service에서 사용자 식별 헤더가 인증 없이 신뢰된다는 보고가 나왔다. 비어 있지 않은 X-User-ID 문자열이면 검증된 사용자 식별자로 받아들여진다는 것이 요지다. 다만 실제 악용 사례, 수정 버전, 식별자 조작으로 도달할 수 있는 데이터의 범위는 확인되지 않았다. 확인된 사실과 아직 알 수 없는 부분을 나눠 보고, 지금 환경에서 살펴볼 지점을 정리한다.
개요
GitHub 이슈 #3314의 보고에 따르면 기대 동작과 실제 동작이 엇갈린다. 기대는 테넌트 데이터를 제공하기 전에 비밀번호·토큰·키 같은 신원 증명을 요구하는 것이고, 실제로는 비어 있지 않은 X-User-ID 문자열이 검증된 신원으로 받아들여지며 체인 어디에도 검증 단계가 없다.
요청 헤더는 요청자가 자유롭게 정하는 값이다. 그 값이 그대로 신원이 된다면, 헤더를 붙여서 보낼 수 있는 요청자가 남의 사용자 식별자를 내세워 그 사용자로 취급될 수 있다는 것이 보고의 취지다. 인증이라는 경계가 확인되지 않은 상태로 남는다는 지적이다.
이 내용은 제보자가 관찰한 기대값과 결과이며, 독립적으로 검증된 기록은 아니다. 운영 환경에서의 실제 영향은 근거 자료의 확인 범위에 포함되지 않았다.
영향 범위
보고 대상은 AgentScope v2.0.4의 Agent Service다. 다른 버전이 같은 동작을 보이는지, 어떤 배포 조건에서 문제가 드러나는지는 확인되지 않았다.
실효적 영향은 조건에 따라 판단이 갈린다. 요청자가 서비스에 도달할 수 있고 그 요청이 X-User-ID 값을 직접 정할 수 있다면, 남의 사용자 식별자를 내세워 그 사용자로 취급되는 길이 문제 제기된다. 다만 그 결과가 실제로 따라나올지는 앞단이나 서버 측의 신원 검증 같은 배포 조건에 달려 있고, 전달된 근거는 조건이 갖춰졌을 때의 결과를 직접 입증하지는 않는다.
그래서 1차 확인 지점은 신원 검증의 유무다. 보안 권고가 서버 측 신원 검증 구현을 다루는 만큼, 배포된 환경에 그런 검증이 실제로 들어 있는지부터 살펴봐야 한다. 같은 코드라도 신원 검증의 적용 여부가 확인되기 전에는 노출도를 확정하기 어렵다.
식별자 조작으로 도달할 수 있는 기능과 데이터 범위는 확인되지 않았다. 따라서 테넌트 데이터 전체가 열린다는 식의 판단은 현 시점에서 근거가 없다. 전달된 근거만으로는 실제 악용이나 공개 공격 코드의 존재도 확인할 수 없다.
기술적 분석
보고된 구조를 요약하면, 서비스는 요청에서 X-User-ID 값을 읽어 검증된 사용자 식별자로 사용하고, 그 식별자를 기준으로 테넌트 데이터를 제공한다. 검증 단계가 없기 때문에 결국 헤더 값 자체가 신원이 된다. 전달된 PR #3448의 인용문에서 해당 이슈 제목은 CWE-306과 CVSS 9.8을 함께 표기하고 있다. CWE-306은 인증 메커니즘이 없다는 분류를 가리키지만, 이 표기를 누가 산출했는지는 근거 자료에 적혀 있지 않다.
보안 권고가 제시하는 내용은 서버 측 신원 검증의 추가다. JWT, API 키, OAuth2를 예로 들면서 create_app()의 extra_middlewares 파라미터(src/agentscope/app/_app.py)를 의도된 주입 지점으로 짚는다. 인용문에서 확인되는 범위는 여기까지이고, 미들웨어가 요청 흐름의 어느 시점에 실행되는지, 검증된 식별자가 기존 헤더 값을 대체하는지는 제공된 근거로 확인할 수 없다. 배포할 때 직접 확인해야 할 부분으로 남는다.
stdio MCP 허용 목록 변경은 인증 문제의 답이 아니다
PR #3448의 제목은 add opt-in allowlist for stdio MCP commands이고, 인용된 설명은 이 변경이 인증을 추가하지 않는다고 명시한다. 같은 설명 안에서 X-User-ID spoofing 문제는 별건으로 인용된다. 확인되는 범위도 PR의 제목과 인증을 추가하지 않는다는 서술까지이고, 변경이 실제로 병합·반영됐는지는 근거 자료에 나와 있지 않다. 허용 목록이 다루는 대상은 stdio MCP 명령이고 인증 누락은 스스로 별건으로 두고 있으므로, 이 PR을 인증 문제의 해결책으로 취급하면 안 된다.
대응 방안
노출면부터 확인한다. Agent Service를 실제로 사용하는지, 어디서 도달 가능한지, 배포된 버전이 보고된 v2.0.4인지 본다.
- 노출 범위: 신뢰할 수 없는 요청자가
X-User-ID를 직접 정할 수 있는 환경이 있는지 우선 점검한다. - 기존 보호 조치: 서비스 앞단 또는 서버 측에 요청자의 신원을 검증하는 장치가 이미 적용돼 있는지 확인한다.
- 서버 측 인증 적용: JWT, API 키, OAuth2 등으로 신원 검증을 구현한다. 권고는
create_app()의extra_middlewares를 주입 지점으로 제시한다. - 적용 후 검증: 검증된 신원과 실제 사용자 식별이 일치하는지 확인하고, 기존 연동이 인증 요구에 맞게 갱신됐는지 검토한다.
확인되지 않은 사실은 대응 순서에 조건으로 반영하는 편이 낫다. 외부에 도달 가능한 Agent Service에 신원 검증이 없다면 인증 적용이 최우선이 된다. 내부 전용이고 앞단에서 신원이 검증되는 환경이라도, 검증된 신원과 사용자 식별이 어긋나지 않는지 보는 절차는 남는다. 수정 버전과 전체 영향 범위가 확인되지 않은 상태이므로, 버전 번호만으로 상태를 판정하기보다 우리 환경에 신원 검증이 실제로 적용돼 있는지를 기준으로 판단해야 한다.
참고자료
- AgentScope v2.0.4 has no authentication mechanism
- AgentScope Agent Service X-User-ID missing authentication advisory
- add opt-in allowlist for stdio MCP commands
함께 읽으면 좋은 글
- CVE-2026-120515: SEOPress AI SEO 플러그인의 저장형 XSS 점검
- CVE-2026-119167: TranslatePress AI Translation 플러그인의 저장형 XSS 점검
- CVE-2026-123493: Vikunja, 소유자를 비활성화해도 봇 API 토큰이 계속 인증되는 이유
본 콘텐츠는 AI 기술로 작성된 분석 리포트를 포함하고 있습니다. 내용 중 사실과 다르거나 보완이 필요한 정보를 발견하셨으면 댓글을 통해 의견을 부탁드립니다. 여러분의 피드백은 더 정확한 보안 정보 공유에 큰 도움이 됩니다.
댓글 (0)
댓글을 작성하려면 로그인이 필요합니다.
로그인아직 댓글이 없습니다.
첫 번째 댓글을 작성해보세요!