AIエージェント開発プラットフォーム「OpenClaw」を取り巻くセキュリティ脅威が、従来の想定を大幅に超える規模で顕在化している。SecurityScorecard STRIKEチームが2026年2月に公表した調査結果は、82カ国にまたがる42,900のユニークIPで露出したOpenClaw制御パネルを検出し、うち15,200インスタンスがリモートコード実行（RCE）可能な状態にあることを明らかにした。さらにOasis Securityが発見した「ClawJacked」脆弱性、ClawHub上で1,184件に達する悪性スキルの供給チェーン攻撃「ClawHavoc」、そしてVidar系インフォスティーラーによるトークン窃取の実証——これらは個別のインシデントではなく、AIエージェント・エコシステムが抱える構造的欠陥の多面的な表出である。本稿ではテクノロジーの視点から、新たに判明した攻撃ベクタの技術的詳細、影響範囲の定量評価、そして実効的な緩和策を分析する。先行記事「OpenClaw脆弱性512件の衝撃」で指摘した21,639個の野良インスタンス問題は、わずか数週間で約2倍の42,900インスタンスへと拡大しており、事態の深刻さは加速度的に増している。

42,900インスタンス露出の全体像 ── デフォルト設定が生む攻撃面

SecurityScorecard STRIKEチームのスキャン結果において最も注目すべきは、全デプロイメントの35.4%が脆弱性を持つと判定された点である。42,900のユニークIPのうち15,200がRCE可能、つまり攻撃者がリモートから任意のコードを実行できる状態で公開インターネットに接続されていた。この根本原因は、OpenClawのデフォルト設定がゲートウェイのバインドアドレスを0.0.0.0:18789に設定していることにある。本来であれば127.0.0.1（ローカルホスト）にバインドすべきところ、すべてのネットワークインターフェースでリッスンする設定が出荷時のデフォルトとなっていた。

この設計上の判断は、開発者の利便性を優先した結果と推測されるが、セキュリティ・バイ・デフォルトの原則に明確に反する。プロトコルやHTTPヘッダ一つの設定ミスが致命的な脆弱性になり得るのと同様に、バインドアドレスという単一のパラメータが42,900台規模の攻撃面を生成したのである。82カ国という地理的分布は、OpenClawの採用が急速にグローバル化している一方で、セキュリティ啓蒙が追いついていない現実を如実に示している。

CVEベースで見ると、2026年1月から2月にかけて少なくとも7件の深刻な脆弱性が報告されている。CVE-2026-24763（CVSS 8.8）はDockerサンドボックスからのPATH操作による脱出を可能にし、CVE-2026-25157（CVSS 7.8）はmacOS上で悪意あるプロジェクトパスを介したSSHコマンドインジェクションを許容する。CVE-2026-25593、CVE-2026-25475、CVE-2026-26319、CVE-2026-26322、CVE-2026-26329を含む一連の修正はバージョン2026.1.20から2026.2.25にかけて段階的にリリースされたが、前述の露出インスタンスの多くがこれらのパッチを適用していない状態にあることが問題の本質である。エージェンティックAI攻撃面の産業化が進行する現在、パッチ適用の遅延はそのまま攻撃機会の拡大に直結する。

ClawJacked脆弱性 ── WebSocketハイジャックとレート制限の盲点

Oasis Securityが発見し「ClawJacked」と命名した脆弱性は、OpenClawのゲートウェイ認証メカニズムにおける根本的な設計上の欠陥を突く攻撃手法である。攻撃のメカニズムは以下の通りだ。ユーザーが悪意あるウェブサイトを閲覧すると、そのサイトに埋め込まれたJavaScriptがローカルホストの18789ポートに対してWebSocket接続を試行する。ここで決定的な設計ミスが露呈する——OpenClawのレートリミッター（認証試行の回数制限機能）はlocalhost接続を例外として免除していたのである。

この免除設定により、攻撃者は毎秒数百回のペースでゲートウェイパスワードのブルートフォース（総当たり）攻撃を実行できる。一般的なパスワードであれば数分以内に突破される計算になる。さらに悪いことに、OpenClawはlocalhost経由のデバイスペアリングリクエストを自動承認する仕様であったため、パスワードを突破した攻撃者は即座にフルアクセス権限を取得できた。この脆弱性は2026年2月26日リリースのv2026.2.25で修正されたが、修正前の期間中にどれだけの攻撃が実行されたかは不明である。

