AWS API MCP Server 보안 업데이트: OAuth 토큰의 audience까지 확인해야 하는 이유

토큰의 발급 대상과 접근 경계를 표현한 생성형 개념 이미지. 실제 제품 화면이 아니다.

OAuth 로그인이 성공하고 JWT 서명도 맞는데, 다른 앱에 발급된 토큰이 우리 서버에서 통과할 수 있을까? 토큰의 수신 대상까지 검사하지 않으면 가능한 문제다.

AWS는 2026년 10월 27일 오전 11시 PDT, 한국 시간으로 10월 28일 오전 3시에 AWS API MCP Server의 OAuth audience 검증 누락을 공지했다. 해당 구성을 운영한다면 패키지 업데이트와 인증 설정을 함께 확인해야 한다. AWS 보안 공지

먼저 영향 범위부터 확인하기

대상은 오픈소스 패키지 awslabs.aws-api-mcp-server의 1.3.0 이상, 1.6.0 미만이다. 이 중 streamable-http 전송과 OAuth 인증을 함께 사용하는 배포가 영향을 받는다. 수정 버전은 1.6.0이다.

취약한 구성은 지정한 인증 제공자가 같은 테넌트의 다른 앱에 발급한 토큰을 받아들일 수 있다. 그 결과 호출자가 서버 호스트에 설정된 AWS 자격 증명의 권한 범위 안에서 AWS API를 호출할 수 있다. 모든 AWS 계정이나 모든 MCP 서버가 같은 문제를 가진다는 의미는 아니다. awslabs 보안 권고

확인 항목	이번 공지의 범위
패키지	`awslabs.aws-api-mcp-server`
영향 버전	1.3.0 이상, 1.6.0 미만
영향 구성	streamable-http + OAuth
식별자	CVE-2026-115413
수정 버전	1.6.0

표의 버전·구성은 공식 권고 기준이다. 사용 여부는 실제 서버의 실행 환경에서 별도로 확인해야 한다.

서명, 발급자, 만료일만으로 부족한 이유

JWT의 aud는 토큰을 받아 처리할 대상을 나타낸다. RFC 7519는 이 클레임이 존재할 때 처리 주체가 대상에 포함되지 않으면 토큰을 거부해야 한다고 규정한다. RFC 7519 §4.1.3

예를 들어 같은 회사의 인증 시스템이 문서 앱과 인프라 관리 앱에 토큰을 발급한다고 생각해 보자. 두 토큰 모두 믿을 수 있는 발급자가 서명했더라도 사용 목적은 다르다. 문서 앱에 준 토큰을 인프라 관리 서버가 그대로 받아서는 안 된다. 이는 이해를 위한 가상 예시다.

이번 취약 버전은 서명·발급자·만료를 검사하면서 앱을 식별하는 클레임을 확인하지 않았다. 정상적으로 발급된 토큰이라도 어디에 쓰도록 발급됐는지 검증하는 단계가 필요했던 것이다. awslabs 권고의 원인 설명

패키지와 설정을 같이 바꾸기

AWS는 최신 버전으로 업데이트하고, 포크나 파생 코드에도 수정을 반영하도록 권고한다. OAuth 운영자는 AUTH_AUDIENCE를 지정해야 하며, Amazon Cognito처럼 접근 토큰에 audience 클레임이 없는 제공자에서는 AUTH_CLIENT_ID를 사용하도록 안내한다. 즉시 업데이트할 수 없다면 기본 stdio 전송을 사용하는 임시 대응도 제시했다. AWS 대응 안내

먼저 실제 서버를 실행하는 Python 환경에서 버전을 확인한다. 다음 명령은 메타데이터 조회 예시이며, 이 글에서 사용자의 서버에 실행한 결과가 아니다.

다른 가상환경의 Python을 실행하면 엉뚱한 버전을 볼 수 있다. uvx나 컨테이너로 띄운다면 해당 실행 환경과 이미지의 패키지를 확인한다. 배포 설정의 버전 표기와 현재 실행 중인 프로세스도 구분한다.

다음은 audience를 사용하는 제공자의 환경변수 예시다. URL과 대상 값은 자신의 인증 제공자 설정에 맞게 바꿔야 한다.

공식 설정 문서에서 AUTH_AUDIENCE는 aud와 비교하고, AUTH_CLIENT_ID는 client_id 또는 azp와 비교한다. 두 값을 함께 설정하면 둘 다 검증한다. 예시를 그대로 붙여 넣기보다 사용 중인 접근 토큰의 클레임과 IdP 구성을 먼저 확인해야 한다. AWS API MCP Server 설정 문서

성공뿐 아니라 거부도 테스트하기

업데이트 뒤 정상 호출만 확인하면 같은 종류의 문제를 놓칠 수 있다. 아래는 테스트 환경에서 사용할 검증 체크리스트다. 실제 공격 재현이나 운영 계정 점검 결과는 아니다.

의도한 대상에 발급된 테스트 토큰으로 허용된 읽기 작업이 성공하는가?

자신이 관리하는 별도 테스트 앱의 토큰은 인증 단계에서 거부되는가?

만료되거나 잘못된 발급자의 테스트 토큰도 거부되는가?

거부된 요청이 AWS 작업 실행까지 이어지지 않는가?

로그에 토큰 원문이나 자격 증명이 남지 않는가?

오류를 없애려고 AUTH_TYPE=no-auth로 전환하는 것은 인증을 제거하는 조치다. 공식 문서도 이 값이 인증을 비활성화한다고 명시한다. 또한 이 서버는 다중 사용자·테넌트 공유용으로 설계되지 않았으며, 인스턴스마다 단일 사용자와 전용 AWS 자격 증명을 사용하도록 안내한다. 공식 보안 고려사항

패치, 대상 클레임 설정, 거부 테스트를 한 묶음으로 확인하는 편이 좋다. 에이전트의 도구 호출을 허용하기 전에 누가 발급한 토큰인지와 이 서버에 사용할 토큰인지가 함께 검증돼야 한다.