悪意あるWebページを1回開いただけで、手元のAIエージェントが乗っ取られる——そんな事態が、OpenClawの重大脆弱性CVE-2026-25253で現実になりました。
この記事では、公式アドバイザリと調査報告に基づき、攻撃の仕組みと開発者・運用担当が今すぐ取るべき対策を整理します。
この記事でわかること
- CVE-2026-25253が成立する技術的な理由
- localhost運用でも被害が及ぶ理由
- パッチ適用とトークンローテーションの手順
- AIエージェント全般に通じる防御の考え方
OpenClawとは何が問題だったのか
OpenClawは、メッセージアプリ連携やローカルPC操作を任せられるオープンソースのAIパーソナルアシスタントです。旧称はMoltbot、ClawdBotです。depthfirstの調査では、10万人以上の開発者がデジタルライフの鍵を預けていると報告されています（参考）。
AIエージェントはシェル実行、ファイル操作、各種APIキーへのアクセス権を持ちます。通常のアプリより被害範囲が広いため、認証まわりの設計ミスは致命的になります。
CVE-2026-25253の概要
| 項目 | 内容 |
|---|---|
| CVE ID | CVE-2026-25253 |
| 深刻度 | CVSS 3.1 スコア 8.8（High） |
| 影響バージョン | 2026.1.29未満の全バージョン |
| 修正バージョン | 2026.1.29 |
| 分類 | CWE-669（リソースの不正な転送） |
NVDの説明どおり、OpenClawのControl UI（管理画面）はURLのクエリ文字列からgatewayUrlを受け取り、確認なしでWebSocket接続を開始し、認証トークンを送信していました。
GitHubの公式セキュリティアドバイザリ（GHSA-g8p2-7wf7-98mq）でも、制御UIがgatewayUrlを検証せず自動接続する点が根本原因とされています。攻撃者が用意したリンクや悪意あるサイトを開くだけで、保存済みのゲートウェイトークンが外部サーバーへ送られます。
1クリックでRCEに至る攻撃チェーン
depthfirstのMav Levin氏の調査では、この脆弱性をさらに悪用し、1クリックでリモートコード実行（RCE）まで到達する手順が公開されています（参考）。
攻撃は大きく3段階に分かれます。
第1段階：トークンの窃取
被害者がgatewayUrl=攻撃者サーバーを含むURLを開くと、Control UIはページ読み込み直後にそのサーバーへWebSocket接続します。接続時のハンドシェイクに認証トークンが含まれるため、攻撃者はオペレーター権限を手に入れます。
第2段階：localhost制限の突破
多くのユーザーはOpenClawをlocalhost（既定ポート18789）で動かしています。インターネットから直接は届かないはずの環境でも、被害者のブラウザが中継点になります。HTTPでは同一オリジンポリシー（SOP）が働きますが、WebSocketはサーバー側がOriginヘッダーを検証する必要があります。OpenClawのWebSocketサーバーはこの検証を行っておらず、悪意あるページ上のJavaScriptからws://localhost:18789へ接続できる状態でした。これをクロスサイトWebSocketハイジャック（CSWSH）と呼びます。
第3段階：サンドボックス無効化とコマンド実行
窃取したトークンはoperator.adminやoperator.approvalsスコープを持ちます。攻撃者はAPI経由で実行確認プロンプトをオフにし、Dockerサンドボックスをバイパスしてホスト上でシェルを動かせます。depthfirstのPoCではnode.invokeメソッドでsystem.runを呼び出し、任意コマンドの実行結果を攻撃者サーバーへ返しています。
被害者が追加の操作や承認を行う必要はなく、ページ表示から数ミリ秒で完了します。
「ローカルだけ」では守れない理由
ファイアウォールで外部公開していなくても、ブラウザが攻撃者とローカルゲートウェイの橋渡しになります。GitHubアドバイザリも「ループバックのみで待ち受けていても、被害者のブラウザが橋になるため攻撃可能」と明記しています。
AIエージェントに広いシステム権限を与えているほど、奪われたトークンの影響は大きくなります。iMessageやSlackの読み取り、StripeのAPIキー、ローカルファイルへのアクセスなど、設定次第で機密データ全体が危険にさらされます。
今すぐ取るべき対策
バージョンアップとトークン再発行
OpenClaw 2026.1.29で修正が入りました。変更点は、新しいゲートウェイURLへの接続前にユーザー確認を求めるモーダルを追加したことです。2026.1.29未満を使っている場合は直ちに更新してください。
openclaw --version
npm update -g openclaw
トークンが漏えいした可能性がある場合は、ゲートウェイの認証トークンを再生成します。接続済みのAPIキー、OAuthトークン、ブラウザCookieなど、エージェントが触れうる資格情報もローテーションが必要です。
ネットワークとオリジンの制限
ゲートウェイはループバック（127.0.0.1）にバインドし、Control UIの接続元オリジンをホワイトリストで限定します。インターネットへ管理画面を公開しない運用が基本です。
権限とサンドボックスの見直し
シェル実行の確認プロンプトを維持し、可能ならコンテナサンドボックスを有効にします。エージェントに与える権限は業務に必要な最小限に抑えます。
セキュリティ監査の実行
OpenClawには組み込みの監査コマンドがあります。設定ミスや危険なスキルの有無を定期的に確認してください。
openclaw security audit --deep
AIエージェント運用に通じる教訓
CVE-2026-25253は、単一製品のバグにとどまりません。エージェントが「ユーザーの代わりに動く」ほど、従来のWebアプリとは異なる脅威モデルが必要です。
信頼境界の設計
URLパラメータ1つで接続先が変わるUIは、フィッシングの入り口になります。外部入力を信頼せず、接続先変更には明示的な確認を挟むべきです。
ブラウザを経由する攻撃
ローカルサービスは「外部から見えない＝安全」とは限りません。WebSocketやブラウザ拡張経由の攻撃を想定し、オリジン検証と認証の分離を徹底します。
高権限トークンの扱い
管理APIのトークンが奪われると、サンドボックス設定そのものを書き換えられます。権限の階層化と、侵害時の影響を抑える設計が欠かせません。
AIエージェントの導入を進めるチームは、機能評価と同じ比重でセキュリティ要件を先に定義してください。OpenClawの事例は、その必要性を具体的な被害シナリオで示した警鐘です。