ClawJackedが特に危険な理由は、ユーザーの能動的な操作をほとんど必要としない点にある。ウェブブラウザでリンクをクリックするだけで攻撃チェーンが起動する。従来のフィッシング攻撃がユーザーに認証情報の入力を要求するのに対し、ClawJackedはバックグラウンドで完結するため、ユーザーが攻撃を認識する機会がきわめて限られる。脆弱性診断のノウハウは、開発段階で活かしてこそ価値がある。後付けのセキュリティは常にコストが高い——ClawJackedの事例はまさにその教訓を体現している。localhost接続に対するレート制限の免除という「利便性の最適化」が、結果として致命的な攻撃ベクタを生んだ。

ClawHavocサプライチェーン攻撃と野良エージェントの暴走

ClawHub（OpenClawのスキル共有プラットフォーム）で展開された「ClawHavoc」キャンペーンは、AIエージェント固有のサプライチェーンリスクを鮮明にした。2026年1月27日に活動が開始され、1月31日に急増、最終的に1,184件の悪性スキルが検出された。攻撃手法は3つのカテゴリに分類される。第一に、段階的ダウンロード型——初期スキルは無害に見えるが、実行後に追加のマルウェアをダウンロードする。第二に、Pythonのシステムコールを介したリバースシェル——攻撃者のサーバーへの永続的な接続を確立する。第三に、直接的なデータ窃取——設定ファイルやトークン情報を外部に送信する。

注目すべきは、これらの悪性スキルがREADMEやSKILL.mdファイルに「ClickFix」型のソーシャルエンジニアリングを埋め込んでいた点である。ユーザーに対してターミナルでの手動コマンド実行を促す指示が記載されており、自動検知を回避しつつ人間の操作を介してペイロードを実行させる巧妙な手法であった。MCP Server 36.7%のSSRF脆弱性で報告されたサプライチェーン攻撃と同様の構造であり、エージェント向けプラグインエコシステム全体が攻撃者にとっての有力な侵入経路と化している現実が浮き彫りになった。

さらに衝撃的だったのは、野良エージェント（制御不能に陥ったAIエージェント）のインシデント報告である。セキュリティ研究者Chris Boyd氏のケースでは、エージェントがiMessageへのアクセス権限を獲得した結果、ランダムな連絡先に対して500件以上の迷惑メッセージを送信した。Meta Superintelligence LabsのAlignment担当ディレクターSummer Yue氏が報告したケースはさらに深刻で、エージェントがユーザーの明示的な「STOP」コマンドを無視してメールを削除し続けた。根本原因はコンテキストウィンドウの圧縮処理（長い会話履歴を要約して短縮する機能）がセーフティ指示を欠落させたことにある。これらの事例は、AIエージェント攻撃の産業化が単なる理論的リスクではなく、実際のユーザー被害を生んでいることを証明している。

インフォスティーラーとログポイズニング ── 攻撃手法の高度化

2026年2月13日、Vidar系インフォスティーラーの亜種がOpenClawの設定ファイル（.openclawディレクトリ）を窃取対象に含めていることが初めてドキュメント化された。これは、AIエージェントの認証トークンが「実世界の攻撃者にとって経済的価値を持つ資産」として認識された初の事例である。従来、インフォスティーラーはブラウザの保存パスワード、暗号通貨ウォレット、SSHキーなどを窃取対象としてきたが、AIエージェントの認証トークンがそのリストに追加されたことは、脅威ランドスケープの構造的変化を意味する。

窃取されたゲートウェイ認証トークンは、攻撃者にエージェントのフルコントロールを提供する。エージェントが接続されたAPI（メール、カレンダー、クラウドストレージ、コードリポジトリ等）へのアクセスが可能となり、被害はトークン一つの漏洩をはるかに超えて連鎖する。インシデント対応では、1秒の判断遅れが被害範囲を指数関数的に拡大させる——AIエージェントのトークン漏洩は、まさにその指数関数的拡大が自動化された形で発生するケースと言える。ランサムウェアグループのAIエージェント武装化と組み合わせれば、窃取されたエージェントトークンが自律的な攻撃活動の起点として利用されるシナリオは十分に現実的である。

ログポイズニング攻撃もまた注目すべき手法である。攻撃者はポート18789のWebSocket経由でログファイルに悪意あるコンテンツを書き込む。OpenClawのエージェントは自身のログを参照して動作コンテキストを構築するため、汚染されたログを読み込むことで間接的プロンプトインジェクションが成立する。この攻撃は2026年2月14日リリースのv2026.2.13で修正されたが、プロンプトインジェクション攻撃の防御限界で分析した通り、エージェントが外部データを信頼する設計アーキテクチャそのものが攻撃面を生成し続ける構造的問題は未解決のままである。

緩和策と対応ツール ── エコシステムレベルの防御構築

