悪性サイトがローカルAIを乗っ取る「ClawJacked」：WebSocket越境が露わにした“内側の境界”の脆さです

今日の深掘りポイント

• ブラウザ上の悪性JavaScriptがlocalhostで待ち受けるAIエージェントにWebSocket接続し、パスワードをブルートフォースして乗っ取れる──「内側は安全」という前提が崩れています。
• 脆弱性はCORSの問題ではなく、WebSocket特有の“Origin検証欠落＋認証レート制御不備”の古典パターンに近い相です。CSWSH（Cross‑Site WebSocket Hijacking）の教訓をAIエージェントにも適用すべき段階です。
• 影響は「その端末だけ」に留まらず、エージェントが保持・経路化するSaaSトークンや内部API経由での横展開に波及し得ます。AIが統合するワークフロー全体が攻撃の踏み台になり得ます。
• 防御はアップデート適用が最優先。加えて、localhostサービスのOrigin検証・高エントロピーな初期トークン化・レートリミット・デバイス登録の二段承認など、設計レベルの見直しが要ります。
• SOCはブラウザ発のlocalhost宛WebSocketと、エージェント側の「新規デバイス登録」や「スキル追加」の監査ログを突き合わせて異常検知を設計するのが近道です。

はじめに

AIエージェントは“外のAI”ではなく、“内なる自動化基盤”になりつつあります。だからこそ、ブラウザとlocalhostを橋渡しするWebSocketは要注意の境界になってきました。OpenClawの「ClawJacked」は、その脆さを最も現実的なかたちで突きつけています。攻撃者は悪性サイトを踏ませるだけで、ユーザ端末内のAIエージェントにWebSocketで手を伸ばせる可能性があり、一定条件下でパスワードの総当たりにより制御を奪えるという報告です。ベンダは迅速に修正を提供済みで、アップデート適用が最重要の初動になります。

本件は単発のゼロデイ騒ぎではなく、AIエージェント時代に見直すべき“ブラウザ—localhost境界”という構造問題に直結します。この記事では、事実の整理と、設計・運用の両面で何を改めるべきかを掘り下げます。

深掘り詳細

事実関係（確認できる一次情報）

• 悪性サイト上のJavaScriptが、ローカルで動作するOpenClawコアゲートウェイにWebSocketで接続し、特定条件下でパスワードをブルートフォースしてAIエージェントを乗っ取れる欠陥が修正されたと報じられています。OpenClawは迅速にパッチを提供し、最新バージョンへの更新を推奨しています。The Hacker Newsの報道が一次情報として確認可能です。
• 関連する脆弱性群（例：CVE-2026-25593など）には、認証バイパスやRCEにつながり得るものが含まれるとされています。詳細な技術要素（脆弱箇所のコード行やパッチ差分、固定版の厳密なバージョン番号など）は公開情報に限りがあるため、本稿では推測を交えず、公知の範囲に留めます。

参考として、WebSocketの越境リスク（CSWSH）に関する背景資料は以下が有用です。これは本件の一般化されたリスク理解のための資料であり、OpenClaw固有の欠陥内容そのものを特定する根拠ではありません。

• Cross‑site WebSocket hijackingの解説（PortSwigger Web Security Academy）: https://portswigger.net/web-security/websockets/cross-site-websocket-hijacking
• WebSocketとOriginヘッダのセキュリティ・コンテキスト（MDN）: https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#security_considerations
• Private Network Access（PNA）仕様（WICG）: https://wicg.github.io/private-network-access/

編集部インサイト（構造問題と設計インパクト）

• ブラウザ—localhostの“見えない境界”が最大の弱点です
  CSWSHに代表される通り、WebSocketはCORSと異なる制約モデルで、サーバ側にOrigin検証やトークン化を実装しない限り、任意サイトからlocalhostへの“正当な”接続として見えてしまいます。AIエージェントのような特権自動化は、この境界を破られると被害の非線形拡大が起きやすいです。OpenClawに限らず、ローカルにHTTP/WSを立てる生成AI系（モデルサーバ、エージェントゲートウェイ、プラグインマネージャ）は設計時にこの前提を置くべきです。
• パスワード認証は“入口”、本質は“権限境界の粒度”です
  パスワードの総当たりが成り立ったという事実は深刻ですが、仮に強固な認証を施しても、乗っ取り後に「何ができるか」の最小化が同等に重要です。具体的には、デバイス登録やスキル追加、外部トークン保管・使用、ファイルI/O、システムコマンド実行などの権限を機能ごとに分離し、対話的な強制承認（Just‑in‑Time許可）と監査証跡を必須化するべきです。AIエージェントは“OSのもう一つの管理者”になりがちで、権限設計を粗くすると一次侵害がすぐ多段化します。
• 供給網の面でも“二重の露出”が生まれる
  ローカル実行の安全神話は、スキルやツールのマーケット（報道中の“ClawHub”に相当）と結びついた瞬間に崩れます。乗っ取られたエージェントが“正規アカウントで”市場に悪性スキルをアップロードすると、供給網汚染と端末乗っ取りが相互に加速する可能性があります。これは従来のブラウザ拡張エコシステムのリスクに、RPA/自動化の実行権限が加わる形で、被害半径が広がるのが特徴です。

脅威シナリオと影響

以下は、公開情報を踏まえた仮説シナリオです。技術的詳細は一般的なパターンに基づく分析であり、OpenClaw固有の実装を断定するものではありません。

