Terraform MCP連携に他人の権限で操作される穴 CVE-2026-16498、1.1.0へ

日本時間の2026年7月29日未明、HashiCorpがセキュリティ告知HCSEC-2026-23を公開しました。AIアシスタントからTerraform（サーバーやネットワークの構成を設定ファイルで管理するツール）を操作させるための公式プログラム「terraform-mcp-server」に、脆弱性が3件あったという内容です。

中でも CVE-2026-16498 は、危険度を示すCVSSスコアが上限の10.0。ある利用者が渡したTerraformの認証トークンが、そのあと接続してきた別の利用者の操作にそのまま使われてしまう、という不具合です。自分の操作が他人の権限で走る、あるいは自分の権限で他人の操作が走る。要は誰の権限で動いているのかが入れ替わるという穴でした。

さらに同じ7月28日（米国時間）、GitHubの公式MCPサーバー「github-mcp-server」にも CVE-2026-47427（CVSS 7.5）が公開されました。こちらは認証情報の話ではなく、細工したリクエスト1回でサーバーのプロセスが落ちるというものです。

先に結論を書きます。この4件は、MCPサーバーを自分のパソコンの中だけで（stdioという方式で）1人で使っている人には影響しません。危ないのは、チームで共有する形でHTTPの受け口を立てて運用している構成です。HashiCorpの導入ドキュメントでも既定の通信方式はstdioとされており、個人利用の大多数はここで対象外になります。以下、どの構成が対象で、何をすればいいのかを一次情報だけで整理します。

公開された4件の脆弱性

数値はすべて各CVEの登録元（HashiCorpとGitHub）が付けた値です。米国の脆弱性データベースNVDは、4件とも独自評価をまだ終えていません（登録状態は「Received」で、対象製品の機械可読な定義も未付与）。つまり今出ている10.0や8.9は、開発元の自己採点であって第三者が検算した数字ではないという点は押さえておいてください。

修正版の番号が両方とも「1.1.0」で揃っているのは事実です。ただし terraform-mcp-server と github-mcp-server は別の組織が開発している別のプロジェクトで、CVE番号も報告者も違います。番号の一致は偶然で、共通の原因があるという情報はどこにもありません。

得をするのは、その共有サーバーに手が届く人

この3件（terraform-mcp-server側）で得をするのは、遠くの国のプロの攻撃集団というより、まずその共有MCPサーバーに接続できる立場にある人です。同じ会社の別チームの人、業務委託で一時的にアクセス権を持っている人、あるいは退職手続き中でまだ接続情報が生きている人。加えて、そのHTTPの受け口がインターネット側から届く状態になっていれば、URLを見つけただけの第三者も候補に入ります。CVE-2026-14869にいたっては、HashiCorpの告知が「認証は不要」と明記しています。

入口はMCPの受け口、出口はワークスペースと変数です。他人の資格情報のまま、Terraformの操作を通す。自分の権限では見えないはずのワークスペース一覧を取り、変数の中身を読み、権限が許せば書き換える。CVE-2026-14869の場合はもう一段違って、サーバーが本来Terraformのサービスへ送るはずだった通信の宛先を書き換え、そこに付いている認証トークンごと攻撃者の手元へ届かせます。盗む対象が「他人のセッション」ではなく「サーバー自身の鍵」になるわけです。

ワークスペースと変数の先に何を置いているかが、そのまま被害の輪郭になります。HashiCorpの告知は、悪用された場合に「そのトークンの権限の範囲で、被害者のTerraformの組織・ワークスペース・変数その他のリソースにアクセスできる」と書いています。Terraformの変数にはクラウドのアクセスキーやデータベースの接続文字列を置くことが多く、そこが読まれると被害はTerraform単体で止まりません。運用側にとっては、監査ログに残る実行者の名前が実際の操作者と一致しなくなるのも厄介です。誰がその変更をかけたのかを後から追えなくなります。対処は「1.1.0へ上げる」で済みますが、その前に自分の構成が本当に対象なのかを確認したほうが早いので、順番に見ていきます。

自分の使い方は対象になるのか

