AnthropicのAIエージェント「Claude Cowork」に、なかなか嫌な穴が見つかりました。
ざっくり言うと、本来は隔離されているはずの仮想環境から抜け出し、Mac上のファイルにまで手を伸ばせる可能性があった、という話です。AppleInsiderが伝えたこの記事は、AIの便利さの裏側にある「権限管理」の甘さをかなり生々しく示しています。
今回の話でややこしいのは、Claude Coworkが「Macの上でそのまま動いていた」のではなく、Linuxの仮想マシンの中で動く設計だったことです。
仮想マシンというのは、簡単に言えば「本物のPCの中に作った、別の小さなPC」です。AIをその中に閉じ込めておけば、万が一暴れてもMac本体には届きにくい。普通はそう考えます。
ところが Accomplish AI の研究者によると、その仮想マシン内でroot権限を取れてしまうと話が変わります。rootはLinuxでいちばん強い管理者権限です。要するに「そこでは何でもできる人」みたいなもの。
その結果、Coworkが用意していたMacのファイルシステムを共有する領域にまでアクセスできた、というのが今回の肝です。
しかも研究者のデモでは、Claudeにひとつ命令を与えただけで、許可されたフォルダの外にあるファイルを読み書きできたとのこと。許可の確認がもう一度出ることもなかったそうです。ここ、かなり怖いです。
AIエージェントは「指示されたことを淡々とやる」ので、いったん権限が外れてしまうと、人間が思う以上に静かに踏み込みます。ドラマチックな暴走より、こういう地味な突破のほうが現実には厄介だと思います。
研究者はこの攻撃手法を SharedRoot と呼んでいます。
名前だけ聞くと少し軽く見えますが、やっていることはかなりシリアスです。
攻撃には CVE-2026-46331 というLinux kernelの不具合が使われました。
CVEは、セキュリティ上の問題に付く識別番号だと思えば大丈夫です。今回の不具合は、traffic-control packet-editing code という通信制御まわりの処理にあり、copy-on-write の扱いミスで page-cache のメモリを壊せる可能性があったとされています。
用語が多いので少しだけ噛み砕くと、copy-on-write は「最初は共有しておいて、変更するときだけコピーする」仕組みです。便利ですが、実装を誤ると“触ってはいけない場所”がずれる。そこを突かれると、保護されたファイルを改ざんできてしまうことがあります。
Accomplish AI の説明では、このメモリ破壊を使って、あとで root 権限のサービス coworkd が実行するファイルをすり替えたそうです。
その結果、仮想マシンの中でrootを取れた。しかも、そのrootを足がかりにして、Mac側の共有ファイルシステムに触れた、という流れです。
ここで重要なのは、Appleの仮想化システムそのものを破ったわけではないという点です。
攻撃者はもっと手前、Linux kernelの穴を使って「仮想環境の中で強い権限」を取っただけ。それでも、CoworkがVMの中に置いていた共有フォルダが広すぎたせいで、外側のMacにまで被害が波及したわけです。
防御が一枚だけだと足りない、という教科書みたいな失敗例に見えます。
研究者が挙げた対象には、SSH private key、cloud credentials、browser data などが含まれます。
SSH private keyはサーバー接続のカギ、cloud credentialsはクラウドサービスに入るための認証情報、browser dataはブラウザの保存データです。どれも、漏れると面倒では済みません。
ただし、Macの全ファイルに自動的にアクセスできたわけではありません。
最終的に読めるかどうかは、そのMacにログインしているユーザーの権限や、macOS側の保護機能に左右されます。システム領域や一部のプライベートデータは、macOSの仕組みでさらに守られているからです。
とはいえ、これは「だから安心」ではありません。
普通の個人ユーザーでも、ブラウザのセッションやクラウドの鍵、開発用のSSHキーが取られたら相当きつい。正直、OSが守ってくれる範囲より、その手前にある実用的な秘密情報のほうがずっと価値が高いことが多いです。
Anthropicは7月7日の更新で、Coworkのクラウド実行をデフォルトにしています。
これは、AIが手元のMacではなくAnthropicのサーバー側で動くモードです。ユーザーのPCがオフラインでも処理を続けられるのが利点で、Webやモバイルから使いやすくする狙いもあります。
この変更によって、今回のようなローカル仮想マシンからの脱出経路は避けやすくなります。
少なくとも「Mac上のVMを抜ける」という今回の穴は、そのままでは使いにくいはずです。
ただし、ここで勘違いしてはいけないのは、クラウド実行にしたからといってAIエージェントの危険が消えるわけではないことです。
むしろ、別の形でリスクが残ります。たとえば、クラウド上の処理であっても、ユーザーが重要ファイルやアカウントを渡していれば、その情報を読み取れる立場には変わりありません。
要するに、場所を変えただけで、権限の重さそのものは別問題です。
Accomplish AI はこの問題を Anthropic に報告したものの、Anthropic側は “Informative” としてクローズしたとされています。
これは「情報提供として受け取ったが、直ちに修正対象とまでは扱わない」というニュアンスだと思ってよさそうです。ただ、Anthropicがなぜそう判断したのか、公開の説明はないそうです。
研究者側は、ユーザーが許可したフォルダだけをマウントし、可能なら読み取り専用にするべきだと提案しています。
これ、地味ですがかなり本質的です。AIに「必要なものだけ渡す」という原則は、口で言うより実装で守るのが難しい。便利さのために丸ごと見せたくなる気持ちはわかりますが、そこをグッと絞れるかが安全性の差になると思います。
さらに、権限の強いサービスやLinuxの機能まわりにも、もっと堅い防御が必要だと指摘しています。
攻撃者は一番弱いところを狙うので、仮想化ソフトが堅くても、周辺サービスが甘ければ抜け道になります。今回の件はまさにその典型です。
一般ユーザーにとっては、まずローカル処理よりクラウド実行を優先するのが無難です。
そして、Claudeに見せるフォルダは本当に必要なものだけに絞るべきです。SSHキーやクラウド認証情報、ブラウザの保存データが入った場所は、できれば触らせないほうがいいでしょう。
もし不審なファイルを扱わせるためにローカルCoworkを使っていたなら、その間に見えた可能性のある認証情報はローテーション、つまり鍵の再発行やパスワード変更を考えたほうが安全です。
「実際に悪用された証拠はない」からといって油断すると、後で面倒が長引きます。セキュリティは、被害が見えてから動くとたいてい遅いです。
AIエージェントは、うまく使うと本当に便利です。雑務をかなり肩代わりしてくれる。
でも、今回のような話を見ると、**“何を任せるか”より“どこまで触らせるか”が本体**なんだと改めて思います。便利さは確かに魅力的ですが、権限設計を雑にすると、その便利さがそのまま弱点になります。
参考: Claude Cowork can escape its sandbox, rummage through all of your files