• シナリオA：ドライブバイでのローカル乗っ取りからSaaS横展開

  1. ユーザが悪意あるサイトを閲覧（MITRE ATT&CK: Drive‑by Compromise, T1189）。
  2. サイト上のJSがlocalhostのOpenClawゲートウェイにWebSocketで接続（Application Layer Protocol: Web Protocols, T1071.001）。
  3. 認証のレート制御やOrigin検証の欠落を突き、パスワードを総当たり（Brute Force, T1110）→有効な認証情報として利用（Valid Accounts, T1078）。
  4. 乗っ取り後、エージェントが保持するSaaSトークンや内部APIを用いたタスク実行、データ取得、外部送信（Collection/Exfiltrationの複合）。
  5. さらにスキルの追加やデバイス登録を通じた持続化・拡張（Create Account/Additional Accessの亜種、T1136の概念に近いアプリ内永続化）。

• シナリオB：供給網汚染の加速器としてのエージェント

  1. Aの手順でエージェントを制御。
  2. マーケットプレイスに悪性スキルを“正規の手続き”で公開し、信用を借用。
  3. 他組織のエージェントがスキルを取得→一見正規の更新として拡散。
  4. 結果として、単一脆弱性が横断的なサプライチェーンリスクへと増幅。

影響の勘所は次の3点です。

• データ機密性の直接侵害だけでなく、“自動化された行動”による誤作動・誤送信が発生しやすい点です。人手のワンクリックがないぶん、被害の速度が上がります。
• ローカルからSaaS・社内APIへの“特権パス”をエージェントが握っている設計だと、端末境界の突破がそのままクラウド側のイベントへと直結します。
• 監査面では、ユーザ操作とボット操作の区別が難しいため、ログの相関とタイムライン復元が不可欠です。エージェントの“誰が何をいつ許可したか”の強い監査証跡が必要です。

参考（MITRE ATT&CK）:

• Drive‑by Compromise (T1189): https://attack.mitre.org/techniques/T1189/
• Brute Force (T1110): https://attack.mitre.org/techniques/T1110/
• Valid Accounts (T1078): https://attack.mitre.org/techniques/T1078/
• Application Layer Protocol: Web Protocols (T1071.001): https://attack.mitre.org/techniques/T1071/001/

セキュリティ担当者のアクション

• 今すぐ（48時間以内）

  • ベンダが提供する最新パッチを適用し、影響バージョンの全滅を最優先で完了させます（報道参照）。
  • エージェントの管理パスワードやAPIトークンを強度の高いものに即時ローテーションし、認証試行のレート制限・アカウントロックの有効化を確認します。
  • エンドポイント防御/ブラウザ監視で、最近7～14日間の以下の兆候をハントします。
    • ブラウザプロセス発での ws://127.0.0.1: 宛多数接続・短時間の連続失敗。
    • OpenClawの「新規デバイス登録」「スキル追加/更新」「設定変更」のイベントログ。
    • エージェント発の異常な外向き通信（普段使わない宛先や時間帯）。
  • 可能であれば一時的に、ブラウザからlocalhost:OpenClawポートへのWebSocket接続を企業FW/EDRのアプリ制御で遮断（業務影響は要評価）します。

• 数日以内（1～2週間）

  • 設計レビュー（開発/調達チームと合同）：
    • WebSocketサーバ側のOrigin検証、初期接続時の高エントロピー・ワンタイムトークン（Sec‑WebSocket‑Protocol等のサブプロトコルでのバインド）、強制的なレートリミット/バックオフの確認。
    • デバイス登録やスキル追加等の高リスク操作に対するインタラクティブ承認（OSレベルのプロンプトや管理者承認フロー）を要求。
    • 権限分割（Least Privilege）：SaaSトークン保管・使用、ファイルI/O、外部呼び出しを分離し、各操作を個別監査。
  • 監査基盤の強化：エージェントの行動ログをSIEMに統合し、ユーザ操作と自動化操作の区別フィールドを標準化。
  • ブラウザの企業ポリシー見直し：Private Network Accessの厳格化や、未知サイトからのlocalhostアクセス制限の検討（組織の標準ブラウザ機能とポリシーで可否を評価）。

• 今四半期内

  • “AIエージェント・セキュリティ基準”を内規化：ローカル通信の安全要件、スキル/ツールのサプライチェーン審査、権限設計、監査証跡、脆弱性対応SLAを明文化します。
  • レッドチーム/ペネトレのシナリオに、CSWSH由来のlocalhost攻撃と、エージェント乗っ取り後の横展開（SaaS・API・ファイルサーバ）を恒常メニューとして追加します。
  • マーケットプレイス（報道中の“ClawHub”に相当）に依存する場合は、社内での署名検証・静的/動的スキャン・利用許可リスト化（allowlist）を運用します。

最後に、今回のスコアリングから透けて見えるのは“即応が可能で、しかも差し迫っている”という現場感覚です。一方で、問題の根はブラウザとlocalhostという設計レイヤにあります。パッチ適用だけで終わらせず、AIエージェントを“システムのもう一つの管理プレーン”として扱い、設計・運用・監査を総合的に底上げすることが、今後のインシデント耐性を左右します。

参考情報

• The Hacker News: ClawJacked flaw lets malicious sites hijack OpenClaw AI agents via WebSocket（2026-02）: https://thehackernews.com/2026/02/clawjacked-flaw-lets-malicious-sites.html
• Cross‑site WebSocket hijacking（PortSwigger Web Security Academy）: https://portswigger.net/web-security/websockets/cross-site-websocket-hijacking
• WebSocketサーバ実装のセキュリティ考慮（MDN）: https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers#security_considerations
• Private Network Access（WICG Spec）: https://wicg.github.io/private-network-access/