AWS API MCP ServerにOAuth検証不備｜1.6.0更新とaudience設定を確認

AWSは2026年10月27日、オープンソースのAWS API MCP ServerにおけるOAuthトークン検証不備、CVE-2026-115413を公表しました。影響するのはバージョン1.3.0以上1.6.0未満を、streamable-httpトランスポートとOAuth認証の組み合わせで動かしている構成です。既定のstdioだけを使うローカル構成や、別の認証方式は、この脆弱性の影響条件には含まれません。

運用担当者は、まず稼働版とトランスポート、AUTH_TYPEを確認し、該当する場合は1.6.0以降へ更新します。更新後は、一般的な「署名が正しいトークン」を受け入れる設定で終わらせず、このMCPサーバー向けのaudまたはクライアントIDを検証する必要があります。本稿では、公式勧告の確認済み事実と、導入環境で行う点検・拒否試験の提案を分けて整理します。

別アプリ向けの正規トークンが通る問題

AWSのセキュリティ告知によると、影響版はOAuthトークンの署名、発行者、有効期限を検証する一方、そのトークンがどのアプリケーション向けに発行されたかを示すクレームを検証していませんでした。同じIDプロバイダーの同じテナントに別のアプリがあると、その別アプリ向けに正規発行されたトークンをAWS API MCP Serverが受け入れる可能性があります。

例として公式のGitHub Security Advisoryは、同じAmazon Cognitoユーザープール内の別アプリクライアントへ発行されたトークンを挙げています。条件を満たすトークンを持つローカルの呼び出し元はMCPサーバーへ到達し、ホストに設定された認証情報の範囲でAWS APIを呼び出せる可能性があります。影響の上限はホスト側のIAM権限に左右されます。MCP側の認証不備が、IAMの許可を超えてAWS全体の権限を新たに作るという意味ではありません。

GitHub Security Advisoryは深刻度をHigh、CVSS v4.0を7.3と評価しています。攻撃経路はネットワーク全体へ無条件に開かれた認証不要攻撃ではなく、同じテナントの別アプリ向けトークンを保有し、対象サーバーへ到達できることなどの前提があります。AWSの公表資料は実環境での悪用確認を記載していないため、本稿では悪用状況を「不明」と扱います。

影響確認は4条件を一緒に見る

製品名やCVE番号だけで対象を決めず、次の4点を同じ稼働単位で確認します。開発端末の設定ファイルだけでなく、コンテナ定義、systemd、CI/CDのシークレット、環境変数を注入するデプロイ設定、フォーク版の依存固定も確認対象です。

• awslabs.aws-api-mcp-serverが1.3.0以上1.6.0未満か
• AWS_API_MCP_TRANSPORT=streamable-httpか
• AUTH_TYPE=oauthでOAuth認証を有効にしているか
• そのHTTPエンドポイントへ、想定外の利用者やワークロードから到達できるか

公式READMEではHTTPモードの既定ホストを127.0.0.1、既定ポートを8000とし、可能ならlocalhostへバインドし、ファイアウォールで接続元を制限するよう案内しています。ただし、localhost限定でも同一ホスト上の別プロセスから到達できるため、今回のトークン検証を省略できる根拠にはなりません。リバースプロキシやコンテナのポート公開がある場合は、アプリ内のbind値だけで外部到達性を判断しないことも重要です。

1.6.0へ更新し受け入れるアプリを明示する

修正版はawslabs.aws-api-mcp-server 1.6.0です。AWSは最新版への更新に加え、フォークや派生実装にも修正を取り込むよう求めています。パッケージを更新しただけで、コンテナイメージや常駐プロセスが古いままにならないよう、稼働中プロセスが参照する版を再確認します。タグlatestだけを根拠にせず、起動ログ、パッケージ一覧、イメージのダイジェストなど、実際の配布方式に合う証拠を残します。

1.6.0では、OAuth利用時に期待するaudienceまたはclient IDの指定が必要です。アクセストークンにaudクレームがあるIDプロバイダーではAUTH_AUDIENCEを指定します。Amazon Cognitoのようにアクセストークンへaudがなく、アプリがclient_idで表される場合はAUTH_CLIENT_IDを使います。両方を指定した場合は両クレームが検証されます。

AWS_API_MCP_TRANSPORT=streamable-http
AUTH_TYPE=oauth
AUTH_ISSUER=https://idp.example.com/
AUTH_JWKS_URI=https://idp.example.com/.well-known/jwks.json
AUTH_AUDIENCE=aws-api-mcp

この例の値は構成を示す仮のものです。IDプロバイダーの管理画面で対象MCPサーバーに対応するリソース／アプリを確認し、実際に発行されたトークンのクレーム設計と一致させます。表示名や推測した文字列を設定すると、正規クライアントまで拒否するか、意図しないトークンを許すおそれがあります。秘密鍵や実トークンを記事、チケット、共有ログへ貼らず、ヘッダーとペイロードの必要なクレームだけを安全な環境で確認します。

