AgentScope v2.0.4의 Agent Service에서 비어 있지 않은 X-User-ID 헤더 문자열 하나면 별도의 인증 과정 없이 검증된 사용자 식별자로 받아들여진다는 보고가 GitHub 이슈 #3314로 제출되었다. 작동 원리는 단순하다. 서비스가 요청에 실려 들어온 헤더 값을 신원 증명과 분리해 그대로 믿는데, 그 판단 조건이 사실상 문자열이 비어 있지 않다는 것 하나라는 점이 이 보고의 핵심이다.
본 글은 Security Desk 리포트를 통해 확인 가능한 근거만으로 AgentScope X-User-ID 인증 누락 보고의 요지와 작동 원리, 권고 대응, 혼동하기 쉬운 PR #3448의 성격, 운영 환경에서 먼저 점검할 항목을 정리한다. 기준 시점은 2026년 11월 11일이며, 근거가 확보되지 않은 사항은 확인되지 않은 범위로 명시해 구분했다.
AgentScope v2.0.4 Agent Service, X-User-ID 인증 누락 보고의 요지
무엇이 보고되었나
보고 대상은 AgentScope v2.0.4의 Agent Service다. 보고의 요지는 사용자 식별 헤더를 인증 없이 신뢰한다는 것이며, 구체적으로는 비어 있지 않은 X-User-ID 문자열이면 검증된 사용자 식별자로 받아들여진다는 것이다. GitHub 이슈 #3314가 이 내용을 다루고 있다.
어떤 원리로 성립하는가
이 보고가 지적하는 구조를 조건으로 풀면 다음과 같다.
- 서비스는 요청 헤더의 X-User-ID 값을 사용자 식별에 쓴다.
- 식별자로 인정하는 조건은 문자열이 비어 있지 않다는 것뿐이다.
- 그 값이 실제로 해당 사용자의 것인지 확인하는 인증 단계는 요구하지 않는다.
요청 헤더에 들어가는 값은 일반적으로 요청을 만드는 쪽이 정한다. 검증 없이 이 값을 신원으로 삼으면 요청자가 표명한 식별자가 곧 서비스가 인정하는 신원이 된다. 비어 있지만 않으면 어떤 값이든 검증된 식별자로 통과한다는 보고 내용과 맞물리면서, 임의의 사용자 식별자를 헤더에 실은 요청이 그 사용자로 취급될 수 있다. 인증 누락이 심각하게 다뤄지는 지점이 바로 여기다.
확인된 사실과 확인되지 않은 사실: 영향 범위의 경계
이 이슈를 논할 때는 확인된 사실과 확인되지 않은 사실의 경계부터 그린다. 근거 자료에서 직접 확인되는 사실은 다음 표와 같다.
| 항목 | 내용 | 상태 |
|---|---|---|
| 보고 대상 | AgentScope v2.0.4의 Agent Service | 확인됨 |
| 보고 내용 | 비어 있지 않은 X-User-ID 문자열이 검증된 사용자 식별자로 받아들여짐 | 확인됨 |
| 추적 가능한 이슈 | GitHub 이슈 #3314 | 확인됨 |
| 권고 대응 | JWT, API 키, OAuth2 등을 이용한 서버 측 신원 검증 추가 | 확인됨 |
| 구현 주입 지점 | create_app()의 extra_middlewares 파라미터(src/agentscope/app/_app.py) | 확인됨 |
| 실제 악용 사례·공개 공격 코드 | 존재 여부 | 확인되지 않음 |
| 취약점 수정 버전 | 존재 여부 | 확인되지 않음 |
| 영향 기능·데이터 범위 | 테넌트 데이터 전체 노출 여부 | 판단 불가 |
| PR #3448 병합·반영 여부 | 근거 문서에 관련 정보 없음 | 확인되지 않음 |
확인되지 않은 범위도 함께 정리한다.
- GitHub 이슈 #3314의 원문 전문은 직접 수집되지 않았고, Security Desk 리포트의 인용과 요약으로만 확인할 수 있다.
- 보안 권고 원문 역시 직접 수집되지 않았다.
- PR #3448의 병합·반영 여부는 근거 문서에 정보가 없다.
- 이슈 제목에 CWE-306과 CVSS 9.8이 함께 표기돼 있다는 언급이 있으나, 이 표기의 산출 주체와 산출 근거는 근거 자료에 기재되어 있지 않아 본 글에서는 확정된 분류나 점수로 다루지 않는다.
- 실제 악용 사례와 공개 공격 코드의 존재 여부는 확인되지 않는다.
- 취약점이 수정된 버전의 존재 여부도 확인되지 않는다.
- X-User-ID 조작으로 도달할 수 있는 기능과 데이터 범위가 확인되지 않아, 테넌트 데이터 전체 노출 여부는 현재 근거로 판단할 수 없다.
- AgentScope v2.0.4 외 버전에서 같은 동작이 발생하는지, 어떤 배포 조건에서 문제가 드러나는지도 확인되지 않았다.
- extra_middlewares로 주입한 미들웨어의 실행 시점과, 검증된 식별자가 기존 헤더 값을 대체하는지 여부는 제공된 근거로 확인할 수 없다.
보안 권고가 제시한 대응: 서버 측 신원 검증과 extra_middlewares
보안 권고가 제시하는 대응은 서버 측 신원 검증 추가다. JWT, API 키, OAuth2 등을 예로 든다. 요점은 클라이언트가 보내온 X-User-ID 값을 그대로 믿는 대신, 서버 측에서 신원을 검증하는 단계를 요청 처리 앞에 두는 구조로 바꾸는 것이다.
구현 관점에서 권고가 짚는 주입 지점은 createapp()의 extramiddlewares 파라미터이며, 소스 위치는 src/agentscope/app/app.py다. 다만 extramiddlewares로 주입한 미들웨어가 실행되는 시점과, 검증된 식별자가 기존 헤더 값을 실제로 대체하는지는 제공된 근거로 확인되지 않는다. 도입 전에는 대상 환경에서 동작 순서를 직접 검증하는 수밖에 없다.
PR #3448은 stdio MCP 허용 목록 변경일 뿐 인증 문제의 해결책이 아니다
PR #3448은 stdio MCP 명령을 위한 opt-in 허용 목록을 추가하는 변경이다. 인용된 설명은 이 변경이 인증을 추가하지 않는다고 명시한다. 허용 목록이 다루는 대상은 stdio MCP 명령이지 X-User-ID 인증 누락이 아니므로, PR #3448을 이 문제의 해결책으로 취급하면 안 된다. 병합·반영 여부 역시 확인되지 않았다.
우리 환경에서 먼저 확인할 사항
운영 관점에서는 다음 순서로 점검하는 것이 합리적이다.
- 사용 중 AgentScope 버전을 확인한다. 보고 대상은 v2.0.4이며, 다른 버전에서 같은 동작이 발생하는지는 확인되지 않았다.
- Agent Service로 들어오는 요청 경로에 서버 측 신원 검증이 존재하는지 확인한다. 권고는 JWT, API 키, OAuth2 등을 예로 든다.
- X-User-ID 값이 비어 있지 않다는 이유만으로 검증된 식별자로 처리되는지 점검한다.
- 검증 추가를 검토한다면 createapp()의 extramiddlewares 파라미터가 권고가 지목하는 주입 지점이다. 단 미들웨어 실행 시점과 헤더 값 대체 여부는 직접 검증이 필요하다.
- PR #3448을 인증 문제의 해결책으로 간주하지 않는다. 해당 PR은 stdio MCP 명령용 opt-in 허용 목록 변경이다.
- 수정 버전의 존재 여부는 근거 자료에서 확인되지 않으므로, 상류 저장소와 공식 발표를 직접 추적한다.
정리: 보고의 핵심과 남은 과제
AgentScope X-User-ID 인증 누락 보고의 핵심은 AgentScope v2.0.4의 Agent Service에서 비어 있지 않은 X-User-ID 문자열이면 인증 없이 검증된 사용자 식별자로 받아들여진다는 점, 그 대응 방향이 서버 측 신원 검증 추가이고 그 주입 지점이 createapp()의 extramiddlewares라는 점이다. 동시에 이 내용은 아직 확인 범위가 제한된 보고라는 점, 실제 영향 범위와 수정 버전 존재 여부가 확인되지 않았다는 점, PR #3448이 인증 문제의 해결책이 아니라는 점을 함께 기억할 때 정확한 대응이 가능하다.