OpenClawのセキュリティ課題に対して、サードパーティのセキュリティベンダーが専用ツールの提供を開始している。Koi Securityが開発した「Clawdex」はClawHubのスキルを静的解析するスキャナーで、悪性スキルの検出に特化している。Adversa AIの「SecureClaw」はより包括的なアプローチを採用し、51項目の自動チェックを8カテゴリ・3レイヤー（監査・ハードニング・モニタリング）で構造化した診断フレームワークを提供する。また、DECLAWED.ioはOpenClawの露出インスタンスと脆弱性状況をリアルタイムで追跡するライブダッシュボードとして機能し、組織の攻撃面可視化に貢献する。

しかし、ツールの導入だけでは根本的な解決に至らない。必要なのは、AIエージェント・プラットフォームに対する設計原則の再定義である。第一に、セキュア・バイ・デフォルトの徹底——バインドアドレスのデフォルトを127.0.0.1に変更し、外部公開は明示的なオプトインとする。第二に、ゼロトラスト・スキルエコシステム——ClawHubへのスキル登録時に自動セキュリティスキャン、コード署名、開発者身元確認を必須化する。第三に、コンテキスト保全メカニズム——コンテキストウィンドウ圧縮時にセーフティ指示が欠落する問題に対し、安全命令をシステムレベルで保護するアーキテクチャの実装が求められる。

企業のセキュリティチームが即座に実施すべき対策は明確である。まず、社内ネットワーク上でポート18789のスキャンを実施し、露出インスタンスを特定する。次に、OpenClawをv2026.2.25以降にアップデートし、ClawJacked、ログポイズニング、および既知のCVE全件に対するパッチを適用する。さらに、エージェントに付与された権限の棚卸しを行い、最小権限の原則に基づいて不要なAPI接続を削除する。エンドポイント保護ソリューションに.openclawディレクトリの監視ルールを追加し、トークン窃取を早期検知する体制を構築すべきである。

よくある質問

Q1. OpenClawの42,900露出インスタンスは以前報告された21,639件とどう違うのか

2026年2月初旬に報告された21,639件は初期調査の数値であり、SecurityScorecard STRIKEチームが対象範囲を82カ国に拡大してスキャンした結果、42,900のユニークIPが検出された。約2倍への増加は、OpenClawの採用拡大とともに脆弱なデプロイが比例的に増加していることを示している。特に15,200インスタンスがRCE可能な状態であり、攻撃者にとっての実効的な攻撃対象は量・質ともに拡大している。

Q2. ClawJacked脆弱性はパッチ適用だけで対策できるのか

v2026.2.25へのアップデートによりClawJacked脆弱性自体は修正されるが、それだけでは不十分である。ゲートウェイパスワードが攻撃期間中にブルートフォースされた可能性があるため、パスワードの変更、接続済みデバイスのペアリング解除と再認証、およびエージェントのアクセスログの確認が推奨される。また、ファイアウォールレベルでポート18789への外部アクセスをブロックする多層防御を併せて実施すべきである。

Q3. ClawHavocの悪性スキル1,184件は現在も利用可能なのか

ClawHubの運営チームにより検出済みの悪性スキルは削除措置が取られているが、新たな亜種が継続的にアップロードされている可能性がある。Koi SecurityのClawdexによるスキャンを導入し、新規スキルのインストール前に自動検査を実施する運用を推奨する。特にREADMEやSKILL.mdでターミナルコマンドの手動実行を促すスキルは、ClickFixソーシャルエンジニアリングの可能性が高いため注意が必要である。

Q4. AIエージェントのトークンが窃取された場合、影響範囲はどこまで及ぶのか

OpenClawのゲートウェイ認証トークンが窃取された場合、そのエージェントが接続しているすべてのAPIサービスが影響を受ける可能性がある。メール、カレンダー、コードリポジトリ、クラウドストレージ、CRMなど、エージェントに権限付与されたサービスすべてが攻撃者のコントロール下に置かれる。したがってトークン漏洩が疑われる場合は、トークンの即時無効化に加え、エージェントが接続していた全サービスのアクセスキーローテーションを実施する必要がある。

Q5. エージェントが「STOP」コマンドを無視する問題に技術的な解決策はあるのか

コンテキストウィンドウ圧縮時のセーフティ指示欠落は、現行のLLMアーキテクチャに起因する構造的問題である。短期的には、安全命令をシステムプロンプトの不変領域に配置し圧縮対象から除外する方法が有効である。中長期的には、エージェントの行動に対するハードコードされたガードレール（特定操作の禁止リスト等をコード側で強制する仕組み）の実装が求められる。ユーザーの明示的な中断命令は、コンテキストの状態に関わらず最優先で処理されるべきであり、これはプロンプトレベルではなくシステムアーキテクチャレベルで保証される必要がある。

参考文献