2026年1月末、AIエージェントプラットフォーム「OpenClaw」がGitHub史上最速のペースで100,000スターを達成した。しかし、その爆発的普及の裏側で、512件の脆弱性、21,639個以上の認証なし公開インスタンス、そしてCVSS 8.8のRCE脆弱性（CVE-2026-25253）が相次いで発覚している。筆者はセキュリティエンジニアとして脆弱性診断やペネトレーションテストに従事してきた経験から、プロトコルやHTTPヘッダ一つの設定ミスが致命的な脆弱性になり得ることを何度も目撃してきた。OpenClawの事例は、まさにそのパターンの再現である。本稿ではテクノロジーの視点から、OpenClawが抱える構造的セキュリティ問題を技術的に解析し、エージェンティックAI攻撃面の産業化が進む2026年において、エンタープライズが採るべき防御戦略を提示する。

OpenClawの異常な成長速度とセキュリティ検証の不在

OpenClawは2026年1月29日から30日にかけて、わずか48時間で100,000 GitHubスターを達成した。ピーク時のスター獲得速度は710件/時、1日あたり約34,168件という数値は、Kubernetesの91件/日と比較して18倍以上の速度である。Clawdis、Clawdbot、Moltbotと名称を変えながら進化してきたこのプロジェクトは、2026年1月30日に「OpenClaw」として最終的にブランドを確立した。

問題は、この異常な普及速度に対してセキュリティ検証がまったく追いついていなかったことである。オープンソースプロジェクトにおいて、100,000人が48時間で導入したということは、その大半がセキュリティレビューなしにローカル環境またはクラウド上でインスタンスを立ち上げたことを意味する。CrowdStrikeのレポートによれば、OpenClawの認証はデフォルトで無効化されており、127.0.0.1からの接続は自動承認される。NginxやCaddyなどのリバースプロキシを経由するとリクエストがlocalhostとして転送されるため、このlocalhost信頼のバイパスは容易に成立する。

2026年2月14日には、OpenClaw開発者のPeter SteinbergerがOpenAIへの参画を発表し、OpenClawはOpenClaw Foundationに移管された。OpenAIが財政・技術支援を行うとされているが、既にインターネット上に展開された数万のインスタンスに対するセキュリティ修復は、組織移管だけでは解決しない構造問題である。

CVE-2026-25253：ワンクリックRCEの技術解析

CVE-2026-25253（CVSS 8.8、CWE-669: Incorrect Resource Transfer Between Spheres）は、OpenClawの根本的なアーキテクチャ欠陥を示す脆弱性である。攻撃メカニズムは以下の通りだ。

OpenClawアプリケーションは、クエリストリングパラメータとしてgatewayUrlを受け取り、ユーザー確認なしに自動的にWebSocket接続を確立する。この過程で認証情報（クレデンシャル）が送信される。さらに、WebSocketサーバーはOriginヘッダの検証を実施しない。この設計により、攻撃者は被害者のブラウザを踏み台として利用し、ローカルネットワークの保護やファイアウォールをバイパスできる。

技術的に重要なのは、この攻撃がlocalhostインスタンス（インターネットに直接公開されていない環境）に対しても有効であるという点だ。被害者が悪意のあるリンクをクリックするだけで、ミリ秒単位でRCE（Remote Code Execution）が成立する。修正はv2026.1.24-1で提供されたが、これにはGateway TokenとAPIキーのローテーションも必要とされている。

筆者がかつてペネトレーションテストの実務で繰り返し確認してきたのは、マルチプラットフォーム環境では各プラットフォーム固有の攻撃面を個別に理解する必要があるという原則である。OpenClawの場合、WebSocket、HTTPクエリパラメータ、localhost信頼モデルという3つの攻撃面が複合的に悪用されている。単一の脆弱性ではなく、アーキテクチャ設計の組み合わせが致命的な攻撃チェーンを形成している点が、この脆弱性の本質的な危険性である。

Skills/Pluginsエコシステム：26%が脆弱性を含む汚染されたマーケットプレイス

OpenClawのセキュリティ問題は、コア製品だけに留まらない。Skills/Pluginsエコシステム全体が深刻な汚染状態にある。セキュリティ監査の結果、以下の数値が確認されている。

512件の脆弱性が確認され、うち8件はクリティカルに分類された。31,000件のエージェントスキルを調査した結果、26%が少なくとも1件の脆弱性を含んでいた。さらに、人気のあるOpenClawスキルの41%以上にセキュリティ上の問題が見つかっている。ClawHubの3,000スキルサンプルからは336件の悪意あるプラグインが発見され、感染率は10.8%に達する。

