あなたのローカルホストはプライベートではありません：開発者環境をローカルホスト SSRFとDNSリバインディングから守る方法

ほとんどの開発者は localhost を信頼の境界とみなしています。127.0.0.1 にバインドされたものは自分だけがアクセスできると考えがちです。しかし、その前提はブラウザ、AIツール、開発サーバー、コンテナランタイムなどで何度も崩れています。

この記事では、2つの関連する攻撃クラスと、それらが開発者のマシンにどのように影響するか、過去2年間のブラウザの変更点、そしてそれらに対して何をすべきかを解説します。また、InstaTunnelのようなトンネリングツールが役立つ場面とそうでない場面についても触れます。

2つの攻撃クラスと誤った前提

ローカルホスト SSRF は、ループバックを狙ったサーバーサイドリクエストフォージェリです。アプリケーションが攻撃者が制御するURL（Webhookターゲット、画像URL、リンクプレビュー）をフェッチし、そのURLを 127.0.0.1、0.0.0.0、または内部アドレスに向けると、サーバーは信頼の境界内からリクエストを行い、外部からの呼び出しを想定していないサービスにアクセスします。

DNSリバインディング はブラウザからの攻撃です。被害者が攻撃者のページを訪れると、攻撃者のドメインは最初攻撃者のサーバーに解決され、その後 127.0.0.1 に解決されるため、リクエストは同一オリジンとみなされ続け、被害者のローカルサービスに到達します。Viteのアドバイザリでは、このチェーンを説明しています：攻撃者はDNSの回答を変更し、127.0.0.1や他のプライベートアドレスに向けさせ、Hostヘッダーの検証を行わないHTTPサーバーは区別できません。

どちらも同じ誤った前提に依存しています：ローカルポートに到達できることは呼び出し元が信頼できることを意味します。

0.0.0.0 Dayの脆弱性

