結論から言います。OpenClaw セキュリティで最も広まっている安全神話 ―― 「ローカルでしか動かしていないから安全」―― は、この脆弱性の前では通用しませんでした。ゲートウェイがループバック（127.0.0.1）にしかバインドされていなくても、被害者のブラウザが内側から外側へ接続を張れば、そのまま突破されました。ドアには鍵をかけたのに、郵便受けには鍵をかけていなかったわけです。この記事では、この事故が実際にどれほど大きかったのかを日付つきの数字で、コミュニティが本当に信用しなくなったものは何か、出回っている自己ホスティングのアドバイスのどこが正しくどこが間違っているか、そしてこの運用方針自体がその中でどの位置に立っているのかを整理します。
🔴 何が起きたのか ―― 日付つきの数字で
2026年1月29日、OpenClawは CVE-2026-25253（CVSS 8.8）にパッチを当てました。Control UIがクエリ文字列の gatewayUrl 値を検証なしに受け取り、自動的にWebSocket接続を張り、その過程で認証トークンも一緒に送信する構造でした。攻撃者は悪意あるリンクを一つ送るだけで済んだのです。
重要なのはその後です。公式セキュリティ勧告にはこう書かれています ―― 「この脆弱性はループバックのみにバインドされたインスタンスでもそのまま機能する。被害者のブラウザが外部への接続を張る側だからだ」。ゲートウェイ自体が外部に露出していなくても、ブラウザが内と外をつなぐ橋になってしまえば意味がない、ということです。
パッチ直後、露出規模を測る調査が相次ぎました。数字だけを見るとそれぞれ別の調査に見えますが、実際には同じ話が時間とともに膨らんでいったものでした。
| 時点 | 露出／脆弱インスタンス数 | 出典 |
|---|---|---|
| SecurityScorecard 初期検索（タイトルマッチ基準） | 24,034台 | SecurityScorecard |
| SecurityScorecard 最終発表数値（ファビコンフィンガープリンティング基準、2026-02-09） | 40,214台（ユニークIP 42.9K、82カ国）・RCE脆弱 15.2K・過去侵害履歴関連 53.3K | SecurityScorecard |
| The Register 報道時点（同日、記事執筆の数時間前にSTRIKEレポートが発行） | 135,000台以上・RCE脆弱 12,812 → 50,000台以上に増加 | The Register |
The Registerはこの急増を直接指摘しています ―― 記事執筆時点での13万5千台という数字は、同じ日の少し前に発行されたSTRIKEレポートの4万台水準から、わずか数時間で開いた差だと指摘しました。RCE脆弱インスタンスも同期間で12,812台から5万台以上に増えたと伝えています。「OpenClawはデフォルト設定で 0.0.0.0:18789 にバインドされる。つまりすべてのネットワークインターフェース、公衆インターネットを含めて待ち受けているということだ」―― これはSecurityScorecardのレポート本文に明記されている内容です。露出は例外ではなく、デフォルトだったということです。
😤 コミュニティが本当に信用しなくなったもの
すでにパッチが当たったCVE一つのせいで信頼が崩れたわけではありません。三つの要因が重なりました。
一つ目は、露出がデフォルト設定だったという設計そのもの。二つ目は、マーケットプレイスの信頼が崩れたことです。セキュリティ企業Koiは、OpenClawのスキルマーケットプレイスであるClawHubで悪意あるスキルを発見し、その数が341個から824個に増えたと後続報告しています。AMOSキーチェーンスティーラー、リバースシェル、タイポスクワッティングまで混在していました。
三つ目は、「パッチが当たったから終わり」ではなかったという点です。2026年4月、CVE-2026-44112が発表されました ―― サンドボックスのファイルシステム書き込み処理でシンボリックリンクを操作し、境界の外に書き込めるようになるTOCTOU（time-of-check/time-of-use）競合状態です。2026.4.22でパッチが当たりました。CVSSスコアは情報源によって異なります ―― NISTは6.3（MEDIUM）、VulnCheckは3.1基準で9.6（CRITICAL）、4.0基準で8.4（HIGH）としています。どちらが正しいかをこの記事が判定する話ではありませんが、一つの数字にまとめて引用しないのが誠実だと考えます。
🧭 出回っている自己ホスティングのアドバイス、何が正しくて何が間違っているか
壊れた神話から見ていきましょう。「ローカルでしか動かしていないから安全」は、上で見た通りこの脆弱性の前では単純に間違っています。ブラウザが橋になる攻撃の前では、ループバックバインディングは意味を持ちません。
もう一つよく出回るアドバイス ―― 「エージェント自身に設定をチェックさせればいい」。これは安心させるふりをした偽の安全策です。チェックを任せる対象（エージェント）こそが、信頼できるかどうかが問われている当の対象だからです。自分で自分を監査する構造は検証ではありません。
逆に、正しいアドバイスもあります。セキュリティコンサルティング企業Osoがまとめた自己ホスティングのハードニング原則はこうです。別のマシン・VM・コンテナで隔離すること、本番ネットワークに置かないこと、コントロールプレーンをインターネットに直接露出せずVPN・強力な認証・厳格なファイアウォールルールを使うこと（Tailscaleが挙げられています）、すべてのツールをホワイトリストの背後に置きデフォルトは拒否にすること、読み取り専用をデフォルトにすること、サードパーティスキルの自動インストール・自動ロードを切ること、そして「即座に止める方法」を必ず持っておくことです。
🔧 強化した運用方式 ―― どの位置に立っているか
これまで、WSL2ゲートウェイとMac Mini リモートノードをSSHトンネルで接続してOpenClawを運用してきました。今回、上のリストと一つずつ照らし合わせてみました。
ゲートウェイはループバックにのみバインドされており、認証トークンもかかっています。macOSのLaunchDaemonがSSHトンネルを自動的に維持しているため、Mac MiniノードがWSL2ゲートウェイのWAN IPに直接アクセスする経路自体がありません。ここまではOsoのリストの「隔離」と「WAN非露出」の項目を満たしています。ただし、この構造も上で確認した事実の前では完全ではありません ―― ループバックバインディングはブラウザ橋攻撃を防げません。今回の改訂で認証トークンのローテーション周期を短くし、サードパーティスキルの自動インストールを切りました。「即座に止める方法」はまだ手動のため、次の整備対象として残しています。
🤔 では、OpenClawは本当に使えない代物なのか
正直に取り上げるべき反論が三つあります。
一つ目、「取り返しがつかないほど壊れている」は2月のパニックを過大解釈したものです。2026.1.29のパッチは実際に出荷されており、2026年5月15日に発行された公式ロードマップ（コアメンテナー Jesse Merhi 署名）には、境界侵害を防ぐfs-safeパターンライブラリ、ネットワークアウトバウンドを制御するProxyline、悪意が確認されたリリースを自動隔離するClawHub検疫システム、Slack・Telegram・iMessageで承認をルーティングするexec承認体制、アドバイザリに紐づく148ルールのOpenGrepルールパックまで具体的に書かれています。口をつぐんで耐えているのではなく、公開されたロードマップが実際に動いています。
二つ目、隔離には限界があります。VMであれコンテナであれ、ネットワーク境界をどれだけ絞っても、エージェントが信頼して取り込んだ外部コンテンツ（ウェブページ、メール、文書）に隠された悪意ある指示を実行してしまう間接プロンプトインジェクションは防げません。隔離が防ぐのは「このプロセスがシステムの他の部分に触れないようにする」ことであって、「このエージェントが騙されないようにする」ことではありません。
三つ目、VM級の隔離はタダではありません。コンテナよりも起動遅延が確実に増えます ―― 正確な倍率を引用できるほど検証された資料は今回の調査では見つからなかったため、数字は明かしません。ただ、このコストを払う価値があるプロファイルと、コンテナ隔離で十分なプロファイルは違う、ということだけは明確です。
✅ では、どの隔離レベルを選ぶべきか
業界のアドバイスと実際の運用経験を重ねてみると、プロファイルごとに必要なレベルが分かれます。
| 自己ホスティングのプロファイル | 推奨隔離レベル | 主な対策 |
|---|---|---|
| カジュアルな1人ホームラボ（外部アクセス不要） | プロセス／コンテナ隔離＋ループバックバインディング | 認証トークン必須、ClawHub自動インストールをオフ、ブラウザ橋攻撃は別途意識すること |
| 常時露出サービス（リモートアクセスが必要） | コンテナ／VM境界＋VPNトンネル | WAN直接バインディング禁止、Tailscale・SSHトンネル、キルスイッチを用意 |
| 小規模チーム／プロダクション | 専用マシンまたはVM完全分離 | 最小権限API、署名済みスキルのみ許可、異常検知ロギング |
どのレベルを選んでも、共通して言えることが一つあります ―― 「ローカルだから安全」という文をセキュリティの根拠として使わないことです。その文が守ってくれなかった事故がすでに一度ありました。検証されていないものは検証されていないと書くべきです ―― VMの遅延倍率も、44112の正確な深刻度も、この記事は無理に結論を出していません。