terraform-mcp-serverの3件は、どれも「streamable-HTTP」という通信方式を有効にしている場合の話です。HashiCorpの告知は3件それぞれについて、stdio方式だけで動かしている環境は影響を受けないと明記しています。しかも16496と16498は互いに排他で、同じ環境が両方に当たることはありません。stateful（既定）ならCVE-2026-16496、statelessをわざわざ指定していればCVE-2026-16498、という切り分けです。

バージョンで見ると、こうなります。ここに1つ食い違いがあるので、あとで別のセクションで触れます。

github-mcp-server側は、修正が入った1.1.0が5月末に出ていて、その後1.7.0まで進んでいます。リリース履歴を見るかぎり、普通に更新を追っている人はCVE番号が付いた時点でとうに直っている状態でした。

terraform-mcp-serverの3件を個別に見る

CVE-2026-16498: 前の人のトークンが次の人に使われる（CVSS 10.0）

HashiCorpの説明はこうです。stateless（状態を持たない）HTTPモードでは、土台になっているMCPライブラリがリクエストごとに固有のセッション識別子を割り当てません。ところがサーバー側は、Terraform APIクライアントの使い回し用キャッシュを「セッション識別子」で引く作りになっていました。識別子が実質空っぽなので、全員が同じ引き出しを共有してしまい、あるテナントが渡した資格情報が、次に来た別テナントのリクエストにそのまま使われた——という流れです。

重さの正体は、攻撃らしい操作が一切要らないところにあります。誰かが細工をしなくても、同じサーバーに2人がぶつかった時点で起きます。CVSSベクタは AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:L。権限も利用者の操作も不要、しかもスコープ変更（S:C）あり、という組み合わせで10.0に届いています。2026年6月11日の正式提供開始（GA）のアナウンスでは、共有サービスとして立てても「利用者それぞれが自分のTerraformトークンで個別のアクセス制御を保てる」と説明されていました。この脆弱性は、まさにその前提が成立していなかったという話になります。

この不具合はHashiCorpの内部チームが自ら見つけたもので、外部からの報告ではありません。CISAが公開している判定指標（SSVC）では、悪用の観測は「なし」、自動化のしやすさは「あり」と評価されています。

CVE-2026-16496: セッション番号を知られると乗られる（CVSS 8.9）

stateful（状態を持つ）モードの側の問題です。こちらはセッションごとにTerraformクライアントをキャッシュしますが、そのキャッシュを引くキーがMCPのセッションIDだけで、そのキャッシュを作った時のトークンと結び付けていませんでした。他人のセッションIDを手に入れた人が、自分のリクエストにそれを載せるだけで、被害者のクライアントとトークンで処理が走ります。共有サーバーとして動かすときの既定がこのstatefulモードなので、「HTTPで共有している」構成のほとんどはこちらに当たります。

この1件だけは外部からの報告で、Coinspect社のJuan Pablo Martinez Kuhn氏がHashiCorpへ届けたものです。ベクタは AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:H/A:L。攻撃複雑度がHighになっているのは、前提として他人のセッションIDを入手する必要があるからです。HashiCorpも回避策として「MCPのセッションIDを機密情報として扱うこと」を挙げています。ログやプロキシのアクセス記録にセッションIDが平文で残っていないか、更新前に見ておく価値があります。

CVE-2026-14869: 宛先を書き換えてトークンを持ち出す（CVSS 8.6）

3件のなかで、これがいちばん「攻撃」らしい形です。terraform-mcp-serverは接続先のTerraformアドレスを設定として受け取り、そこへサーバー側のトークンを付けて通信します。HTTPリクエストを受ける処理は、このアドレスがHTTPヘッダーで送られてきた場合には拒否していました。ところが同じ値をURLのクエリパラメータで渡した場合には、同じ検査をしていませんでした。結果、攻撃者は自分のサーバーのアドレスをクエリに付けてリクエストを1本投げるだけで、サーバーの認証トークンを自分の手元へ届けさせられます。

HashiCorpは「streamable-HTTPの受け口へHTTPリクエストを送れさえすれば成立し、認証は不要」と明記しています。外部からの通信が届く形で立てていた場合、いちばん現実的な脅威はこれです。1.1.0の変更履歴では、クライアントからのTFE_ADDRESS指定をstreamable-HTTPモードで一律に無効化し、サーバー側の環境変数だけで決めるように変えたと書かれています。仕組みとして「クライアントが宛先を決める」余地を消した対応です。この構造そのものは、AI連携ツールから認証情報が外部へ流れるmcp-grafanaの脆弱性とよく似た形をしています。

