AIにコードを渡す人気ツール『Repomix』に深刻な脆弱性、公開サーバーが踏み台にされ内部情報流出の恐れ CVE-2026-59702、1.14.1へ更新を

ソースコードをまるごと1つのファイルにまとめ、ChatGPTやClaudeなどのAIに読み込ませるための人気ツール Repomix（リポミックス） に、深刻な脆弱性が見つかりました。番号は CVE-2026-59702、深刻度はCVSS 9.3（Critical、10点満点）です。誰でも、ログインすらせずに攻撃できます。

問題があったのは、ブラウザ上でリポジトリのURLを貼り付けるだけで使える公式Web版「repomix.com」の裏側で動くサーバー機能です。攻撃者が細工したURLを送り込むと、Repomixのサーバー自身を踏み台にして、そのサーバーが動くクラウドの内部情報を勝手に読み出せる――いわゆるサーバーサイド・リクエスト・フォージェリ（SSRF、サーバーを騙して意図しない通信をさせる攻撃）が成立しました。実際に狙われ得たのは、Repomix公式サイトが動く Google Cloud Run 上の本番環境です。

修正版は Repomix 1.14.1 です。脆弱性の情報を管理する VulnCheck によれば、1.14.1より前のすべてのバージョンが対象です。公式サイトの repomix.com はすでに修正済みですが、Repomixのこのサーバー機能を自分のサーバーで公開して運用している人は、いますぐ1.14.1へ更新してください。パソコン上でコマンドとして使うだけの人（後述）は、このSSRFの直接の対象ではありませんが、同じ1.14.1で別の脆弱性も直っているため、あわせて更新をおすすめします。記事公開時点で 米政府CISAが公開する「実際に攻撃されている脆弱性リスト（KEV）」への登録や、実被害の報告は確認されていません。

Repomixとは何か、なぜこの穴が怖いのか

Repomixは、日本の開発者 yamadashy 氏が公開しているオープンソースのツールです。プログラムのソースコードは何十、何百というファイルに分かれていますが、これをAIに読ませようとすると「どのファイルから貼ればいいのか」で手間がかかります。Repomixは、リポジトリ（ソースコードの保管場所）全体を 1つのAI向けファイルにまとめてくれる ため、Claude・ChatGPT・Gemini などに自分のコードを丸ごと渡して質問する、いまどきのAIコーディングの定番ツールになっています。GitHubのスターは2万を超え、Claude Code周りの便利ツールとしても頻繁に名前が挙がります。

使い方は大きく3つあります。①パソコンにコマンドとして入れて手元で動かす方法（npx repomix）、②ブラウザで repomix.com を開き、GitHubのURLを貼り付けてまとめてもらう方法、③AIアシスタントと直接つなぐMCP連携です。今回の穴があったのは、このうち ②のWeb版を動かしているサーバー側の仕組み です。

Web版は、利用者が入力したリポジトリのURLをサーバーが受け取り、そのURLに対して git clone（コードのコピーを取得する操作）を実行して、結果をまとめます。ここで問題になるのが、「利用者が入力したURLを、サーバーがそのまま信じて通信してしまう」 という点です。攻撃者は「GitHubのリポジトリ」を装いつつ、実際にはサーバーの内側にしか見えないアドレスを指定できます。すると、サーバーは自分の内部に向けて通信を始めてしまいます。これがSSRFという攻撃です。外からは触れないはずのクラウドの管理用アドレスや、社内ネットワーク、サーバー上のファイルに、サーバー自身を代理人として使ってアクセスされてしまう のが、この脆弱性の怖さです。

攻撃者は誰で、何を狙い、どこまで被害が届くのか

「SSRF」と聞いてもピンと来ないと思うので、まず攻撃の届く範囲をはっきりさせます。今回の穴は、Repomixを使う人すべてが等しく危ないわけではありません。どの使い方をしているか で、自分ごとかどうかが決まります。

