この記事、かなり面白いです。AIエージェントの話というと、つい「便利な自動化」や「賢いアシスタント」を想像しがちですが、実際には“どこまで触っていいのか”の境界線が本当に難しい。今回の件は、その境界線があっさり破られた例だと思います。
The Hacker News が伝えたのは、Anthropic の Claude Cowork にある sandbox escape 脆弱性です。sandbox というのは、アプリやAIを「外に出られない安全な箱」に入れて動かす仕組みのこと。万が一おかしな動きをしても、箱の外には被害が広がらないようにするわけです。
ところが今回のケースでは、その箱が破られました。研究チーム Accomplish AI によると、ローカルの Cowork セッションで短いメッセージを1回送っただけで、AIエージェントがVMの中から抜け出し、接続していないはずのMac上のファイルまで読み書きできたそうです。しかも、許可ダイアログも出なかったというのが厄介です。普通の感覚だと、「さすがに何か聞かれるだろう」と思うのですが、そこが出ない。これは嫌な感じです。
脆弱性には SharedRoot というコードネームが付けられています。影響を受けたのは、修正前にローカルで Cowork を使っていた約50万台のmacOSユーザーだとされています。
仕組みを少しかみ砕くと、Claude Cowork のmacOSアプリは、ログイン中のユーザー権限で動きます。一方で、AIエージェント本体の作業は Apple の Virtualization framework を使って作られた Linux VM の中で行われます。さらに、そのVMには seccomp という制限もかけられています。seccomp は、Linuxで「このプログラムは危ないシステム操作をしないでね」と縛るための仕組みです。
ここだけ見ると、かなり慎重に作ってあるように見えます。ところが、ユーザーが接続したフォルダは root daemon の coworkd が VM に共有していました。そして決定的なのは、ホスト側のファイルシステム全体 / が、VMの中に読み書き可能な形で見えていたことです。研究者はこれを、ゲスト側の guest-root から /mnt/.virtiofs-root として見えると説明しています。
つまり、「VMの中からは外に出られない」はずなのに、実は外の家の鍵穴をそのまま持っていた、みたいな話です。外から見れば“別室”でも、壁の裏で本宅につながっていたら意味がない。ここが今回の肝です。
攻撃は、Linux kernel の act_pedit という通信制御まわりの機能を使い、CVE-2026-46331 を突くことで guest-root を取る、という流れです。CVE というのは脆弱性に付けられる管理番号で、「どの弱点の話か」を特定するためのものです。今回の CVE-2026-46331 は、記事では “pedit COW” と呼ばれていました。
ここで少し感心したのは、攻撃が“いきなり魔法のように抜ける”わけではないことです。まずは unprivileged user namespace と network namespace を作り、そこで CAP_NET_ADMIN という権限を得ます。CAP_NET_ADMIN は、ネットワーク関連の操作をかなり広く許す特権です。ふつうのユーザーには持たせたくないやつです。
Accomplish AI の CTO, Or Hiltch は、namespace 自体が悪いのではなく、「本来なら特権が必要な場所に、普通のユーザーでも届く足場を与えてしまう」のが問題だと説明しています。これはかなり核心を突いていると思います。安全機構って、たいてい単体では悪くないんです。悪いのは、その組み合わせと抜け道です。
そこから guest-root を得ると、VMの中からホストの / にアクセスできてしまう。結果として、Mac上のファイルを読むことも書くことも可能になります。SSH keys、cloud credentials、ローカルのメモや設定ファイルまで狙える。普通に考えて、かなりまずいです。
研究者のコメントで印象的だったのは、これは“単発のバグ”というより、“この種類の穴が定期的に出てくる”という話です。Linux の net/sched 系サブシステムには、unprivileged user でも届く経路とメモリバグがセットで出てくることがある、と。今回の act_pedit を塞いでも、次の似た系統がまた来るかもしれない、という見方です。
これ、かなり現代的な怖さだと思います。AIエージェントの防御って、アプリのロジックを固めるだけでは足りない。下のレイヤー、つまり kernel や namespace、マウント設定まで丁寧に見ないといけない。しかもその下層は、便利さのために複雑化している。便利にしたつもりが、攻撃面も広げる。皮肉ですが、よくある話です。
記事では、対策としていくつかのポイントが挙げられていました。要は、VMの中からホストに触れすぎないことです。
まず、unprivileged user namespaces を無効化すること。次に、seccomp フィルタを緩くしすぎないこと。さらに、モジュールの自動読み込みを止めること。そして何より、ホスト全体 / を VM に共有しないことです。
Accomplish AI は、接続されたフォルダだけを対象にし、少なくとも read-only にするべきだとしています。加えて coworkd を ProtectSystem=strict で動かし、独自の mount namespace に閉じ込める案も示しています。こうしておけば、たとえ guest-root を取られても、最後の一撃を打つ“着地点”がなくなる、というわけです。
この発想はかなり大事だと思います。セキュリティの世界では、完璧に防ぐのは難しい。だから「抜けられたとしても、着地できない」ように設計する。私はこの考え方のほうが、現実的で強いと感じます。
一番ぞっとしたのは、AIが賢いかどうかより、「どこまで権限を持たせるか」のほうがずっと重要だという事実です。AIエージェントは仕事を代わりにやってくれますが、そのぶんファイル、ネットワーク、認証情報に触れる機会が増える。つまり、便利さがそのまま危険物になりやすい。
しかも今回は、ユーザーが明示的に何か危険な操作をしたわけではなく、短いメッセージ一発で崩れたとされています。こういうのを見ると、AIエージェントの普及は「どう使うか」より「どう隔離するか」が先に問われる段階に入ったのではないか、と思います。
Anthropic 側は、最新バージョンでクラウド実行をデフォルトにしているため、この問題は回避されるとされています。とはいえ、ローカル実行を選ぶユーザーにはまだリスクが残る。便利さと安心のトレードオフが、かなり露骨に出た事例です。
参考: Claude Cowork Flaw Could Let AI Agent Escape Its VM and Access Mac Files