GitHub公式MCPサーバーの1件は「落とされる」タイプ

CVE-2026-47427: refが無いリクエストでプロセスが落ちる（CVSS 7.5）

こちらは資格情報の話ではありません。github-mcp-serverのpkg/github/server.goにあるCompletionsHandlerが、params.Refがnil（値が無い状態）かを確かめずに参照していました。そのためcompletion/completeというリクエストからrefの項目を落として送ると、Go言語のランタイムパニックが起きてプロセスごと終わります。GitHubのアドバイザリには実際のリクエスト例まで載っており、パラメータを空の{}にするだけで再現します。報告者はファジング（機械的に壊れた入力を大量に投げる検査）で925件のうち108件、11.7%でクラッシュを確認したとも書いています。

修正コミットはごく短いもので、req・req.Params・req.Params.Refのいずれかがnilならエラーを返して抜ける、という3行が入っただけです（テストが24行）。この修正は2026年5月19日にマージされ、1.1.0で出荷されています。

修正が出てから番号が付くまでの流れ

4件とも、CVE番号が公開された時点で修正版はすでに出回っていました。github-mcp-server側は報告から公開までの経緯が本人の記録として残っているので、そこも含めて並べます。

← スワイプで移動

公開された情報に食い違いがある

一次情報を突き合わせると、数字と説明が合っていない箇所が3つあります。過大にも過小にも読まないために、そのまま書いておきます。

1つ目は影響範囲の下限です。HashiCorpの告知は「terraform-mcp-server 0.2.1から1.0.0まで」と書いていますが、同じHashiCorpが登録元として提出したCVEレコードは「0.3.0以上1.1.0未満」になっています。0.2.1と0.2.xが対象かどうかで両者が食い違っており、しかも告知の側は上限を1.0.0としているため、1.0.0より上で1.1.0未満のバージョンの扱いも読み取りづらい状態です。0.2.1以降を使っているなら対象とみなして更新するのが安全側の判断になります。

2つ目はCVE-2026-16496の前提条件です。HashiCorpの告知の要約部分は「認証済みの利用者が他人のキャッシュ済み資格情報にアクセスできる」と書いていますが、CVSSベクタはPR:N、つまり権限は不要という設定です。詳細の記述を読むと実態は「他人のセッションIDを入手した者」であり、そこは攻撃複雑度AC:Hに織り込まれています。誰でもすぐ試せる類ではなく、セッションIDの漏れが前提だという読み方が実情に近いです。

3つ目はCVE-2026-47427の深刻度に対する開発側の見方です。アドバイザリとNVDの説明は「JSON-RPCを送れる無認証のクライアントなら誰でも即座にサーバーを落とせる、完全なサービス停止」となっており、CVSSも可用性への影響を最大（A:H）として7.5が付いています。一方、修正を入れたPull Request #2502の説明では、影響について「ローカルのstdio運用では自分のプロセスが落ちるだけ（信頼境界は起動元のクライアント）」「リモート運用では無認証では到達できず、トークンが必要なので、最悪でも認証済みの呼び出し元が自分のセッションを落とすだけ」と書かれ、そのうえで「通常の堅牢化として直す価値はある」と結ばれています。同じ穴について、番号と点数は「無認証で完全停止」、修正した側の説明は「自己DoS」という開き方をしているわけです。どちらが正しいかを当サイトで断定はできませんが、7.5という数字だけを見て緊急扱いにする前に、自分の環境が無認証で叩ける状態にあるのかを確かめたほうが判断を誤りません。

なお、GitHubのアドバイザリのページ本文には、報告時点の記述である「影響: 0.33.0以下」「修正版: なし」が今も残っています。一方で同じアドバイザリの機械可読データ（GitHub Advisory API）は「1.1.0未満が対象・1.1.0で修正」を返します。読む場所によって結論が変わるので、判断は機械可読データ側とNVDの記述に合わせるのが確実です。

1.1.0への更新は設定の見直しが必要になる場合がある

terraform-mcp-serverの1.1.0は、脆弱性の修正と一緒に互換性を壊す変更を2つ含んでいます。「更新すれば終わり」と考えて動かなくなるパターンがあるので、先に押さえてください。変更履歴に明記されている内容です。

