2026年2月初旬、セキュリティ研究者がOpenClawのスキルシステムに深刻なリモートコード実行（RCE）脆弱性を発見した。CVE番号が割り当てられ、CVSS 9.8のクリティカル評価を受けた。影響を受けるのは、サードパーティスキルをインストールしている全てのOpenClawユーザーだ。
脆弱性の核心は単純だった。OpenClawのスキルランタイムは、サードパーティのスキルコードをメインプロセスと同じNode.jsランタイム内で実行する。スキルがインストールされると、そのJavaScriptコードはOpenClawのメインプロセスと同じ権限で動作する。ファイルシステムへのフルアクセス、ネットワークへのフルアクセス、環境変数へのフルアクセス。サンドボックスはない。
脆弱性の詳細
研究者が発見した具体的な攻撃ベクトルは以下の通りだった。OpenClawのスキルマニフェストには、スキルの初期化時に実行されるセットアップスクリプトを指定するフィールドがある。このフィールドに悪意のあるコードを含むスキルをnpmレジストリに公開し、ユーザーがそのスキルをインストールすると、セットアップスクリプトがユーザーのマシン上でフル権限で実行される。
これは理論上の脆弱性ではなかった。研究者はProof of Concept（PoC）を公開し、悪意のあるスキルがSSHキーの窃取、環境変数の外部送信、リバースシェルの確立が可能であることを実証した。
さらに厄介なのは、この脆弱性がOpenClawの設計そのものに根差していることだ。スキルシステムはパフォーマンスと開発の容易さを優先し、プロセス内でスキルを実行する設計を採用していた。サンドボックスを後付けすることは技術的に可能だが、既存の何千ものスキルとの互換性を維持しながら実装するのは現実的に困難だった。
攻撃面の分析
この脆弱性の影響範囲を理解するには、OpenClawの典型的なデプロイメント環境を考える必要がある。
多くのOpenClawユーザーは、個人のラップトップまたはデスクトップ上で直接実行している。つまり、OpenClawプロセスはユーザーのホームディレクトリ、ドキュメント、ブラウザのCookie、SSHキー、GPGキー、クラウドプロバイダーの認証情報に直接アクセスできる環境で動作している。悪意のあるスキルがRCEを獲得した場合、ユーザーのデジタルライフ全体が露出する。
サーバー上で実行しているユーザーの場合はさらに深刻だ。OpenClawがDockerコンテナ内で実行されていない限り（多くのユーザーはそうしていない）、プロセスはサーバー上の他のサービス、データベース、設定ファイルにアクセスできる。マルチテナント環境では、一つの悪意のあるスキルが複数のユーザーのデータを侵害する可能性がある。
OpenClawのメンテナーチームは脆弱性の報告を受けて迅速に対応した。スキルマニフェストのセットアップスクリプトフィールドを無効化するパッチがリリースされた。しかし、これは表面的な修正に過ぎなかった。スキルのランタイム実行自体が依然としてプロセス内で行われている以上、悪意のあるスキルコードがユーザーの環境にアクセスするパスは他にも存在する。
NanoClawのコンテナ隔離モデル
NanoClawはこの種の脆弱性に対して構造的に免疫がある。その理由はアーキテクチャの根本的な違いにある。
NanoClawではAIエージェントはコンテナ内で実行される。Apple ContainerまたはDocker——どちらの場合も、エージェントプロセスはホストシステムから隔離されたサンドボックス内で動作する。コンテナにはファイルシステムの読み書き権限がなく、ネットワークアクセスは制限され、ホストの環境変数にはアクセスできない。
APIキーの受け渡しもセキュアだ。NanoClawはAPIキーを環境変数としてコンテナに渡さない。代わりにstdin経由でJSON形式で渡す。コンテナ内のプロセスはキーをメモリ上でのみ使用し、ディスクに書き込まない。コンテナが侵害されても、攻撃者が得られるのはそのコンテナのセッションに限定されたアクセスだ。ホストシステムのSSHキー、ブラウザのCookie、他のサービスの認証情報には到達できない。
この隔離はオペレーティングシステムレベルで強制される。NanoClawのアプリケーションコードがバグを含んでいても、コンテナの境界はOSカーネルによって維持される。Apple ContainerやDockerのセキュリティモデルは、何千人ものエンジニアが何年もかけて堅牢化してきたものだ。NanoClawの80行のコンテナオーケストレーションコードは、その投資を活用しているに過ぎない。
プラグインとスキルのセキュリティモデル
OpenClawのRCE問題は、プラグイン/スキルシステムの設計哲学に関するより広い問題を提起している。
OpenClawのアプローチは「信頼ベース」だ。スキルはインストール時にコードレビューなしで受け入れられ、メインプロセスのコンテキストで実行される。これは開発者体験としては優れている——スキルの作成とインストールが簡単で、パフォーマンスオーバーヘッドが少ない。しかし、セキュリティモデルとしては脆弱だ。
NanoClawのアプローチは「隔離ベース」だ。エージェントがどのツールを使うかはClaude Codeが決定し、ツールの実行はコンテナ内で行われる。サードパーティのコードがユーザーのホスト環境に直接触れる機会がそもそもない。NanoClawにはプラグインマーケットプレイスが存在しないが、これは制限ではなく設計上の判断だ。Claude Codeのスキルシステム——CLAUDE.mdファイルによる宣言的なスキル定義——は、コード実行を伴わない安全なカスタマイズメカニズムを提供する。
修正の難しさ
OpenClawがこの脆弱性を根本的に修正することが困難な理由は、修正がアーキテクチャの変更を意味するからだ。
スキルをサンドボックス内で実行するには、プロセス分離、IPC（プロセス間通信）メカニズム、権限システムの全てを設計し直す必要がある。既存の何千ものスキルは、メインプロセスのグローバルスコープにアクセスできることを前提に書かれている。サンドボックスを導入すれば、これらのスキルの大半が動作しなくなる。
これはOpenClawに固有の問題ではない。プロセス内プラグインシステムを採用した全てのプロジェクトが直面する構造的なジレンマだ。最初にセキュリティモデルを設計しなければ、後から追加するコストは指数関数的に増大する。
NanoClawはこのジレンマを回避した。プラグインシステムを持たないことで、プラグインのセキュリティ問題自体が存在しない。「最も安全なコードは書かれなかったコードだ」という原則の最も直接的な適用例だ。
セキュリティは機能ではなくアーキテクチャだ
この事件から得られる最も重要な教訓は、セキュリティはアーキテクチャの特性であるということだ。
OpenClawのメンテナーは優秀なエンジニアだ。脆弱性の報告に迅速に対応し、パッチを素早くリリースした。しかし、根本的なアーキテクチャが「全てのコードが同じ権限で同じプロセス内で実行される」である限り、新しい攻撃ベクトルは次々と発見される。モグラ叩きだ。
NanoClawのアプローチは異なる。セキュリティをアプリケーションロジックのレイヤーではなく、インフラストラクチャのレイヤーで実現する。コンテナ隔離はバグがあっても安全だ——NanoClawのオーケストレーションコードにバグがあっても、OSレベルのコンテナ境界がホストシステムを保護する。
これは「深層防御」の原則だ。NanoClawの500行のコードは完璧ではない。しかし、そのコードがコンテナ隔離の上に構築されているため、アプリケーションレベルの脆弱性がシステムレベルの侵害に escalate する経路が構造的に存在しない。
OpenClawのRCE脆弱性は、AIエージェントのセキュリティが後付けできないことを改めて証明した。セキュリティはアーキテクチャの最初の判断で決まる。NanoClawは「コンテナ内で実行する」という最初の判断で、この種の脆弱性を根本的に排除した。