AIエージェントと外部ツールをつなぐ標準規格MCP(Model Context Protocol)の公式Python SDKで、接続先のMCPサーバーが悪意を持っていると、OAuthの認証情報を丸ごと奪われる欠陥が9月28日に 公表されました 。深刻度は「High」(CVSS 7.5)で、修正版はmcp 1.30.0と2.2.0です。PythonでMCPクライアントを作り、OAuthでサーバーに接続している開発者が対象です。注意したいのは、サーバー間認証に使う2つのクラスでは、更新しただけでは守られず、コードに1行足す必要がある点です。
何が起きていたか
OAuthでは、クライアントは「どの認可サーバー(ログインを担当するサーバー)に認証情報を渡すか」を、MCPサーバーから教えてもらう手順(ディスカバリー)を踏みます。このとき本来は、教えられた認可サーバーが名乗るissuer(発行者の識別子)が、期待した相手と一致するかを確かめます。
発見者の一社であるCycodeの 解説 によると、SDKはMCPサーバーが最初の問い合わせに404(見つからない)を返すと、別の経路でログイン設定をMCPサーバー自身から取りに行きます。この代替経路では比較対象のURLが空のままなので、issuerの確認が丸ごと飛ばされていました。Cycodeは「攻撃者は何もしなくていい。ログイン担当は誰かと聞かれたら404を返すだけだ」と書いています。
その結果、悪意あるMCPサーバーは、トークンの交換先を自分の用意したURLに向けられます。アドバイザリーによれば、流出しうるのはクライアントシークレット、認可コード、PKCE(認可コードの横取りを防ぐ仕組み)の検証用の値です。攻撃者はこれを本物の認可サーバーに持ち込み、正規のアクセストークンを取得できます。Cycodeはこれを「アカウントの完全な乗っ取り」と表現しています。
なぜ「更新するだけ」では足りないのか
影響を受けるのはOAuthClientProvider、ClientCredentialsOAuthProvider、PrivateKeyJWTOAuthProvider、それに1.x系で非推奨のRFC7523OAuthClientProviderです。
このうちClientCredentialsOAuthProviderとPrivateKeyJWTOAuthProviderは、人を介さずに機械同士で認証するためのクラスです。アドバイザリーは、この2つについて更新後にissuer=(例: issuer="https://auth.example.com")を渡すよう求めています。渡さない場合は非推奨の警告が出るだけで、必須になるのは次のメジャー版3.0からです。 The Hacker Newsの記事 はこれを「issuer=を渡すまで、更新しても何も変わらない」とまとめています。CIが警告を無視する設定だと、パッチを当てたつもりで穴が残ることになります。
深刻度も2種類あります。The Hacker Newsによると、人のログイン操作を挟むOAuthClientProviderはCVSS 6.5、人を介さない2クラスは7.5です。後者は利用者の操作なしに成立するためです。Cycodeは、対話型でも安全とは言えないとして、MCPサーバーの登録簿の汚染、エージェントへのプロンプトインジェクション(外部の文章に紛れ込ませた命令)、DNSの乗っ取りで、接続先を利用者が選ばないまま悪意あるサーバーにつながる筋書きを挙げています。
時系列にも注意が必要です。PyPIの記録では、修正を含む1.30.0と2.2.0は9月7日に公開されていました。アドバイザリーの公表はその3週間後です。9月7日以降に何となく更新した人も、issuer=を足していなければ2クラスは守られていません。現時点で、実際の攻撃は報告されていません。
日本の読者にとって
社内のエージェント基盤や、SaaSとAIをつなぐ連携をPythonのMCPで作っている企業は少なくありません。特に、社外のMCPサーバーやMCPの公開ディレクトリに載ったサーバーに、自社の認証情報を持ったクライアントから接続している構成は、今回の条件にそのまま当てはまります。9月28日に取り上げた エージェントスキルが例示用ドメイン経由で詐欺サイトにつながる問題 と同じく、エージェントが「どこにつながるか」を人が確かめない前提の弱さが出た事例だと考えられます。
次にやることは3つです。1つ目、依存関係でmcpの版を確認し、修正版に上げる。間接的な依存で入っている場合もあるので、ロックファイルも見てください。2つ目、コード内でClientCredentialsOAuthProviderとPrivateKeyJWTOAuthProviderを検索し、issuer=を追加して警告が消えることを確認する。3つ目、信頼できないMCPサーバーに接続した履歴がある場合は、アドバイザリーの指示どおりクライアントシークレットを入れ替え、発行済みトークンを認可サーバー側で失効させる。すぐに更新できない古い版を使い続ける場合、Cycodeは完全に信頼できるMCPサーバーにだけ接続するよう勧めています。
