CVE-2026-18953: AWSのTransform MCP Serverには書き込み境界が存在しなかった

Amazon は 2026年8月5日、CVE-2026-18953 に関するセキュリティ公告 2026-075-AWS を公開しました。これはget_resourceツール、つまりawslabs.aws-transform-mcp-server という、開発者自身のマシン上で動作し、AI アシスタントが AWS Transform ジョブを実行してその成果物を取得できるようにするオープンソース Model Context Protocol サーバーが提供するツールにおけるパストラバーサルです。バージョン 0.1.0 から 0.1.4 ではパス名を適切に制限しておらず、savePath パラメータは意図した作業ディレクトリ外にファイルを書き込む可能性がありました。Amazon のリポジトリにある GitHub アドバイザリでは、これは「ローカルでのコード実行につながる可能性がある」と述べています。Amazon はこれを 8.6（High）と評価しました。修正はバージョン 0.1.5 で、サーバー側または設定のみの回避策はありません。脆弱なコードパスがデフォルト設定に存在するためです。公開されている情報源で、これが悪用されたことを記録したものはありません。重大度と確信度の評価を含む完全な記録は、Orca AI Incident Archive にあり、同じ月に登録された MCP およびエージェントランタイムのインシデントと並んでいます。

開発者が作業する場所に書き込むMCPサーバー

Model Context Protocol サーバーは、アシスタントに呼び出し可能なツールを提供するレイヤーであり、これは意図的にローカルで動作します。Amazon の告知では、「開発者のマシン上でローカルに動作するオープンソースの MCP サーバーで、AI を活用したアシスタントが AWS Transform と連携してコード変換ジョブを実行し、その成果物を取得できるようにするもの」と説明されています。Python Package Index のパッケージ説明によると、19 個のツールを通じて Transform のライフサイクルを公開し、変換ワークスペース、ジョブ、コネクタ、ヒューマン・イン・ザ・ループのタスク、成果物、チャットを管理し、メインフレームのモダナイゼーション、VMware 移行、.NET モダナイゼーション、カスタムコード変換に対応しています。

その配置こそが、この欠陥を重大なものにしている。ベンダー自身のインフラ上にあるサーバーがファイル名を誤って処理すると、そのベンダーのストレージが破損する。今回のサーバーは開発者として、開発者のホームディレクトリ内で、そのシェル設定やSSH鍵の隣で動作しており、Amazonが説明する影響はダウンロードの破損ではなく「ローカルでのコード実行」である。このCVEに付されたすべてのスコアは、一点で一致している。攻撃ベクトルはネットワークではなくローカルである。

アドバイザリで名前が挙げられているツールは、ジョブ成果物をディスクにダウンロードするものです。get_resource は savePath を受け取り、ファイルの保存先を指定します。バグは、そのパスが別の場所を指定することを何も阻止しなかったことです。

どれほど悪いのか、そしてそれは誰の計算によるのか

このCVEには3つのスコアが付されており、それらは一致していません。CVEの採番機関としてこのCVEを割り当てたAmazonは、CVSS v3.1でベクトルCVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:Hを使い8.6のHighと評価しています——ローカル、低複雑性、権限不要、ユーザー操作要、スコープ変更、機密性・完全性・可用性への高い影響です。NISTによるNational Vulnerability Databaseの登録項目は、独自のプライマリv3.1スコア8.8を別のベクトルCVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:Hで持っています：低権限が必要、ユーザー操作不要です。どちらもHigh帯に入ります。相違は前提条件——攻撃者がすでに足がかりを必要とするか、人間を説得する必要があるか——に関することであり、結果がどれほど深刻かについてではありません。

同じCVEに対するAmazonのCVSS v4.0スコアは、CVSS:4.0/AV:L/AC:L/AT:N/PR:N/UI:P/VC:N/VI:N/VA:N/SC:H/SI:H/SA:Hでは6.3、Mediumです。影響指標を読み取ると、脆弱なシステム自体には何もなく、後続システムではすべてが高です。これは、ツール自身の境界を突破するトラバーサルの形です。被害はツールが到達できるあらゆるものに及び、そのためサブシステム列に計上され、脆弱なシステムのスコアはゼロになります。

CISAによるCVEのエンリッチメント（2026年8月6日付）には、SSVCの判定として Exploitation: none、Automatable: no、Technical Impact: total が記録されています。NVDのレコードは2026年10月23日に最終更新され、依然として8.6と8.8の両方を並記しています。どちらの文書も、他方を誤りとして扱っていません。

脆弱なコードが何をしていたか、そして0.1.5で何が変わったか

