MCP公式Python SDKにOAuth窃取の穴、社内AIエージェントの点検

社内の業務システムにAIエージェントをつなぐため、MCPのクライアントをPythonで内製したり、SIerに開発を委託したりしている日本企業は少なくない。その企業のセキュリティ担当と開発基盤担当が、今週中に点検すべき脆弱性が公開された。

対象は、MCP（Model Context Protocol、AIエージェントが外部のツールやデータにつなぐための規格）の公式Python SDKであるmcpパッケージだ。2026年9月28日に公開されたアドバイザリGHSA-qx49-fqc8-xw99によると、1.9.1〜1.29.1と2.0.0〜2.1.1のOAuthクライアント機能に欠陥がある[1]。悪意のあるMCPサーバーにつなぐと、クライアントシークレットや認可コードが攻撃者に送られてしまう[1]。深刻度はCVSS 7.5で、CVE番号は9月29日時点で付いていない[1][2]。

修正版の1.30.0と2.2.0は9月7日にすでに出ていた[2]。つまり、リリースノートだけを見て更新を後回しにした組織では、3週間ほど気づかないまま放置されていた可能性がある。本稿は、影響する構成の見分け方、更新だけでは閉じない設定、そして接続先MCPサーバーの管理をどこまでやるかを整理する。

予備知識

• 認可サーバー: OAuth（アクセス権を委ねる標準方式）でトークンを発行するサーバー。Entra IDやKeycloakがこの役割を担う
• クライアントシークレット: アプリが認可サーバーに自分を証明するための長期の合言葉。漏れると入れ替えるまで悪用できる
• PKCE: 認可コードを横取りされても使えないよう、クライアントだけが知る検証値を組み合わせる仕組み
• issuer: 認可サーバーが自分の正体として名乗る識別子（URL）。クライアントが相手を確かめる基準になる

MCPのクライアントとサーバーの役割分担を、Pythonの実装で確かめながら理解したい開発基盤担当に向く一冊。

PythonではじめるMCP開発入門 （KS情報科学専門書）

created by Rinker

• Amazon
• 楽天市場
• Yahooショッピング
• メルカリ

何が起きたのか——MCPサーバーが認可サーバーを差し替えられた

問題の本質は、SDKが「どの認可サーバーに認証情報を渡すか」をMCPサーバーの言い分どおりに決めていたことだ。MCPの仕様では、クライアントはMCPサーバーから401応答を受け取ると、保護リソースメタデータ（RFC 9728）で認可サーバーの場所を知り、その認可サーバーのメタデータ（RFC 8414）を取りに行く[5]。

アドバイザリによると、SDKはこの過程で認可サーバーのissuerを一部の経路で検証しておらず、保存した登録情報も特定の認可サーバーに結び付いていなかった[1]。Cycodeの研究者は、メタデータ取得に404を返して代替経路へ誘導する手口を示している[3]。

対話型のサインインでは、表示されるログイン画面は本物のままだ[3]。利用者は正しく認証したつもりでも、認可コードとPKCEの検証値が同時に攻撃者のトークン窓口へ渡る。PKCEは片方だけを奪われた場合の防御なので、両方を渡してしまうこの攻撃では効かない[4]。

認可サーバー、クライアントシークレット、トークンの関係を図で押さえ、今回の脆弱性の意味を読み解く土台になる。

認証と認可 Keycloak入門 第2版 OAuth/OpenID Connectに準拠したAPI認可と シングルサインオンの実現

created by Rinker

• Amazon
• 楽天市場
• Yahooショッピング
• メルカリ

どの構成が影響を受けるか——HTTP接続のOAuthクライアントだけ

影響を受けるのは、HTTPでMCPサーバーにつなぎ、SDK内蔵のOAuthプロバイダーを使うクライアントに限られる[1]。社内で作ったMCPサーバー側や、ローカルでプロセスとして動かすstdio接続は対象外だ[1]。

深刻度は利用形態で分かれる。人がサインインを始める対話型はCVSS 6.5、人の操作なしで動くサーバー間連携型は7.5だ[1][3]。夜間バッチで動く社内エージェントほど、気づかれずに情報が抜かれる余地が大きい。

2.x系については、Cycodeは代替経路と403応答による再認可の経路で影響があると説明している[3]。現時点で悪用の報告はない[2]。

mcp・エージェント

AIエージェントのMCP認可設計、KubeCon Japanの最前線

Kubernetes上でAIエージェントとMCPサーバーを動かす企業が増えている。MCPはModel Context Protocolの略で、AIエージェントが外部のツールやデータソースへ接続するための標準プロトコルである。エージェントが[…]

更新だけで閉じるか——issuerの固定と資格情報の入れ替え

