2026年1月のある火曜日の朝、セキュリティ研究者がGitHubにPoC（概念実証）エクスプロイトを公開した。タイトルは控えめだった：「OpenClaw WebSocket Origin Bypass」。しかしその影響は控えめどころではなかった。
エクスプロイトはシンプルさが際立っていた。攻撃者は数行のJavaScriptを含む悪意あるWebページを作成するだけでいい。OpenClawユーザーがそのページを訪れると——メールやSlackのリンクをクリックするだけで——JavaScriptがローカルマシンで動いているOpenClawインスタンスにサイレントで接続し、任意のコマンドを実行する。認証不要。リンクをクリックする以外のユーザー操作も不要。マシンへのフルアクセスが手に入る。
CVE-2026-25253のCVSSスコアは8.8。セキュリティコミュニティはこれをクリティカルと呼んだ。OpenClawチームは当初「WebSocketアーキテクチャの既知の制限」と呼んだ。この二つの表現の乖離が、危機がどのように展開したかをすべて物語っている。
タイムライン
最初のCVEが1月14日に公開された。48時間以内に、Shodanのスキャンでインターネット上に公開されているOpenClawインスタンスが42,000件以上あることが判明した——URLさえ知っていれば誰でも悪用できるインスタンスだ。多くは企業のデプロイで、内部ファイルシステム、データベース、環境変数に保存された認証情報へのアクセス権を持って動いていた。
最初のパッチがリリースされる前に、CVE-2026-26327が公開された：露出したインスタンスでログインを完全にスキップできる認証バイパスだ。同じ週に2つのクリティカルな脆弱性、どちらもリモートから悪用可能、どちらも同じ42,000以上の露出インスタンスに影響する。
そしてClawHubの問題が浮上した。セキュリティ研究者がOpenClaw公式スキルマーケットプレイスを監査し始め、公開されているスキルの41.7%に脆弱性が含まれていることを発見した——偶発的なものもあれば、意図的に仕込まれたものもある。数百の悪意あるスキルが、ユーザーがインストールするのを待ちながら、過去数ヶ月にわたって静かにアップロードされていた。XDA Developersが「OpenClawの使用をやめてください」という記事を公開し、バイラルになった。
これは単なる不運ではなかった
OpenClaw危機を一連の不運なバグとして片付けたくなる気持ちはわかる——どんなプロジェクトにも起こりうる類のもので、パッチで修正して前に進めばいい、と。しかしそのフレーミングは本質的な問題を見逃している。これらの脆弱性はランダムではなかった。OpenClawがまだ週末プロジェクトで、セキュリティが主要な関心事ではなかった頃に行われた、特定のアーキテクチャ上の決定の予測可能な結果だった。
WebSocketの信頼モデルが最初の問題だった。OpenClawのWebインターフェースはOriginヘッダーを検証せずにWebSocket接続を受け入れる。これは2012年から知られているよく文書化された脆弱性クラス——クロスサイトWebSocketハイジャック——だ。修正は簡単：Originヘッダーをチェックするだけ。しかしOpenClawでそれを修正すると、許容的なモデルを前提に育ったプラグインエコシステムが壊れるため、先送りにされ続け、最終的にCVE-2026-25253になった。
第二の問題はOSレベルの権限だった。OpenClawスキルをインストールすると、それはOpenClawプロセス自体と同じ権限で動く。ほとんどのシステムでは、ファイルの読み取り、ネットワークアクセス、コマンド実行、APIキーやパスワードを含む環境変数の読み取りができることを意味する。サンドボックスなし、ケイパビリティモデルなし、スキルに必要なものだけアクセスを許可する方法もない。インストールするすべてのスキルは暗黙的にすべてのものを信頼される。
第三の問題はJavaScriptのサプライチェーンだった。OpenClawのnode_modulesには1,200以上のパッケージが含まれている。ClawHubの悪意あるスキルはこれを利用し、人気のあるパッケージに似た名前のパッケージを公開——タイポスクワッティング——して、依存関係として取り込まれるのを待った。大きな依存ツリーを持つ動的言語では、このような攻撃をプラットフォームレベルで防ぐことはほぼ不可能だ。
セキュア・バイ・デザインとは実際どういうことか
ZeroClawは異なる前提のもとで構築された。「後でセキュリティを追加する」ではなく、「セキュリティの制約が最初からアーキテクチャを形作る」という考え方だ。
Rustの所有権システムはコンパイル時に脆弱性クラス全体を排除する。バッファオーバーフロー、use-after-free、データ競合——これらはRustコードでパッチが必要なバグではなく、コンパイルエラーだ。CVE-2026-25253がOpenClawで可能だったのは、JavaScriptの動的な性質がセキュリティ境界を言語レベルで強制することを難しくしているからでもある。Rustでは、それらの境界はコードが実行される前にコンパイラによって強制される。
ゲートウェイペアリングはリモートアクセスのパスワード認証を置き換える。ポートを公開してユーザーが強力なパスワードを設定することを期待する代わりに、ZeroClawはクライアントとゲートウェイ間の暗号ペアリングを要求する——Bluetoothペアリングの仕組みに似ている。インターネット上でZeroClawインスタンスを見つけた攻撃者は、ペアリングキーなしでは何もできない。
デフォルト拒否のアローリストモデルは、エージェントがアクセスする前に、すべてのツール、ファイルパス、ネットワークエンドポイントを明示的に許可する必要があることを意味する。指定されたワークスペース外のファイルを読もうとするスキルはアクセスではなく権限エラーを受け取る。リストにないエンドポイントへのネットワークリクエストはブロックされる。デフォルトはアクセスなし；必要なものだけを正確に許可する。
シンボリックリンクエスケープ検出を伴うワークスペーススコーピングはパストラバーサル攻撃を防ぐ。悪意あるスキルがシンボリックリンクをたどってサンドボックスから脱出しようとしても、ZeroClawはデータにアクセスされる前に試みを検出してブロックする。
そしてシングルバイナリアーキテクチャはサプライチェーン攻撃面を完全に排除する。node_modulesなし、パッケージレジストリなし、監査すべき推移的依存関係なし。数百の悪意あるClawHubスキルを可能にした攻撃ベクターは単純に存在しない。
移行する
現在OpenClawを動かしているなら、移行パスは簡単だ。まずOpenClawのデータをバックアップする——会話履歴と設定は`~/.openclaw/`にあり、何かに触れる前にコピーが欲しい。
ZeroClawをシングルコマンドでインストール：
```bash curl -fsSL https://raw.githubusercontent.com/zeroclaw-labs/zeroclaw/main/scripts/bootstrap.sh | bash ```
まずドライランモードで移行ツールを実行して、何が変わるかプレビューする：
```bash zeroclaw migrate openclaw --dry-run ```
何がインポートされ、何がスキップされ、何に手動対応が必要かが正確に表示される。プレビューに満足したら、実際の移行を実行：
```bash zeroclaw migrate openclaw ```
メモリ、設定、チャンネル設定が引き継がれる。チャンネルが再接続することを確認し、シンプルなクエリでテストする。全体のプロセスは通常10分以内で完了する。
業界が学ぶべきこと
OpenClaw危機は一つのプロジェクトのセキュリティ失敗の話ではない。スクリプトツールの前提でインフラソフトウェアを構築するとどうなるかという話だ。
AIエージェントは認証情報を扱い、ファイルシステムにアクセスし、コードを実行し、24時間365日動く。これはインフラであり、スクリプトではない。Webサーバーと同じセキュリティの厳格さ、データベースと同じアーキテクチャの規律、マシン上で昇格した権限で動く他のあらゆるものと同じ脅威モデリングが必要だ。
セキュリティは許容的なアーキテクチャに後付けできない。最初から設計に組み込む必要がある——言語の選択、権限モデル、デプロイアーキテクチャ、プラグインシステムに。そうでなければ、42,000の露出インスタンスと8.8のCVEが生まれる。
問題はAIエージェントが標的にされるかどうかではない。それが起きたとき、アーキテクチャがそれに耐えられるよう構築されているかどうかだ。