この穴を狙って得をするのは、いたずら目的の愉快犯ではありません。クラウド上で動くサービスに片っ端からSSRFを仕掛け、そのクラウドの認証情報（鍵）を盗んで乗っ取りにつなげる、金銭目的の攻撃者やボットです。彼らが本当に欲しいのは、Repomixがまとめたソースコードそのものではありません。Repomixのサーバーが動いているクラウド（今回はGoogle Cloud）の「管理用アドレス」にサーバー自身を通じてアクセスし、そのサービスに紐づいたアクセス用トークン（鍵）を抜き取ることです。

クラウド上のサーバーには、自分自身の設定や権限を確認するための特別なアドレス（メタデータサービス）が用意されています。これは本来、そのサーバーの内側からしか触れない前提で、外部に公開されていません。ところがSSRFが成立すると、攻撃者は「サーバー、あなた自身の管理用アドレスにアクセスして、その結果を見せて」と命令できます。ここから吸い出せるのが、そのサーバーがクラウドの他のサービスにアクセスするための鍵です。この鍵を握られると、攻撃者は正規のサーバーになりすまして、データベースやストレージなどクラウド上の他の資産へと侵入を広げていけます。

被害を受けるのは、まずそのWebサービスを運用している側です。クラウドの鍵が漏れれば、保管しているデータの流出、不正な課金、サービスの改ざんにつながります。そしてサービスを使っていた一般の利用者も、自分が貼り付けたコードや、サービスに預けた情報が巻き添えで漏れる 恐れがあります。「URLを貼るだけの便利な無料ツール」の裏側で、こうした深刻な事態が起こり得たわけです。Repomix公式サイトはすでに修正済みですが、同じ仕組みを自前で立てて公開している場合は、他人事ではありません。

何が起きていたのか、技術的な詳細

問題は、Web版の裏側にある POST /api/pack という受け口にありました。ここは利用者が指定したリポジトリのURLを受け取り、まとめ処理を始める入口です。報告された不具合（Issue #1703） によれば、URLの正しさをチェックする isValidRemoteValue という関数が、URLの「持ち主/リポジトリ名」の形（owner/repo）になっているかしか見ていませんでした。

この検査は git-url-parse というライブラリでパスの部分を取り出し、[a-zA-Z0-9._-]+/[a-zA-Z0-9._-]+ のような「英数字/英数字」の並びに当てはまればOK、という緩いものでした。そのため、URLの先頭が http:// でも https:// でも、さらにはサーバー上のファイルを指す file:// であっても、末尾が「なにか/なにか」の形になってさえいれば検査を通過し、そのまま git clone に渡されてしまいました。実際にIssueで示された例が、次の3つです。

2つ目の http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token が、この脆弱性の最も危険な使い方です。これはGoogle Cloud上のサーバーが自分の権限用トークンを取り出す標準的なアドレスで、SSRFでここを叩ければ、そのサーバーになりすますための鍵がまるごと手に入ります。VulnCheckの評価が、機密情報の漏えい（読み取り）に重く振れたCVSS 9.3となっているのは、この「クラウドの鍵に届く」という点が効いています。1つ目の内部アドレスは社内ネットワークの探索、3つ目の file:// はサーバー上のファイル読み出しに使えます。VulnCheckのアドバイザリ は、内部のRedisなど他のサービスへの到達可能性にも触れています。

修正は、Pull Request #1706 で、URLの検査を厳しくする形で行われました。git のリポジトリとして妥当なもの以外の通信先（内部アドレスや file:// など）をはじくようになっています。この種の「入力されたURLへサーバーが通信する」機能は、過去にAIツールLangflowで公開直後に攻撃が始まった事例 と同じく、便利さと危険が背中合わせの典型的な急所です。Repomixのようにコードや依存関係を扱う開発ツールは、オープンソースのサプライチェーン（部品供給網） の上流に位置するため、踏まれたときの波及が大きくなりがちです。

発覚から修正までの時系列

← スワイプで移動

最初の非公開報告は2026年6月2日でしたが、修正までしばらく時間がかかり、7月5日に 実証コードを含む詳細 が公開情報になりました。CVE番号 CVE-2026-59702 が振られたのは7月8日です。報告したのはセキュリティ研究者の geo-chen 氏です。