• クライアントがヘッダーやクエリでTFE_ADDRESS（接続先アドレス）を渡していた場合、1.1.0では403が返ります。アドレスはサーバー側の環境変数で指定する形に変わりました（CVE-2026-14869の修正）
• プロキシ経由でX-Forwarded-Forによる接続元IPの引き継ぎに頼っていた場合、既定が安全側のRemoteAddrに変わったため、MCP_REMOTE_IP_METHODとMCP_XFF_TRUSTED_HOPSを明示する必要があります

1.1.0にはCVE番号が付いていない安全側の修正も入っています。組織の許可リスト（allowlist）の検証と実際のTerraform API呼び出しで別のトークンが使われうる不具合を直した、という項目です。矛盾するTFE_TOKENヘッダーを送ると許可リストを迂回できた、と読める内容で、これも共有運用の前提を崩す種類の問題でした。CVE番号だけを追っていると見落ちる部分です。Argo CDの脆弱性のときと同じで、インフラ操作系のツールは変更履歴を直接読む価値が高いです。

HashiCorpの推奨は「リスクを評価し、1.1.0への更新を検討すること」という表現で、10.0の脆弱性を含む告知としてはかなり控えめな言い回しです。すぐ上げられない場合の回避策としては、streamable-HTTPの受け口へのネットワークアクセスを信頼できる利用者だけに絞ること、MCPのセッションIDを機密情報として扱うことが挙げられています。

国内での注意喚起はまだ出ていない

この4件について、日本国内の公的な脆弱性情報データベースには記載を確認できませんでした。IPAとJPCERT/CCが運営するJVN iPediaを「terraform」「MCP」「HashiCorp」および各CVE番号で検索しましたが、該当0件でした（2026年7月29日13時時点）。JPCERT/CCの注意喚起、IPAの重要なセキュリティ情報にも該当の掲載は見つかりません。

日本語での解説記事も、はてなブックマークとZennを検索した範囲では見当たりませんでした。MCPサーバー一般のセキュリティを扱った日本語記事は存在しますが、今回の4件を扱ったものは確認できず、日本語での整理は当サイトが最初になる可能性があります。Terraformは国内のインフラ運用でも定番のツールで、しかも欠陥が出たのはHashiCorp公式・GitHub公式という、「他人が作った野良ツール」ではない側です。社内の誰かが便利だからと共有サーバーを立てている、というケースは十分あり得ます。

規模については正直に書きます。terraform-mcp-serverのGitHubリポジトリのスター数は約1,480で、31,800を超えるgithub-mcp-serverと比べると利用者は少ないほうです。さらに、影響を受けるのはHTTPで共有している構成だけなので、該当する組織の数はもっと絞られます。ただ、該当する組織にとっては「共有しているからこそ、複数人のTerraform権限がまとめて危ない」という話になり、数字はそのまま降ってきます。

実際に攻撃されている兆候はあるのか

現時点で、悪用が観測されているという情報はありません。米国CISAが公開する「実際に攻撃に使われている脆弱性の一覧」（KEV）を確認したところ、カタログ版2026.07.27の1,655件に4件はいずれも含まれておらず、HashiCorp製品の登録自体がありません。KEVの中身はCISA KEVダッシュボード（日本語版）から追えます。

悪用される確率を推定するEPSSスコアも、4件すべて未算出です（FIRSTのAPIで照会し、該当データなし）。公開翌日なので、数日から1週間ほどで値が付き始めるはずです。CISAの判定指標（SSVC）では、terraform-mcp-serverの3件は悪用の観測「なし」、CVE-2026-47427だけは「PoCあり」と評価されています。これはアドバイザリ本文に再現用のリクエストが載っているためで、実際に攻撃が起きているという意味ではありません。

MCPサーバーはGo言語やPythonのパッケージとして配布され、依存関係の一部として入り込むことも多いので、自分の環境に古い版が残っていないかはOSSサプライチェーンスキャナーのような仕組みで機械的に洗い出すのが早いです。

MCPサーバーで同じ形の穴が続いている

ここからは筆者の見解です。事実の整理とは分けて読んでください。

