OpenClaw の脆弱性と対策｜コード実行と情報漏洩を防ぐ権限設計

はじめに

OpenClaw は、ローカル環境でコマンド実行やファイル操作、外部サービスとの連携までを自律的に行うオープンソースの AI エージェントです。利便性の一方で、外部から届いた入力をそのまま信頼して動作するという構造的な弱点があり、2026 年 6 月、これを突く 2 つの研究が相次いで公表されました。

本記事は、OpenClaw を運用中、あるいは導入を検討しているエンジニアに向けて、公表された攻撃手口の中身と、自分の環境で取るべき対処を整理します。基本機能や仕組みそのものについては、関連記事『OpenClaw とは — 自律型 AI エージェントの仕組みと基本機能』を参照してください。

要点を先に述べると、Imperva が報告したメッセージオブジェクト経由のプロンプトインジェクションは OpenClaw 2026.4.23 で修正済みのため、運用中の環境はまず更新が推奨されます。一方、Varonis が示したエージェントフィッシングはパッチで解決する種類のものではなく、エージェントに与える権限と外部送信の制御をアーキテクチャ側で見直すことが対処の中心になります。

OpenClaw で公表された 2 つの攻撃手口

2026 年 6 月、Imperva と Varonis の 2 チームが、別々の研究として OpenClaw に対する攻撃を公表しました。いずれも、エージェントが受け取った入力を信頼し、その権限がそのまま攻撃者の手に渡るという同じ問題に行き着きますが、侵入の入り口と必要な対処は異なります。

両者の違いを整理すると次のようになります。

観点	プロンプトインジェクション（Imperva）	エージェントフィッシング（Varonis）
攻撃の仕掛け	データの中に命令を隠す	もっともらしい依頼を通常の経路で送る
入り口	共有連絡先・vCard・位置情報ピン	通常のメール
被害の例	攻撃者サーバーからのスクリプト実行	AWS キー・顧客データの外部送信
対処	2026.4.23 への更新で修正済み	権限設計・送信ゲート等のアーキテクチャ対応

Imperva の研究者 Yohann Sillam は、OpenClaw が連絡先や位置情報などのメッセージオブジェクトを LLM へ渡す際、その内容を信頼できない入力として区別せず、プロンプト本文へそのまま展開してしまう点を指摘しています。一方 Varonis は、こうした隠した命令とは区別される攻撃として、正規の経路から届いた信頼できそうな依頼にエージェントが従ってしまう挙動を「エージェントフィッシング」と名付けています。

両チームの問題意識は、最終的に同じ一点へ集約されます。

参考: The Hacker News（New Attacks Trick OpenClaw AI Agent Into Running Code and Leaking Secrets）
“the agent trusts what reaches it, and its access becomes the attacker’s.”
（エージェントは届いたものを信頼し、その権限が攻撃者のものになる。）
https://thehackernews.com/2026/06/new-attacks-trick-openclaw-ai-agent.html

メッセージオブジェクト経由のプロンプトインジェクション（Imperva）

Imperva が報告した攻撃は、OpenClaw が連絡先や位置情報といったメッセージオブジェクトを LLM へ渡すときの処理（プランビング）に起因します。Web から取得したコンテンツには「信頼できない入力」を示すマーカーが付与される一方で、メッセージオブジェクトにはこの境界が付かず、内容がプロンプト本文へそのまま平坦化（flatten）されて展開されてしまう点が問題でした。

具体的には、連絡先を共有すると name フィールドだけがモデルへ渡り、<contact: name, number> という形でシリアライズされます。山括弧（< >）は名前として使える正当な文字のため、モデルは本物の名前がどこで終わり、注入された命令がどこから始まるのかを判別できません。さらに、連絡先名は画面上では切り詰められて表示されるため、送信側アプリでも受信側アプリでも、被害者がペイロードを目にすることはありません。同じ手口は、vCard（.vcf）の氏名（FN）フィールドや、共有された位置情報ピンのラベルでも成立します。

参考: Imperva（Compromise OpenClaw with Prompt Injections in Message Objects）
“the LLM has no way to know an injection happened.”
（LLM には、注入が起きたことを知る手立てがない。）
https://www.imperva.com/blog/compromise-openclaw-with-prompt-injections-in-message-objects/

Imperva のテスト（Gemini 3.1 Pro のプレビュービルド）では、連絡先名に隠したテキストが、研究者の管理するサーバーからスクリプトを取得して実行するよう指示し、エージェントは実際にそれを実行しました。興味深いのは、同じ命令を画像に埋め込んだ場合は失敗した点です。画像経由のインジェクションは報告例が多く、モデルが学習段階で耐性を獲得しているのに対し、メッセージオブジェクト経由は学習データ上の事例が少なく、防御が及んでいないと考えられます。