SDKを更新しても、サーバー間連携型の2つのプロバイダーは設定を足さないと守られない。アドバイザリは、ClientCredentialsOAuthProviderとPrivateKeyJWTOAuthProviderにissuer=で正しい認可サーバーを渡すよう求めている[1]。渡さない場合、更新後もMCPサーバーが示す認可サーバーに従ってしまう[1]。

Skycloakが示す1.x系の設定例は次のとおりだ[4]。issuerは認可サーバーのメタデータにあるissuerと完全に一致させる必要がある[4]。

auth = ClientCredentialsOAuthProvider(
    server_url="https://mcp.internal.example.com/mcp",
    storage=token_storage,
    client_id="reporting-agent",
    client_secret=os.environ["REPORTING_AGENT_SECRET"],
    issuer="https://auth.example.com/realms/acme",
    scopes="mcp:tools",
)

1.30.0では、issuer=を省くとDeprecationWarningが出るが、Pythonの既定では表示されない[1]。3.0で必須になる予定だ[1]。ログに警告が出ないため、コードを検索して指定漏れを探すほうが確実である。

更新後は、保存済みのOAuth登録情報を消して再登録させる[1]。古い登録はissuerに結び付いていないためだ。信頼できないMCPサーバーにつないだ可能性があるなら、認可サーバー側でクライアントシークレットを入れ替え、トークンを失効させる[1]。

Skycloakは、シークレットを使わないprivate_key_jwtへの移行や、エージェント用アクセストークンの有効期間を分単位に短くすることも勧めている[4]。失効を指示しても発行済みのJWTはすぐには無効にならないため、短い有効期間が実質の失効手段になる[4]。

関連記事

F5 BIG-IP APM悪用中の脆弱性、VPN担当者の緊急点検リスト

数千人規模の社員を抱え、社外拠点や在宅勤務者の接続をF5 BIG-IPのリモートアクセスVPNゲートウェイ一台に集約している情シス・セキュリティ担当者にとって、2026年9月22日の発表は座視できない。F5はBIG-IP APM（ア[…]

SIer委託のAIエージェントで接続先とシークレットを誰が管理するか

同じ事象は日本企業でも起きる。ただし、影響の広がり方と対応の遅れ方は、開発体制と権限の付け方によって変わる。

特に重いのは権限の広さだ。漏れるのはそのクライアントの資格情報なので、Entra IDなどで広い権限を管理者同意しているほど、被害の範囲も広がる。

IT部門の判断としては、社内のMCPクライアントを棚卸しし、HTTP接続でSDKのOAuthプロバイダーを使うものだけを今週中に更新対象として特定する。決裁側の判断としては、委託先への改修発注とシークレット入れ替えに伴う停止時間を、緊急対応として通常の稟議より先に承認するかを決める。

関連記事

ColdFusion脆弱性、解析公開2時間で悪用開始の教訓

Adobe ColdFusionは、企業の基幹システムや官公庁システムで長年使われてきたレガシーなWebアプリケーションサーバーである。近年の主流構成に比べると新規採用は減っているが、稼働中のシステムは今も少なくない。2026年7月7日、[…]

まとめ

今回の脆弱性は、MCPサーバーが名乗る認可サーバーをSDKが確かめずに信じていたことに起因する。影響はHTTP接続でSDKのOAuthプロバイダーを使うクライアントに限られるが、サーバー間連携型は更新後もissuer=を指定しない限り守られない。

IT部門の次の一手は、mcpパッケージの版数と使っているプロバイダーを棚卸しし、1.30.0か2.2.0への更新、issuer=の指定、保存済み登録の削除までを一続きの作業として計画することだ。決裁側の判断材料は、外部のMCPサーバーに接続した履歴の有無で、シークレットの入れ替えと委託先への追加発注が必要かどうかが決まる点である。

AIエージェントが増えるほど、接続先の数と資格情報の数も増える。どのMCPサーバーにつないでよいかを許可リストで決めておくことが、次の同種の欠陥への備えになる。

よくある質問（FAQ）

Q. 自社で作ったMCPサーバーも更新が必要ですか。
A. アドバイザリでは、SDKで作ったMCPサーバーは影響を受けないとされている。対象はクライアント側だ。

Q. 手元のPCでMCPサーバーをプロセスとして動かすだけでも危険ですか。
A. stdio接続のクライアントは対象外とされている。HTTPで外部のMCPサーバーにOAuthでつなぐ構成が対象になる。

Q. CVE番号がないと社内の脆弱性管理に載せられません。どうすればよいですか。
A. 9月29日時点でCVEは付いていない。GitHubのアドバイザリ番号GHSA-qx49-fqc8-xw99で登録すれば追跡できる。

出典