いますぐやること

対応は、Repomixをどう使っているかで変わります。

• Web版を自分のサーバーで公開している場合：最優先で Repomix 1.14.1以降 へ更新してください。更新できない事情がある場合は、そのサーバーからクラウドの管理用アドレス（メタデータサービス）や内部ネットワークへ出ていく通信を遮断する、外部からアクセスできる範囲を絞る、といった応急対応を検討します。
• 公式サイト repomix.com を使うだけの場合：サイト側はすでに修正済みで、利用者の手元での操作は不要です。ただし、この種の「URLを貼るだけ」の無料サービス全般に言えることとして、機密性の高い非公開リポジトリを外部サービスに渡す運用そのものは慎重に判断してください。
• パソコンでコマンドとして使うだけの場合：今回のSSRFの直接の対象ではありません。ただし同じ 1.14.1 では、細工したブランチ名からコマンドが実行され得る別の脆弱性（CVE-2026-49987）や、AI連携（MCP）での情報漏えいも修正されているため、あわせて更新をおすすめします。

Repomixが動くサーバー機能そのものは npmパッケージ の一部として配布されているため、CI/CDや社内ツールに組み込んで動かしているケースでも、バージョンの確認と更新を行ってください。

技術者として見ると、繰り返される「URLを信じすぎる」問題

今回の根っこは、ユーザーの入力したURLを、通信の直前まで十分に絞り込まなかった という一点です。URLの「形」がGitのリポジトリらしく見えるかどうかだけを確認し、通信先が内部アドレスかどうか、プロトコルが http/https/file のどれかを弾くべきか を見ていませんでした。SSRF対策の定番は、URLの文字列パターンではなく 実際に解決されるIPアドレスを見て、内部向け（プライベートアドレスやクラウドのメタデータ用アドレス）を拒否する ことです。文字列マッチだけの検査は、git-url-parse のような寛容なパーサーと組み合わさると、今回のようにあっさり抜けます。

この構図は、開発者向けツールで何度も繰り返されています。AIツールLangflowが公開直後に攻撃された事例、データ基盤Snowflakeのコマンドツールの脆弱性、開発ツールmiseの脆弱性、AmazonのAI開発ツールKiroの脆弱性 など、AI時代に急に使われ始めたツールが、便利さを優先した実装のまま外部入力を受け取り、後から穴が見つかるパターンが続いています。Repomixは開発が活発で、報告から修正・公開まで一連の対応が取られている点はむしろ健全ですが、「入力されたURLへサーバーが自分から通信しに行く機能」は常にSSRFの温床 だという教訓は、あらゆる同種ツールに当てはまります。

なお本件は、7月8日のセキュリティ脆弱性まとめ でも触れた、この時期に相次いだ開発ツール系CVEの一つです。

よくある質問

まとめ

AIにコードを渡すための人気ツールRepomixに、公開サーバーを踏み台にして内部情報を抜き取れる深刻なSSRF（CVE-2026-59702、CVSS 9.3）が見つかりました。狙われ得たのは公式サイトが動くGoogle Cloud上の本番環境で、クラウドの認証鍵に届く点が最も危険です。公式サイトはすでに修正済みですが、同じサーバー機能を自前で公開している場合は、いますぐ1.14.1へ更新してください。 コマンドとして手元で使うだけの人も、同時に直っている別の脆弱性のために更新しておくのが安全です。「URLを貼るだけ」の便利さの裏で、サーバーが何と通信するのかを絞り込む――地味だが効く対策の重要性を、改めて突きつける一件です。

参照元

• ›NVD — CVE-2026-59702
• ›VulnCheck — Repomix SSRF Advisory
• ›GitHub Issue #1703 — SSRF via /api/pack
• ›GitHub Pull Request #1706 — 修正
• ›Repomix Releases（1.14.1）
• ›GitLab Advisory — CVE-2026-49987（同時に修正された別の脆弱性）
• ›Repomix 公式リポジトリ