Amazonによるこの仕組みの説明は一文だけで、しかも慎重に書かれている。同ツールは「パス名を適切に制限していなかった」ため、「状況依存のアクター」が「savePathパラメータを介して意図された作業ディレクトリ外に任意のファイルを書き込む」可能性がある。勧告はそのアクターを定義しておらず、何が書き込みの引き金になるかも述べておらず、悪用が成功した場合にどのような状態になるかも説明していない。ただ、その結果が「ローカルでのコード実行につながる可能性がある」とだけ述べている。

このメカニズムについて最も詳細に公開されている解説は、Amazonのものではない。それは小さな概念実証リポジトリ、ronamosa/CVE-2026-18953であり、2026年8月8日にApache-2.0の下でGitHubに公開された——執筆時点でコミットは2件、スターもフォークもなし——脆弱な版とパッチ適用済み版のfile_validation.pyをそのままコピーして同梱し、両方に同じ入力を通して実行するものである。

0.1.4 の解釈は次のとおりです: validate_write_path()解決しsavePath を realpath および expanduser、場所の短い拒否リスト（~/.aws、~/.ssh、~/.gnupg、~/.docker、~/.aws-transform-mcp、/etc/shadow、/etc/passwd）を拒否し、指定されたファイル名からディレクトリ部分を除去しました。解決されたパスをベースディレクトリや作業ディレクトリに限定することは決してありませんでした。機密性の高いファイル名 — .bashrc、.zshrc、authorized_keys、id_rsa — のブロックリストは読み取り時には適用されましたが、書き込み時には適用されませんでした。

このリポジトリは、これによって許可される 3 つの書き込みを示しています。すなわち、トラバーサルをまったく必要としない絶対パス、相対的な ../../ によるエスケープ、そして読み取りパスなら拒否していたはずのドットファイル名です。3 つとも、スクリプトが作成する一時ディレクトリ内に収まり、そのサンプル出力には dropped_by_absolute_path.sh、dropped_by_traversal.sh と .bashrc がデコイのホームディレクトリ配下にあることが示されています。実際のホームディレクトリには一切触れません。バージョン 0.1.5 は、欠けていた境界を追加します。それは、$AWS_TRANSFORM_MCP_WRITE_DIR またはサーバーの起動時作業ディレクトリから取得したベースディレクトリ（解決されたすべての書き込みがその配下に収まる必要があります）と、最終的に解決された書き込みパスに適用されるファイル名のブロックリストです。修正済みのバリデータは、3 つすべてに対して「Write path must be within the working directory」を発生させます。

そうした詳細はアドバイザリには一切現れておらず、リポジトリもそれがそこから来たと主張しているわけではありません。拒否リスト、読み取り専用のファイル名チェック、ベースディレクトリの修正は、ソースコードからの再構成として扱い、2つ目の公式な指摘とみなさないでください。リポジトリがアドバイザリを超えて付け加えているのは、誰がパスを供給できるかについての説明です。サーバーの役割はジョブとタスクの内容をアシスタントのコンテキストに取り込むことであるため、savePathを選ぶ当事者は、必ずしもキーボードの前にいる人である必要はありません。同じツールを通じて取得した信頼できないコンテンツに誘導されたアシスタントが、その決定を行えるのです。それはコードとツールの設計に基づくリポジトリの主張であり、Amazonが述べている主張ではありません。Amazonの定義されていない「context-dependent actor」はそれと整合し、そこで止まります。

パッチから告知までの7週間

修正は発表と同時には届かなかった。Python Package Index のリリース履歴 — このパッケージが配布されるレジストリからの一次メタデータ — では、0.1.4 が 2026年5月20日、0.1.5 が 2026年6月17日となっており、これは bulletin 2026-075 が8月5日に公開される7週間前のことだ。インデックス上には 0.1.0 のファイルが一切存在せず、影響範囲内で最も早く公開された成果物は 0.1.1 で、2026年5月9日にアップロードされた。したがって、インデックスからインストールした開発者が脆弱なビルドを受け取ることは、5月9日から6月17日までの間にしかあり得ず、リリースを追跡していた人なら6月中旬にはすでに修正済みコードを使っていた。

Amazonは、この問題をいつ把握したのか、報告がいつ届いたのか、そしてそれをクローズしたリリースがなぜ出されたのかを明らかにしていない。記録に名前が挙がっている唯一の人物はDrew Rainesで、速報とGitHubアドバイザリの両方で「協調的な問題開示プロセスを通じてこの問題に協力したこと」に対して感謝の意が示されている。GHSA-66mr-jr63-2jgwは2026年8月5日にAmazonのawslabs/mcpリポジトリで公開され、それは速報と同じ日だった。CVEレコードは同日13:44 UTCに予約され、19:33 UTCに公開された。