当サイトはこの1年でMCPサーバーの脆弱性を何本か扱ってきました。mcp-pinotは初期設定のまま誰でも接続できる状態でCVSS 10.0、mcp-server-kubernetesはクラスタ管理者の認証情報が抜かれる9.8、LiteLLMはMCP機能の窓口からコマンドを通されて実際にCISA KEV入り、そしてmcp-grafanaは認証情報の持ち出し。並べると、原因の言葉は違っても着地点はいつも同じです。認証や権限の境界が、MCPという新しい層に引き直されていない。

今回の3件が示しているのは、その一段先の問題だと思います。mcp-pinotやmcp-server-kubernetesは「認証を掛け忘れた」に近い話でした。今回のterraform-mcp-serverは、利用者ごとにトークンを受け取って権限を分ける設計が入っていて、そこは考えられていました。それでも「誰のトークンだったか」を保持する場所の作りを間違えると、認証の設計があっても意味を失うのです。セッションIDをキャッシュのキーにする、という一見ふつうの実装が、セッションIDを発行しないモードと組み合わさった瞬間に全員のトークンを混ぜてしまう。設計の抜けではなく、状態の持ち方の抜けでした。

そしてもうひとつ。MCPサーバーは「自分のパソコンでAIに道具を持たせる」ものとして広まりましたが、便利だからチームで共有する、という流れは自然に起きます。その瞬間に、単一利用者を前提に書かれたコードがマルチテナントのサーバーになる。今回の3件はどれも、stdio運用では発生せず、共有した瞬間だけ出てくるものでした。MCPサーバーを共有化するというのは、実質的に社内向けの認証プロキシを自作するのと同じ重さの作業になっている、というのが今の実感です。共有するなら、その手前に自分たちの認証と経路の制御を置く前提で考えたほうがいい、と思います。

1.1.0へ上げる前に決めておくこと

まず、自分の環境でterraform-mcp-serverをstreamable-HTTPで動かしているかを確認します。stdioだけなら緊急性はありません。次の更新のタイミングで1.1.0に上げれば十分です。HTTPで立てているなら1.1.0へ上げますが、前述の互換性を壊す変更（TFE_ADDRESSの扱いとX-Forwarded-Forの設定）を先に確認してください。すぐ上げられない場合は、受け口に到達できる範囲を信頼できる利用者だけに絞るのが回避策になります。

HTTPで共有していた期間があるなら、更新だけで終わりにしないほうがいいです。CVE-2026-16498はstatelessモードで攻撃なしに発生しますし、CVE-2026-14869は認証不要で成立します。サーバー側が持っていたTerraformのトークンは、外部へ渡った可能性を前提に入れ替えるのが安全です。Terraform Cloud / Enterpriseの監査ログで、自分たちの操作と一致しないワークスペースの参照や変数の読み出しが無いかも見ておく価値があります。

github-mcp-serverのほうは、1.1.0以降を使っていればすでに直っています。現在の最新は1.7.0です。0.x系や1.0.x系のまま止まっている環境があれば、CVE-2026-47427以外の修正も溜まっているので、そこを上げるほうが先です。

参照元

• ▸ HashiCorp - HCSEC-2026-23: Multiple vulnerabilities impacting HashiCorp Terraform MCP Server（2026年7月28日）
• ▸ NVD - CVE-2026-16498（CVSS 10.0 / CWE-488）
• ▸ NVD - CVE-2026-16496（CVSS 8.9 / CWE-384）
• ▸ NVD - CVE-2026-14869（CVSS 8.6 / CWE-918）
• ▸ NVD - CVE-2026-47427（CVSS 7.5 / CWE-476）
• ▸ GitHub Security Advisory - GHSA-w4q6-qw23-4rg7
• ▸ hashicorp/terraform-mcp-server - CHANGELOG（1.1.0）
• ▸ hashicorp/terraform-mcp-server - Releases
• ▸ github/github-mcp-server - PR #2502（nilガード追加）（2026年5月19日）
• ▸ github/github-mcp-server - 修正コミット c88d2ec
• ▸ HashiCorp - Terraform MCP server is now generally available（2026年6月11日）
• ▸ HashiCorp Developer - Security model for Terraform MCP server
• ▸ CISA - Known Exploited Vulnerabilities Catalog
• ▸ FIRST - EPSS（Exploit Prediction Scoring System）