悪意あるスキルが実行する攻撃は多岐にわたる。暗号通貨ウォレットの認証情報窃取、macOS Keychainの認証情報抽出、ブラウザパスワードの窃取、クラウドサービストークンの流出が確認されている。これはデータポイズニング攻撃の産業化と同様の構造であり、サプライチェーン全体を汚染する攻撃パターンが、AIエージェントのPluginマーケットプレイスにも本格的に適用されたことを示している。

Authmindの分析によれば、1,937件のClawHubスキルのうち336件がGoogle Workspaceへのアクセスを要求し、170件がMicrosoft 365へのアクセスを要求していた。Slack、AWS、その他エンタープライズサービスへのアクセスを要求するスキルも多数存在する。つまり、一見便利なAIスキルを導入するだけで、企業の中核SaaSサービスへのOAuthトークンが攻撃者に渡るリスクが常態化しているのである。

21,639個の野良インスタンス：認証なし公開の実態とOAuthトークン窃取リスク

Bitsightの調査によれば、40,000以上のOpenClawインスタンスがインターネット上に公開されており、そのうち35.4%（約14,160件）が脆弱性フラグ付きとされている。Shodanでの探索では、これらの公開インスタンスからAPIキー、OAuthトークン、チャット履歴全文、サードパーティサービスの認証情報が漏洩していることが確認されている。

OpenClawの~/.openclaw/ディレクトリには、APIキーが.envファイルにプレーンテキストで保存される。暗号化はネイティブにサポートされていない。会話ログもJSONまたはベクター形式で平文保存される。単一の設定ミスにより、35,000件のメールアドレス、プライベートDM、約150万件のAPIトークンが流出した事例が報告されている。

Flareのアナリストは、30,000以上の侵害されたOpenClawインスタンスが、APIキーの窃取、メッセージの傍受、Telegram経由の情報窃取マルウェア配布に利用されていることを確認した。窃取されたOAuthクレデンシャルは、攻撃者がユーザーを偽装し、クラウドリソースにアクセスし、ハイブリッド環境内でラテラルムーブメント（横展開）を実行するために使用されている。

この状況は、プロンプトインジェクション攻撃の防御限界で分析した「完全修正不可能」な構造問題と同質である。OpenClawの場合、認証デフォルト無効という設計思想そのものが攻撃面を形成しており、パッチ適用では解決しない。

「プライバシー悪夢」：情報処理の不透明性とサプライチェーン攻撃の連鎖

Northeastern大学の研究者はOpenClawを「プライバシー悪夢」と評している。オランダのデータ保護当局（Autoriteit Persoonsgegevens）も、OpenClawがサイバーセキュリティとプライバシーの重大リスクをもたらすと公式警告を発した。情報処理の不透明性は以下の点に集約される。

第一に、Skills/Pluginsが要求する権限の範囲がユーザーに明示されない。Google Workspace、Microsoft 365、Slack、AWSなどエンタープライズサービスへの広範なアクセスが、スキルインストール時に暗黙的に付与される。第二に、会話ログを含むすべてのデータが平文で保存され、デバイスが侵害された場合やマルウェアスキルがインストールされた場合、数秒でデータ全量が窃取される。

2026年2月17日には、npm上のCline CLIバージョン2.3.0にサプライチェーン攻撃が確認された。攻撃者は侵害されたnpm公開トークンを使用し、OpenClawをステルスインストールするバージョンを公開。約4,000件のダウンロードが影響を受けた。Microsoftの脅威インテリジェンスチームは、悪意あるOpenClawインストールの増加を確認している。

筆者はSOC構築・運用の経験から、SOCの価値はツールではなく、アラートから判断までの人間のプロセスにあることを理解している。OpenClawの事例が示すのは、AIエージェントの野良展開が従来のSOC監視の範囲外で発生し、既存のセキュリティ運用プロセスでは検知できない「盲点」を生み出しているという現実である。

エンタープライズ防御戦略：野良インスタンスの検知・削除とアクセス制御設計

OpenClawの事例から導かれるエンタープライズ防御戦略を、具体的な技術措置として以下に整理する。

1. 野良インスタンスの検知と強制排除

Microsoftのセキュリティブログが推奨する通り、「アイデンティティ、分離、ランタイムリスク」の3層で防御を構築する必要がある。具体的には、ネットワーク内のOpenClawインスタンスをShodanやCensysの内部スキャン相当で探索する。SIEMルールにopenclaw、clawdbot、moltbot関連の通信パターンを追加する。CASBやプロキシで、ClawHub（Skills/Pluginsマーケットプレイス）への通信を監視・制御する。社内ポリシーとして、未承認AIエージェントの利用を明示的に禁止し、違反時のエスカレーションフローを整備する。

2. OAuthトークンと認証情報の保護