更新後は「成功」より「拒否」を試す

疎通確認では正規クライアントが接続できることだけでなく、同じ発行者が別アプリ向けに発行したトークンが拒否されることを確認します。署名が壊れたトークンだけを試しても、今回の修正点であるアプリケーション境界は検証できません。検証用テナントや専用クライアントを使い、本番トークンを持ち出さない手順にします。

1. 正しい発行者、正しいaudience／client ID、有効期限内のトークンで必要最小限のMCP操作が成功する
2. 同じ発行者でも別アプリ向けのトークンは認証段階で拒否され、AWS APIが呼ばれない
3. 期限切れ、発行者違い、署名不正のトークンも拒否される
4. 拒否時のログにトークン本文や機密クレームを残さず、時刻と判定理由を追跡できる

ここで示した拒否試験は本サイトの提案であり、筆者が読者の環境で実測した結果ではありません。HTTPステータスだけで判定せず、対象時刻にCloudTrail等で対応するAWS API呼び出しが発生していないことも確認します。CloudTrailはサービスや操作により記録対象、管理イベント／データイベント、追加設定が異なるため、利用するAWS APIごとの記録条件を先に確認してください。

IAMを狭め認証失敗時の影響を限定する

今回の脆弱性で実行できる操作は、MCPサーバーのホストに与えたAWS認証情報の権限に制約されます。したがって更新と並行して、専用のIAMロールまたはプロファイルを使っているか、不要な書き込み権限がないか、対象リージョンやリソースを条件で絞れるかを点検します。公式READMEのREAD_OPERATIONS_ONLY=trueは書き込み操作を抑える補助策ですが、README自身がIAM権限を主要な制御と説明しています。このフラグだけで過大なIAMポリシーを補わないでください。

特に、AIエージェントが自然言語からAWS CLI操作を選ぶ構成では、「認証できた利用者」と「その利用者に実行させてよいAWS操作」を別々に設計します。MCPサーバーのOAuth検証は前者、IAMは後者です。両者のどちらか一方だけを強くしても、別アプリの利用者が過大なホスト権限を使える構成や、正規利用者が不要な更新操作を実行できる構成は残ります。

更新前に利用されていた環境の確認

該当版をHTTP＋OAuthで公開していた場合は、更新だけで過去の利用を消去せず、公開期間、接続元、認証失敗・成功、MCP操作、対応するAWS API履歴を時系列で照合します。IDプロバイダー側では、対象MCPアプリだけでなく同じテナントに存在する別アプリのクライアント、トークン発行主体、無効化済みアプリも確認します。別アプリ向けトークンを持つこと自体は侵害の証拠ではないため、MCPエンドポイントへの接続とAWS API実行の対応を取って判断します。

AWSやGitHubの公式勧告は、侵害痕跡や特定のIOCを提示していません。未知の悪用を断定したり、すべての認証情報を無条件に交換したりするのではなく、ログで不審な呼び出しが確認された場合に、使用されたIAM認証情報、影響したリソース、派生した資格情報を特定して失効・交換します。必要なログが保存されていなければ、その欠落を調査上の制約として記録し、影響し得る権限の広さから対応を決めます。

一時回避はstdioへの切り替え

すぐに更新できない場合、AWSは既定のstdioトランスポートへ切り替える方法を回避策として示しています。HTTPエンドポイントを止め、同じ端末上のクライアントから標準入出力で起動する構成へ戻すことで、今回の「streamable HTTP＋OAuth」という成立条件から外れます。ただし、業務上リモート接続が必要な構成では単純に置き換えられません。その場合は影響版の公開を続けるのではなく、更新までサービスを止めるか、到達元を厳しく制限する判断が必要です。

なお、既報のAWS MCP ServerのPythonサンドボックス修正は、AWSがホストするマネージドサービスのrun_scriptを扱い、顧客側の更新は不要でした。今回のCVE-2026-115413は、自ら導入するオープンソースのAWS API MCP Serverが対象で、1.6.0への更新とOAuthクレーム設定が必要です。名称が似ていても、対象と作業を混同しないでください。

対応の優先順位

最初に稼働構成を特定し、該当するHTTP＋OAuth環境を1.6.0以降へ更新します。次にAUTH_AUDIENCEまたはAUTH_CLIENT_IDを実際のトークンクレームへ合わせ、別アプリ向けトークンの拒否試験を行います。最後にIAM権限と公開期間中の利用履歴を点検します。更新、アプリ境界の検証、AWS権限の最小化を別作業として管理することが、再発時にも判断しやすい運用につながります。