セキュリティ企業のArmadinは、AnthropicのデスクトップAIエージェントであるClaude Cowork(Windows版)について、サンドボックス内でroot権限による任意のコマンド実行と、ネットワーク制限の完全な解除を組み合わせられる欠陥を発見したと公表しました。
研究者はこの内容を2026年3月20日にAnthropicへ報告していますが、Anthropicは3月24日、攻撃の実行にはホスト側で既にローカルコード実行ができている状態が前提になるという理由から、これをセキュリティ上の脆弱性とは認定しないという回答を返しています。当サイトでは以前、Claude Codeのネットワークサンドボックスを迂回できる脆弱性を取り上げましたが、今回の一件も、AnthropicのAIエージェント製品が持つサンドボックスの境界線をどこまで信頼してよいのかという同じ論点を投げかける事例です。
サマリー
- セキュリティ企業Armadin(創業者はMandiant創業者のKevin Mandia氏)の研究者Nick McClendon氏が、Claude Cowork for Windowsのサンドボックスに関する調査結果を公表した
- 検証はClaude Desktop for Windowsバージョン1.9255.2.0を対象に行われ、2026年3月20日にAnthropicへ報告された
- 侵入の起点は、claude.exeがアプリケーションのフォルダから先にUSERENV.dllを読み込む仕様を利用したDLLサイドローディングで、これによりAnthropicの正規の署名を持つプロセス内でコードを実行できる状態を作り出している
- この信頼された立場を使い、Cowork内部のVMを操作する名前付きパイプ経由のRPC(プロセス間通信)を解析したところ、isResumeとallowedDomainsという2つの未検証パラメータが見つかった。isResumeをtrueに指定すると、本来は新規の権限のないユーザーを作成する処理がバイパスされ、root権限を含む任意の既存ユーザーとしてコマンドを実行できてしまう
- allowedDomainsに任意のワイルドカードを指定すると、通信先を制限しているドメイン許可リストがその実行についてのみ無効化され、ネットワーク制限のないアウトバウンド通信が可能になる
- 2つの欠陥を組み合わせることで、サンドボックス内でroot権限を得たうえで、既知のLinuxコマンドを使ってVM側の名前空間へ抜け出し、外部への無制限な通信を使って機密情報を持ち出すところまで実証されている
- Anthropicは2026年3月24日、攻撃の成立にはホスト上でのローカルコード実行という前提条件が必要であるため、これをセキュリティ上の脆弱性とは扱わないと回答している
| 項目 | 内容 |
|---|---|
| 報告者 | Armadin(研究者:Nick McClendon氏) |
| 報告日 | 2026年3月20日(Anthropicへ) |
| Anthropicの回答 | 2026年3月24日、脆弱性として非認定(ローカルコード実行が前提条件のため) |
| 検証環境 | Claude Desktop for Windows バージョン1.9255.2.0 |
| 侵入の起点 | claude.exeへのDLLサイドローディング(USERENV.dll) |
| 見つかった主な欠陥1 | isResumeパラメータの未検証によるroot権限での任意コマンド実行 |
| 見つかった主な欠陥2 | allowedDomainsパラメータの未検証によるネットワーク許可リストの無効化 |
| 実証された影響 | サンドボックス脱出、root権限奪取、無制限な外部通信、機密ファイルの外部送出 |
目次
何が起きたか
Claude Coworkは、Anthropicが非エンジニアの知識労働者向けに提供しているデスクトップ向けのAIエージェント製品で、内部ではClaude Codeをサンドボックス環境で動かすことでファイル操作やツール実行を行っています。Windows版では、Hyper-Vで隔離されたUbuntu仮想マシンの中でこれを実行しており、名前付きパイプによる署名検証つきの通信、bubblewrapによる名前空間の分離、セッションごとの権限のないユーザー、seccompフィルタ、ドメインを制限した通信プロキシという、複数の防御層が重ねられています。Armadinは、この防御層を外側から検証し、最終的にサンドボックス内でroot権限を得たうえで、制限のない外部通信を行えるかどうかを調べる形で調査を進めました。
調査の結果、Armadinは実際にこの目標を達成しています。攻撃の入口はDLLサイドローディングと呼ばれる手法で、claude.exeがUSERENV.dllというシステムのライブラリを、正規のシステムフォルダより先にアプリケーション自身のフォルダから読み込む仕様を悪用したものです。同じ名前で偽のライブラリを用意してアプリケーションのフォルダに置いておくと、Anthropicの正規の署名を持つclaude.exeのプロセス内で、攻撃者の用意したコードが実行されてしまいます。ここから、Cowork内部のVMを制御するCoworkVMServiceという名前付きパイプサービスに対して、あたかも正規のクライアントであるかのように通信できる状態が作られました。
起点となったDLLサイドローディングと、見つかった2つの未検証パラメータ
CoworkVMServiceは、通信してきたプロセスの署名を検証し、Anthropicによる正規の署名であることを確認したうえでコマンドを受け付ける仕組みになっています。Armadinは署名検証そのものを直接突破する方法(署名情報の複製や、別の信頼チェーンの構築)も試していますが、いずれも失敗しています。そのため、正規の署名を持つプロセスの中からコードを実行するという、DLLサイドローディングによる回り道が採用されました。
正規のクライアントとして通信できる状態になったArmadinは、サービスのログファイルに残されていた情報と、意図的に不正な形式のリクエストを送ることで返ってくるエラーメッセージを手がかりに、このRPCが受け付けるパラメータの全体像を洗い出しています。この過程で見つかったのが、spawnというコマンド実行用のRPCメソッドに含まれる、isResumeとallowedDomainsという2つのパラメータです。
isResumeは本来、以前のセッションを再開するためのパラメータですが、これをtrueに設定すると、新規の権限のないユーザーを作成するという通常の処理そのものがスキップされてしまい、rootを含め任意の既存ユーザーとしてコマンドを実行できることが分かりました。実際にrootを指定してリクエストを送ったところ、bubblewrapによる隔離環境の内側で、root権限を持つシェルがそのまま得られています。
allowedDomainsは、通信を許可するドメインの一覧を指定するためのパラメータですが、ここにワイルドカードを指定すると、通常は許可されていない宛先への通信を試みても拒否されるはずのプロキシが、その回だけ制限なしに通信を許可してしまう挙動が確認されました。
サンドボックスからの完全な脱出
root権限を得た状態のサンドボックス内では、通常のLinuxのケーパビリティがすべて有効になっており、強制アクセス制御の仕組みも制限されていない状態だったとされています。加えて、サンドボックスの外側にあたるVM本体で動作しているプロセス(プロセスID1)が、サンドボックス内からも見える状態になっていました。この状態であれば、Linuxの標準的な名前空間操作のコマンドを使って、サンドボックスが分離しているはずのマウント・プロセス・ネットワークなどの各名前空間から、VM本体側の名前空間へと移動することができてしまいます。root権限の奪取とネットワーク制限の解除という2つの欠陥を組み合わせることで、Armadinはサンドボックスの外側にある機密ファイルを、外部の任意のサーバーへと送信するところまで実際に確認しています。
Anthropicは脆弱性と認めず-前提条件を巡る評価の違い
今回の一連の欠陥についてAnthropicは、この攻撃を成立させるには、そもそも攻撃者がホスト側のWindows環境で何らかのコードを実行できる状態になっている必要があるとして、自社の脅威モデルの範囲外にあたるという説明をしています。攻撃者が既にホスト上でコードを実行できているのであれば、Cowork以外の経路でも被害を与えることは可能であり、Cowork固有の脆弱性とは位置づけないという考え方自体は、一定の合理性を持つ説明です。
一方で、Armadin側の視点に立てば、この評価には見過ごせない点もあります。サンドボックスという仕組みが本来提供しようとしている価値は、仮にホスト上で何らかの不正なコードが動いてしまった場合でも、被害をそのサンドボックスの内側に閉じ込め、root権限の奪取や無制限な外部通信にまでは至らせないという、多層防御としての意味合いです。前提条件として何らかのローカルコード実行を要求する脆弱性であっても、サンドボックスという境界そのものを容易に無効化できてしまうのであれば、防御を一枚剥ぎ取られたのと同じ状態になります。両社の評価が分かれているのは、脆弱性という言葉の適用範囲をどこまで狭く取るか、そして多層防御の1枚をどこまで重視するかという、立場の違いに起因していると見るのが公平だと思います。
原因はRPCの境界検証を呼び出し元に委ねた設計にある
技術的な根本原因を一言で言えば、CoworkVMServiceが接続してきたクライアントの身元(署名)は確認していたものの、そのクライアントが送ってくるリクエストの中身(パラメータ)そのものの妥当性検証を、ホスト側のサービスではなくVM内部のプログラムに委ねていた点にあります。ネットワークエンジニアとして境界設計に携わってきた経験から言うと、認証(誰であるかの確認)と認可(何をしてよいかの制御)を混同してしまうと、今回のような抜け道が生まれやすくなります。CoworkVMServiceは通信してきた相手がAnthropicの署名を持つ正規のクライアントであることまでは確認していましたが、そのクライアントが本来のセッションの範囲を超えた操作(他人の権限での実行や、通信制限の解除)を要求してきた場合の妥当性チェックまでは行っていなかったということです。
情報システム部門への示唆
Claude Coworkのように、業務端末の中にHyper-Vで隔離されたVMを持ち込むタイプのAIエージェント製品は、これまで開発者向けのツールに限られていたローカルVMという攻撃対象を、非エンジニアの一般的な業務端末にまで広げる性質を持っています。VM自体はHyper-Vの通常のツールからは見えにくい構成になっているため、既存のエンドポイントセキュリティ製品の可視性が届きにくいという点も、あわせて意識しておく必要があります。
実務的な対応として、Cowork機能を必要としない端末についてはClaude Desktopをアンインストールし、名前付きパイプサービスごと取り除いてしまうのが最も確実な対策です。業務上どうしても必要な端末については、AppLockerのパッケージアプリルールを使い、Claudeのパッケージを利用できるアカウントを特定のグループに限定することで、サイドローディングを狙う攻撃者が標的にできる対象を絞り込めます。加えて、claude.exeがUSERENV.dllをシステムフォルダ以外の場所から読み込んだ場合を検知するSysmonのイベントID7の監視ルールを整備しておくと、同種の手口を早期に発見しやすくなります。同様の手口はVERSION.dllやWINMM.dll、dwmapi.dllといった他の定番ライブラリでも成立しうるため、監視対象は1つのファイル名に限定せず横展開しておくことをお勧めします。当サイトで以前取り上げたClaudeのFiles APIを悪用した情報持ち出しの脆弱性やClaude Codeのネットワークサンドボックス迂回ともあわせて、AIエージェント製品のサンドボックスは絶対的な境界ではなく、あくまで多層防御の1枚として捉え、ホスト側の対策と組み合わせて運用することをお勧めします。