OpenClawがSaaSサービスに接続する際のOAuthフローを、IdP（Identity Provider）側で制限する。具体的には、条件付きアクセスポリシーでOpenClaw関連のクライアントIDを明示的にブロックする。OAuth同意フローの監査ログを有効化し、異常なスコープ要求を検知する。既に付与されたOAuthトークンの棚卸しを実施し、不審なアプリケーション連携を取り消す。これはアイデンティティ防衛の崩壊への対策と同じフレームワークで実行できる。

3. Docker隔離とクレデンシャル分離

Composioの技術ガイドが推奨するOpenClawのDockerハードニング手法を適用する。OpenClawを実行する場合は必ずDockerコンテナ内で隔離する。ホストファイルシステムのマウントを最小限に制限する。環境変数によるクレデンシャル注入を避け、シークレットマネージャー（HashiCorp Vault、AWS Secrets Managerなど）を使用する。ネットワークポリシーで、コンテナから外部APIへの通信先をホワイトリスト化する。

4. Skills/Pluginsのガバナンスフレームワーク

企業が使用するOpenClawスキルを事前承認制にする。承認プロセスには、スキルのソースコードレビュー、要求権限の監査、サンドボックスでの動作テストを含める。26%が脆弱性を含むマーケットプレイスから無条件にスキルを導入することは、企業ネットワークへの攻撃経路を自ら開放することに等しい。

構造的教訓：AIエージェント時代のセキュリティ・バイ・デザイン

OpenClawの事例は、個別のCVEやパッチ適用を超えた構造的教訓を含んでいる。

第一に、「認証デフォルトOFF」は利便性とセキュリティのトレードオフではなく、設計の誤りである。AIエージェントが企業のSaaSに接続し、ファイルにアクセスし、コードを実行する時代において、認証なしのデフォルト設定は構造的な脆弱性そのものである。

第二に、Pluginマーケットプレイスのセキュリティは、従来のアプリストア審査とは異なるガバナンスモデルを必要とする。OpenClawのClawHubでは、スキルがOAuthトークンを要求し、ファイルシステムにアクセスし、任意コマンドを実行できる。これはモバイルアプリのサンドボックスとは根本的に異なる脅威モデルであり、AIエージェント武装化の攻撃チェーンに直接組み込まれるリスクがある。

第三に、CrowdStrike、Cisco、Kaspersky、Microsoft、Vectra AIなど主要セキュリティベンダーが相次いでOpenClawに関する警告レポートを発行している事実は、AIエージェントセキュリティが今やエンタープライズセキュリティの最前線であることを示している。2026年のIPA情報セキュリティ10大脅威で「AIリスク」が初選出3位にランクインしたのは偶然ではない。

脆弱性診断の実務で筆者が常に実感してきたのは、脆弱性診断のノウハウは、開発段階で活かしてこそ価値があるという原則である。後付けのセキュリティは常にコストが高い。OpenClawに必要なのは、パッチの逐次適用ではなく、セキュリティ・バイ・デザインの根本的な再設計である。100,000スターの勢いで広がったプラットフォームに対して、後からセキュリティを注入する困難さは、今後のAIエージェント開発全体への警鐘として記録されるべきだ。

FAQ

OpenClawとは何か？なぜこれほど注目されているのか？

OpenClawはオープンソースのAIエージェントプラットフォームであり、AIアシスタントのローカル実行を可能にする。2026年1月30日に48時間で100,000 GitHubスターを達成したことで爆発的に注目された。Skills/Pluginsエコシステムにより拡張可能で、SaaSサービスとの連携機能を備えているが、セキュリティ設計の不備が複数指摘されている。

CVE-2026-25253はどの程度深刻か？

CVSS 8.8（High）と評価されたワンクリックRCE脆弱性である。攻撃者が作成した悪意のあるリンクを被害者がクリックするだけで、localhostインスタンスに対してもリモートコード実行が可能になる。v2026.1.24-1以降へのアップグレードとAPIキーのローテーションが必要である。

企業がOpenClawの利用を全面禁止すべきか？

全面禁止は現実的に困難だが、無条件の利用許可はリスクが高すぎる。Docker隔離、認証の強制有効化、Skills/Pluginsの事前承認制、OAuthトークンのスコープ制限など、技術的コントロールを前提とした条件付き利用が推奨される。

野良OpenClawインスタンスはどう検知するか？

ネットワーク内のポートスキャンとトラフィック分析が基本となる。OpenClawはデフォルトで特定のポートを使用するため、SIEM/NDRで該当ポートの通信を監視する。CASBを利用してClawHubへの通信を検出する方法も有効である。EDR製品でのopenclawプロセスの検知ルール追加も検討すべきだ。

OpenClawのPluginsは安全に利用できるか？

ClawHubマーケットプレイスの10.8%が悪意あるプラグインとされ、26%が何らかの脆弱性を含む現状では、無条件に安全とは言えない。企業利用の場合、ソースコードレビュー、権限監査、サンドボックステストを経た承認済みスキルのみを使用すべきである。

参考文献