修正の日付は確定しているが、その理由は確定していない。アドバイザリより7週間早くレジストリ上に置かれていたパッチ済みバージョンは、静かな修正の後に協調的開示が行われたという見方と整合する。しかしそれは2つのタイムスタンプからの推論であり、どちらの文書にもそのことは明記されていない。

記録が何を立証し、何を立証していないか

アーカイブはこのエントリをAと評価しており、十分に文書化され、一次資料も一致しているため、論争中とはしていない。これは配備時のインシデントではなく、脆弱性の発見として研究記録に分類され、実世界での被害は記録されていない。この評価は文書化の質に関するものであり、レビューした証拠に照らせば妥当である。公告、GitHubアドバイザリ、CVEレコードはAmazonが公開した3つの文書であり、製品、バージョン、修正、クレジットについて一致している。

・ 確定済み。Amazonは2026年8月5日に速報2026-075-AWSを公開し、CVE-2026-18953を扱った。これはawslabs.aws-transform-mcp-server 0.1.0～0.1.4におけるCWE-22パストラバーサルで、対象はget_resourcesavePath処理にあり、0.1.5で修正された。脆弱な経路がデフォルト構成に存在するため、サーバー側または構成のみによる回避策はない。

• 確定済み。スコアとその相違点：CVE採番機関としてのAmazonによる8.6 High、NVDの主要スコアとしてのNISTによる8.8 High、CVSS v4.0では6.3 Medium、そしてCISAの8月6日付SSVC判断では、悪用も自動化可能な経路も観測されていないとされていた。

• 確定しました。 Python Package Index のリリース日、および協調的開示に対する Drew Raines へのクレジット。

• 第三者によるソースコードからの推測。拒否リスト、読み取り専用ファイル名のブロックリスト、存在しないベースディレクトリ、および _ALLOWED_WRITE_BASE の修正はすべて、ronamosa の概念実証リポジトリに由来します。このリポジトリには、2つのバリデータバージョンのベンダー化されたコピーが含まれており、誰でも差分を確認できます。

• タイムスタンプと設計から推測される。 0.1.5が意図的なセキュリティリリースであったこと、また、信頼できないコンテンツに誘導されたアシスタントが敵対的なパスを提供し得ることを示している。Amazonはどちらも述べていない。

• 未確認。 実際の攻撃での悪用は不明。CISAの「Exploitation: none」は8月6日付で、公開された概念実証（PoC）が登場する2日前のものであるため、その時点の状況を指しており、それ以降の状況については何も示していない。影響を受けたユーザー数、顧客への通知、テレメトリは公開されていない。

• 確立されていない。独立した報道。このCVEを扱った主流メディアは見つからないようです。公開記録は、Amazonの3つの文書、NISTとCISAによるそれらの補足情報、記録をそのまま再掲するトラッカーページ、そして前述の1つの小規模な概念実証リポジトリです。

何が変更されたか、そして何を確認すべきか

Amazonの対策はバージョンを上げることだけだ。0.1.5以降へアップグレードし、「フォークまたは派生コードに、新しい修正を取り込むためのパッチが適用されていることを確認する」よう求める。広く当てはまるのは後半の文言だ。サーバーはオープンソースであり、0.1.4のバリデータを取り込んだフォークは、脆弱性を引き継ぐが勧告は引き継がない。この勧告は派生コードの運用者に対し、変更をそのコードに反映するよう求めている。つまり、上流のリリースは、他者が保守するコピーには届かない。

PoCリポジトリは、アドバイザリが避けて通る提案をしている。同リポジトリは、すぐにアップグレードできない運用担当者に対し、作業ディレクトリを専用の空ディレクトリに設定してサーバーを実行し、サーバーが書き込み可能なファイルはすべて侵害済みと見なすべきだとしている。Amazonの立場はより厳格で、サーバー側の回避策も設定のみの回避策もまったく存在しない。リポジトリ自身の説明によれば、その提案も根拠が薄い。そもそも脆弱なコードは書き込みを作業ディレクトリ内に限定していなかったからだ。両者が食い違う場合には、ベンダーの「アップグレードのみ」という指示が優先される。

この記録で役に立つのは、そのスコアではない。役に立つのはその形だ。ローカルの MCP サーバー、呼び出し側が指定した保存先へのアーティファクトのダウンロード、そしてその二つの間に境界がないこと。重要な確認は告知日ではなく、固定されたバージョン — 0.1.5 以降であり、バリデータをコピーしたあらゆるフォークにも同じ変更が取り込まれていることだ。