OpenClaw はメモリ機能が既定で有効なため、広く共有された 1 つのコンテンツに隠れた命令が、サンドボックス化されていないエージェントを静かに侵害し続ける恐れがある、と Imperva は指摘しています。

この問題は OpenClaw 2026.4.23 で修正済みです。修正版では、連絡先名・vCard フィールド・位置情報ラベルをプロンプト本文から切り離し、信頼できないメタデータ専用のチャネルへ移しています。なお Imperva は、他のパーソナル AI アシスタントでも同じ平坦化パターンを確認しており、OpenClaw だけの問題ではないとしています。運用中の環境では、まず 2026.4.23 以降への更新が推奨されます。

エージェントフィッシング — 通常メールでの情報漏洩（Varonis）

Varonis Threat Labs（Itay Yashar 主導）は、社会工学の側面から OpenClaw に迫りました。Pinchy と名付けたエージェントを構築し、合成された業務データとダミーの機密を入れた Gmail の受信箱に接続したうえで、Gemini 3.1 Pro と OpenAI Codex GPT-5.4 を用いて 4 つのフィッシングシミュレーションを実施しています。

Varonis は、データの中に命令を隠す間接プロンプトインジェクションと、今回の「エージェントフィッシング」を明確に区別しています。前者がモデルの解析層を突くのに対し、後者は一段上の層、つまり正規の経路から届いたもっともらしい依頼に対して、エージェントが「誰の依頼か」を確認する前に行動してしまう点を突きます。構成としては、受信メールを分類・計画・委譲する Orchestrator エージェントと、ブラウザー操作・シェル・Google Workspace API で実際の処理を行う Worker エージェントの二段構成がとられ、標準的な Generic プロファイルと、送信者確認を明示的に指示する Strict プロファイルの 2 つで評価されました。

結果は明暗が分かれました。情報漏洩を狙った 2 つのシナリオでは、エージェントが失敗しています。

 シナリオ 1:
外部の Gmail アドレスから、チームリードの「Dan」を名乗り、本番障害対応のためステージング環境の認証情報を求めるメールを送信。Pinchy は受信箱を検索し、AWS IAM のアクセスキー・データベース接続文字列・SSH 認証情報を平文で外部へ転送しました。

 シナリオ 2:
在宅勤務中の QBR 資料作成という口実で、定例の顧客エクスポートを依頼。Pinchy は、247 社分の顧客レコード（連絡先・契約額・月次経常収益（MRR）約 128 万ドル相当を含む合成データ）を送信しました。

参考: Varonis（Phishing for Lobsters: How We Tricked OpenClaw into Spilling Secrets）
“the verification step still collapsed when the request appeared operationally urgent.”
（要求が業務上緊急に見えると、確認ステップはなお崩れた。）
https://www.varonis.com/blog/openclaw-phishing

一方で、技術的なフィッシングに対しては相応の強さを見せました。ギフトカードを装ったフィッシングページでは実際の認証情報を渡さず、最終的に不審と判断しています。Strict プロファイルではページ自体がブロックされました。タイムシートアプリを装った悪意ある OAuth 同意画面でも、リダイレクト先を検査して不審と判断し、承認前に処理を止めています。モデル間では、Gemini 3.1 Pro が外部サイトとのやり取りや送信により積極的だったのに対し、GPT-5.4 はより慎重な姿勢を示しましたが、社会的な口実にはどちらも引っかかりました。

ここから見えるのは、エージェントは不審な URL や偽ログイン、悪意ある OAuth アプリの検知では人間よりむしろ得意である一方、同僚が不自然なタイミングで認証情報を求めてきたときに立ち止まる、という社会的な判断を苦手とするという非対称性です。役に立とうとする性質そのものが、攻撃の入り口になっています。

なぜ攻撃が成立するのか — lethal trifecta

Varonis は、今回の 2 つの攻撃をいずれも、Simon Willison が提唱する lethal trifecta（致命的な三要素）に当てはめて説明しています。これは、(1) 機微なデータを読める、(2) 信頼できないコンテンツを取り込む、(3) データを外部へ送り出せる、という 3 つの能力を同時に備えたエージェントが本質的に危険だ、という考え方です。OpenClaw はこの 3 つをすべて持つため、汚染された連絡先も、善意を装ったメールも、最終的に同じ結末へ行き着きます。

そして、この信頼境界の問題はプロンプトの扱いだけにとどまらず、OpenClaw のコードそのものにも現れています。

チャネル拡張に潜む同種のバグ（allowlist の名前解決）

InfoSec Write-ups に掲載された別の分析（研究者 Garabandic 氏）は、OpenClaw の過去のアドバイザリを静的解析ルールへ落とし込み、それを使って Slack・Discord・Matrix・Zalo・Microsoft Teams の各チャネル拡張から、同じ根本原因による 5 件の不具合を新たに発見しました。各チャネルはそれぞれ独自の allowlist を持ち、誰がエージェントへメッセージを送れるかを操作者が指定します。