2024年8月、Oligo Securityは【”0.0.0.0 Day”】を公開しました(https://www.oligo.security/blog/0-0-0-0-day-exploiting-localhost-apis-from-the-browser)。これは、主要なブラウザ（Chromium、Firefox、Safari）が`0.0.0.0`へのリクエストを処理する方法に関するロジックの欠陥です。Oligoは2024年4月にブラウザベンダーに報告していました。

• 仕組み。 Private Network Access (PNA)は、公開ウェブサイトがプライベートアドレスにアクセスするのを防ぐための仕組みです。しかし、0.0.0.0はプライベートやローカル範囲に含まれていません、そのためリクエストが通ってしまいます。
• 影響範囲。 この問題はmacOSとLinuxに影響し、Windowsには影響しません。Oligoの研究者は、公開サイトからホストの任意のポートにアクセスできるが、レスポンスを読むことはできないため、露出は主にブラインドの状態変更リクエストに関するものだと述べています。
• 歴史。 これは新しいものではなく、過去のバグ報告（2006年のMozillaへの報告）を反映しています。
• 修正。 Chromeは0.0.0.0をブロックし始めました（Chromium 128以降）、段階的に展開され、Chrome 133までに完了予定です。AppleはWebKitを変更しブロックしています。MozillaはFetch標準を変更し、これをブロックしていますが、当時Firefoxの修正はリリースされていません。

展開は不均一でした。Oligoが2025年のMCP Inspectorの脆弱性に関するレポートを公開した際も、ChromiumとFirefoxでは0.0.0.0の挙動は未解決のままでした。チームのすべてのブラウザが保護されていると考えないでください。

実際の悪用例：MCP Inspector

CVE-2025-49596は、MCPサーバーのテスト用開発ツールであるMCP Inspectorに影響しました。これはCritical（CVSS 9.4）と評価されました。バージョン0.14.1以前は、Inspectorクライアントとローカルプロキシ間に認証がありませんでした。0.0.0.0 Dayを利用したCSRFスタイルのリクエストを連鎖させることで、悪意のあるウェブサイトがそのプロキシにコマンドを送信し、開発者のマシン上でコードを実行できました。バージョン0.14.1は2025年6月13日にリリースされ、セッショントークンとホストチェックを追加しました。

AIツールの影響と悪化

ローカルのAIツールは、”ローカルだけ”だからと認証なしのHTTPやWebSocketサーバーをループバック上に稼働させる傾向があります。最近の事例を3つ紹介します。

MCP SDKs（2025年12月）。CVE-2025-66416（Python SDK、修正済みは1.23.0）とCVE-2025-66414（TypeScript SDK、修正済みは1.24.0）は、HTTPサーバーに対してDNSリバインディング保護をデフォルトで有効にしていなかったため公開されました。ローカルの未認証MCPサーバーは、悪意のあるウェブサイトからアクセスされ、そのツールを呼び出すことが可能でした。stdioトランスポートを使用するサーバーは影響を受けません。

ClawJacked（2026年2月） Oasis Securityは、任意のウェブサイトがローカルのOpenClawエージェントを乗っ取れることを示しました。ブラウザはクロスオリジンの理由でlocalhostへのWebSocket接続をブロックしないため、ページのJavaScriptがゲートウェイにソケットを開き、パスワードを推測できます。ゲートウェイはlocalhostをレートリミットから除外し、ローカルからのデバイスペアリングを自動承認していた、推測に成功すると永続的なアクセスが得られました。修正は約1日以内にリリースされました。

NVIDIA NemoClawとOllama（2026年8月） Oasis Securityは、悪意のあるウェブページがNemoClawの背後にあるOllamaインスタンスを乗っ取れると報告しました。Ollamaは自身のDNSリバインディングバグ（CVE-2024-28224）をv0.1.29で修正し、Hostヘッダーの検証を行っています。ただし、検証はOllamaが非ループバックアドレスにバインドされている場合はスキップされると記載されています。攻撃者はモデルのチャットテンプレートを書き換え、永続的な指示を埋め込むことが可能です。現時点でCVEはなく、2026年8月25日時点での報告では実際の悪用例はありません。研究者によると、NemoClawのバージョン0.0.35ではmacOSとLinuxに修正済みですが、WindowsとWSLには未対応です。最新の状態を確認してください。

教訓は、0.0.0.0へのバインドは、ループバック専用の保護を静かに無効にする可能性があるということです。

開発サーバーとコンテナランタイム

Vite（CVE-2025-24010）。修正前は、任意のウェブサイトが開発サーバーにリクエストを送り、レスポンスを読むことができました。これは、CORSの設定が緩く、WebSocketのOrigin検証が欠如していたためです。ローカルマシン上のサーバーにも適用されました。Vite 6.0.9、5.4.12、4.5.6で修正済みです。server.allowedHostsオプションはlocalhost、*.localhost、IPアドレスをデフォルトで許可します。Viteのドキュメントでは、これをtrueに設定するとDNSリバインディングを許すことになると警告しています。

Docker Desktop（CVE-2025-9074）。DockerのEngine APIは、192.168.65.7:2375に認証なしでアクセス可能でした。この脆弱性はCVSS 9.3と評価され、Docker Desktop 4.44.3で修正済みです。WindowsとmacOSに影響し、Linuxには影響しません（Linuxはローカルソケットを使用）。SOCRadarはこれをSSRFと分類しています：コンテナ内部からのリクエストが、信頼できると想定されたコントロールプレーンに到達しました。

ブラウザの対応

Chromeの以前の計画、Private Network AccessとCORSプリフライトは保留になっています。Chromeは一時的に0.0.0.0/8をPNAのローカル範囲に追加しました。

新しい仕組みはLocal Network Access (LNA)です：

• Chrome 142（2025年10月28日）は、公開サイトからローカルまたはループバックアドレスへのリクエストを許可前に確認ダイアログを表示。他のChromium系ブラウザも追従しています。
• Chrome 145では、許可をlocal-networkとloopback-networkに分割しました。詳細はChromeの追跡issue。同じissueでは、Chrome 147がWebSocketやWebTransportへの制限を拡大し、一時的な企業向けの設定除外ポリシーはChrome 156で廃止予定としています。
• Firefoxも同様の確認ダイアログを導入しています。 Mozillaのサポートページによると、バージョン149からStrictなEnhanced Tracking Protectionを有効にしているユーザーに適用され、バージョン151から段階的に全ユーザーに展開されています。

これらは確かに改善ですが、防御層の一つです。ユーザーに確認を促し、クロスサイトリクエストを制御しますが、認証されていないローカルサービスを安全にするわけではありません。DNSリバインディングやマルウェアは別の問題です。リバインディングの標準的な対策は、NemoClawの研究でも述べられているように、HostとOriginヘッダーの検証です。ブラウザの制御は第二の層とみなしてください。

アプリの強化：チェックリスト

1. すべてのローカルサービスに認証を設定しましょう。ランダムなトークンを使い、「localhostだけだから大丈夫」は避けてください。CVE-2025-49596やClawJackedの原因は認証の欠如または弱さにあります。
2. Hostヘッダーの許可リストを作成し、それ以外を拒否します。これがDNSリバインディング対策の核心です。ワイルドカードや「すべて許可」は避けてください（例：ViteのallowedHosts: true）。
3. Originの検証を状態変更リクエストやWebSocketのアップグレード時に行います。CORSはWebSocketには適用されません。
4. ローカルもレート制限を適用し、ループバックからのペアリングや登録を自動承認しないこと。
5. 127.0.0.1にバインドし、0.0.0.0は必要な場合のみ。コンテナやWSLの設定で広くバインドされている場合は、どのホストチェックが有効か確認してください。
6. stdioやローカルソケットをTCPより優先しましょう。MCPのstdioトランスポートはブラウザ攻撃に曝露されませんし、DockerのLinuxアーキテクチャも同様です。
7. パッチ適用。上記のバージョンは最低限です：Vite 6.0.9 / 5.4.12 / 4.5.6、MCP Inspector 0.14.1、MCP Python SDK 1.23.0、MCP TypeScript SDK 1.24.0、Ollama 0.1.29、Docker Desktop 4.44.3。

サーバーサイドのfetcher（localhost SSRF）の強化

バックエンドがユーザー提供のURLをフェッチする場合は：

• 許可リストを優先しましょう。 OWASP SSRF Prevention Cheat Sheetは、拒否リストは回避されやすいと述べています。可能な場合は、ホストを既知の宛先と照合し、自分でリクエストを構築してください。
• すべてのローカル表現をブロックします。OWASPは127.0.0.0/8、0.0.0.0/8、::1/128をローカルとしています。公開のバイパスリストには多くのバリアントがあります：127.1、0、[::]、10進数の2130706433、16進数の0x7f000001、IPv4-mapped IPv6など。
• 解決後に検証し、固定します。AレコードとAAAAレコードを両方調べ、ブロック範囲に含まれるか確認し、検証済みのIPに接続します。そうしないと、ホスト名が検証を通過しても、実際のリクエスト時にプライベートアドレスに再解決される可能性があります。
• リダイレクトも再検証します。リダイレクト先も同じ検査を行います。
• リンクローカルやプライベート範囲をブロックします。クラウドのメタデータアドレス169.254.169.254も含みます。

トンネルの役割

トンネルはあなたの露出を逆転させます：あなたのブラウザだけがアクセスできるローカルサービスの代わりに、URLを知っている誰でもアクセスできるサービスになります。WebhookやOAuthコールバック、デモ、MCPのテストに便利ですが、その場合は上記のチェックリストを必須にしてください。

トンネルは上記の問題を解決しません。Hostの検証やMCPエンドポイントの認証を追加できません。できることは、ローカルサービスの前にアクセス制御を置き、サービスのデフォルトに依存しないことです。 InstaTunnelのドキュメントによると：

• エッジ認証。 --passwordや--auth user:passはトンネルを保護します。これらはProまたはBusinessプランが必要です。CLI 1.1.24以降、パスワードとBasic Auth設定はリクエストがマシンに転送される前に適用されます。

instatunnel 3000 --subdomain acme-qa --auth qa:review-secret

• MCPトンネルとベアラートークン。 --mcpはProまたはBusinessが必要です。ドキュメントでは、node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"でトークンを生成し、Authorization: Bearerヘッダーとして使用します。MCPサーバーはトークンを自ら検証する必要があります。クライアントはデフォルトでは必要ありません。

instatunnel 8787 --mcp --transport v2 --subdomain mymcp

• トラフィックポリシー。 トラフィックポリシーのドキュメントでは、CIDR範囲のIP許可・拒否ルール、ヘッダルール、IP/APIキー/ユーザごとのレート制限（ブロック時は403や429）、ブロックリクエストの監査記録について説明しています。これらは管理者が /admin/policies から管理します。
• 可視性とクリーンアップ。 --logs（Pro/Business）でリクエストログを取得し、--kill <subdomain>でトンネルを停止します。QAリンクの場合、資格情報のローテーションやレビュー後の停止を推奨します。

実用的な注意点：トンネルが公開ホスト名をHostヘッダーに送信する場合、ViteのallowedHostsのような許可リストは、そのホスト名を追加するまで拒否します。特定のホスト名を追加し、ワイルドカードやtrueは避けてください。トンネルが実際に送信する内容を確認してから信頼してください。

まとめ

• 0.0.0.0 Dayは2024年のブラウザの脆弱性であり、不均一に修正されています。実際にMCP Inspectorなどの開発ツールで悪用例がありました。
• DNSリバインディングは2024年のOllamaから2025年のMCP SDK、2026年のNemoClawまで再び浮上しています。対策は常にサーバー側です：認証とHost・Originの検証。
• ブラウザの許可ダイアログ（Chrome 142+、Firefox 149+）は露出を減らしますが、これだけでは十分ではありません。
• サーバー側のfetcherには許可リスト、完全なアドレスファミリーの解決、ピン留めされた接続が必要です。
• トンネルは認証とアクセス制御を追加し、唯一の防壁としないことが重要です。