OpenClawのAIアシスタントに、攻撃者が細工したコンテンツをシステムログに挿入できる脆弱性が見つかった。
この欠陥は、特定のWebSocketヘッダーの記録方法に起因するもので、AI支援ワークフローにおけるログポイズニングの潜在的なリスクを生じさせる。
「この問題は主に間接的なプロンプトインジェクションのリスクであり、下流でのログ消費の方法に左右される。ログをLLMやその他の自動化処理に入力しない場合、影響は限定的だ」とOpenClawは勧告で述べている。
OpenClawのログポイズニングの仕組み
この脆弱性は、OpenClawのゲートウェイサーバーコンポーネント（src/gateway/server/ws-connection.ts）に存在し、2026.2.12までのすべてのバージョンに影響する。2026.2.13で修正された。
影響を受けるリリースでは、WebSocket接続がハンドシェイク処理を完了する前に切断されると、OriginやUser-Agentなどの特定のリクエストヘッダーが、サニタイズも長さ制限も行われないまま記録されていた。
その結果、ユーザーが制御するヘッダー値が構造化ログエントリーに直接書き込まれる可能性があった。
認証されていない攻撃者がOpenClawのゲートウェイインターフェースに到達できる場合、細工したヘッダー値を送信し、それらをログにそのまま表示させることができる。
これはリモートコード実行（RCE）や認証制御の回避を可能にするものではないが、間接的な操作のリスクをもたらす。
問題となるのは、こうしたログが後に大規模言語モデル（LLM）の推論のコンテキストとして使われる場合だ。例えば、AI支援によるデバッグワークフローが該当する。
その場合、挿入されたコンテンツが、正規のシステム出力やオペレーター向けの指示、構造化された診断情報だと誤解される可能性がある。
全体的な影響は、下流でログがどのように利用されるかに左右される。ログを人間による確認だけに使う場合、実際上のリスクは限定的だ。
一方、AIエージェントがトラブルシューティングや活動の要約のためにログデータを自動的に取り込む環境では、汚染されたエントリーが、モデルによる事象の解釈や結論の組み立て、次のステップの推奨に影響を与える可能性がある。
情報公開時点で、悪用が実際に行われたとの報告や、一般に入手可能な概念実証コードは存在しなかった。
OpenClawのログポイズニングリスクを軽減する
この脆弱性への対処には、パッチの適用に加え、ログとゲートウェイへのアクセスの管理方法を幅広く見直す必要がある。
このリスクは、信頼できない入力が後にAIの推論に影響を及ぼす可能性と結びついているため、組織はロギング、公開範囲、監視の運用を評価すべきだ。
- 最新のOpenClawバージョンにパッチを適用し、WebSocketヘッダー値がログに書き込まれる前に適切にサニタイズされていることを確認する。
- ゲートウェイの公開範囲を制限し、パブリックインターネットからのアクセスを排除し、強力な認証を適用するとともに、ファイアウォール、VPN、またはゼロトラストのアクセス制御を導入する。
- ユーザーが制御するフィールドをサニタイズおよびエンコードして、ログを信頼できない入力として扱い、ヘッダーの長さを制限するとともに、生のテレメトリがAI推論ワークフローに直接取り込まれないようにする。
- デバッグログをAIが利用可能な入力から分離し、フィルタリングやガードレールを導入して、間接的なプロンプトインジェクションのリスクを低減する。
- 異常なヘッダーパターンを監視し、WebSocket接続の失敗の急増や、ログポイズニングの試みを示す可能性がある不審なAI出力を検知する。
- レート制限、IP許可リスト、Webアプリケーションファイアウォールのルールを適用して、攻撃者が細工したリクエストを繰り返し注入する能力を低減する。
- テスト対象のインシデント対応計画について、疑わしいログ活動の調査や、AI主導のトラブルシューティング出力の完全性検証のためのプレイブックを盛り込む。
これらの対策は、ログポイズニングのリスクを低減し、AI支援型のOpenClaw導入環境における信頼境界を強化するのに役立つ。
AI環境におけるログ
OpenClawのログポイズニング脆弱性は、AIを統合したシステムが従来型のエクスプロイト以外にも新たなセキュリティ上の考慮事項をもたらすことを浮き彫りにしている。
直接的なコード実行のリスクが存在しない場合でも、データが記録され、その後に言語モデルによって解釈される方法が、意図しない信頼経路を生み出す可能性がある。
組織が業務ワークフローへのAIアシスタントの組み込みを進める中、ログとテレメトリを信頼できない入力として扱い、自動推論システムがコンテキストデータをどのように利用するかを改めて評価する必要がある。
活用すべきゼロトラストの原則により、ユーザー、デバイス、データフロー全体で継続的な検証を実施することは、こうした信頼境界の課題に対応するために組織が取り組む理由の1つだ。