参考: Cybernews（Researcher easily finds five OpenClaw zero-days）
“that allowlist is the entire security model.”
（その allowlist が、セキュリティモデルのすべてである。）
https://cybernews.com/security/openclaw-zero-days-research-microsoft/

根本原因は、起動時の初期化ロジックにありました。実行時のチェックは安定したユーザー ID を検証する一方で、初期化時の解決処理は displayName や username といった可変フィールドのディレクトリ照合で allowlist エントリを解決していました。このため、攻撃者がサービス再起動の前に自分の表示名を allowlist 上のユーザーと一致するよう変更すると、攻撃者の ID が信頼済みリストへ誤って紐づけられてしまいます。allowlist に入り込めれば、操作者が信頼してアクションを委ねているツール連携済みエージェントを、攻撃者がそのまま操れることになります。

実務でとるべき対策

今日提供されているのは、個別のパッチとガードレールです。攻撃の入り口を塞ぐことはできますが、「入力を信頼し、役に立とうとする」エージェントの性質そのものに対する汎用的な解決策は、まだ存在しません。そのうえで、Varonis はアーキテクチャ面で 4 つの制御を挙げています。

まず前提として、メッセージオブジェクト経由の脆弱性に対しては 2026.4.23 以降への更新が推奨されます。そのうえで、設計面では次の対応が有効です。

 指示ファイルを強制ポリシーとして扱う:
エージェントへの指示ファイルを「お願い」ではなく、バージョン管理された強制力のあるポリシーとして運用します。

 外部送信にゲートを設ける:
初めての宛先への送信には承認を挟み、乗っ取られたエージェントが信頼済みアカウントからフィッシングを中継できないようにします。

 コネクタ権限を起動元の信頼レベルに合わせる:
外部メールを処理する受信箱が、同時に CRM 全体も読み出せる、といった過剰な権限付与を避けます。

 高リスク操作は人間の承認を待つ:
認証情報の転送や送金など、影響の大きい操作は自動実行せず、人による確認を必須とします。

allowlist の設計も見直す余地があります。OpenClaw 公式ドキュメントによれば、チャネルの認可は既定で ID 先行（ID-first）です。

参考: OpenClaw 公式ドキュメント（Slack）
“inbound authorization and channel routing are ID-first by default.”
（受信の認可とチャネルのルーティングは、既定で ID 先行である。）
https://docs.openclaw.ai/channels/slack

allowlist は表示名ではなく安定した ID で構成し、Slack であればチャネル ID を用いることが推奨されます。dangerouslyAllowNameMatching のような名前照合は避け、ホストコマンド実行には exec approvals（実行承認のインターロック）を有効にしておくと安全性が高まります。あわせて、Docker による隔離（サンドボックス）や、既定で有効なメモリ機能の扱いも検討に値します。隔離環境の構築や権限設定ファイルの具体的な書き方は、関連記事『OpenClaw とは — 自律型 AI エージェントの仕組みと基本機能』の権限設定の項を参照してください。

なお、オランダのデータ保護当局（Autoriteit Persoonsgegevens）は、データ侵害とアカウント乗っ取りのリスクを理由に、機微なデータを扱うシステム上で OpenClaw を実行しないよう利用者・組織へ助言しています。導入判断にあたっては、こうした当局の見解も参考になります。

両チームの結論は、同じメンタルモデルに収束します。Varonis は「システムへのアクセス権を持つが、何が不審かを察知する勘のない新人社員」として扱うべきだとし、Imperva は「入力を信頼してしまう、認証済みの実行者（authenticated executor）」と捉えています。便利さと危うさは表裏一体であり、権限と送信経路を意図的に絞り込む設計が、当面の現実的な守りになります。

まとめ

2026 年 6 月、OpenClaw に対する 2 つの攻撃が相次いで公表されました。1 つはパッチで修正済みですが、もう 1 つはパッチで塞げる種類のものではありません。エージェントに与える権限と外部送信の経路を意図的に絞り込む設計が、当面の現実的な守りになります。

• 連絡先や vCard 経由のプロンプトインジェクションは 2026.4.23 で修正
• 修正版は連絡先名や位置情報ラベルを信頼できないメタデータとして分離
• 通常のメール 1 通で AWS キーや顧客データを流出させたエージェントフィッシング
• 送信者確認を指示しても緊急性や日常性で崩れる確認手順
• 偽 URL や悪意ある OAuth の検知はエージェントが比較的得意
• チャネル拡張に残っていた表示名ベースの allowlist 解決バグ
• 当面の守りは更新と権限・外部送信の最小化、高リスク操作の人間承認

以上、最後までお読みいただきありがとうございました。