Около 500 тысяч пользователей macOS до исправления были затронуты уязвимостью Claude Cowork: локальный ИИ-агент мог вырваться из Linux-виртуалки и читать или менять файлы по всему Mac. Для русскоязычной IT-аудитории это важный сигнал: если агенту дают «песочницу», это еще не значит, что у него нет короткой дороги к SSH-ключам, облачным токенам и внутренним репозиториям.
Об этом сообщает The Hacker News со ссылкой на исследователей из Accomplish AI. Они описали цепочку атаки под названием SharedRoot: достаточно подключить папку к новой локальной сессии Claude Cowork и отправить агенту одно короткое сообщение, после чего тот при удачном сценарии выходит за пределы своей VM. По словам исследователя Оrena Yomtov, изнутри виртуальной машины агент мог добраться до хостовой macOS и читать или записывать файлы далеко за пределами той директории, которую пользователь явно расшарил в сессию.
Ключевая проблема оказалась не в какой-то одной «магической» ошибке, а в сочетании архитектурных решений. Десктопное приложение Claude Cowork на macOS работает от имени текущего пользователя, а сама агентная нагрузка уходит в Linux VM, созданную через Apple Virtualization framework. Для каждой сессии поднимается отдельный непривилегированный пользователь и применяется seccomp-фильтр. На бумаге звучит прилично. Но папки, которые пользователь подключает к агенту, внутрь виртуальной машины экспортирует root-демон coworkd. И, как выяснили исследователи, в VM в режиме чтения и записи монтировалась не только нужная папка, а весь хостовый файловый корень.
Это и сделало уязвимость Claude Cowork по-настоящему неприятной. Если внутри гостевой Linux получить guest-root, дальше агент видит весь хостовый / и может работать с файлами от лица залогиненного пользователя macOS. То есть речь не о красивом академическом побеге из песочницы, а о вполне практичном доступе к SSH-ключам, облачным credential'ам, локальным базам, заметкам, рабочим документам и всему, что обычно лежит на ноутбуке разработчика, продакта или фаундера. В 2026 году это уже не «личные файлы на десктопе», а, как правило, половина операционного контура компании.
Как сработала цепочка
Для повышения привилегий исследователи использовали недавно раскрытую уязвимость CVE-2026-46331, известную как pedit COW. Сценарий упирался в подсистему Linux kernel traffic control, точнее в модуль act_pedit. По словам сооснователя и CTO Accomplish AI Or Hiltch, сессия внутри Cowork получает user и network namespaces, а вместе с ними — возможность работать с CAP_NET_ADMIN внутри собственного сетевого namespace. Формально это не сам эксплойт, а условие, которое открывает непривилегированному пользователю доступ к чувствительному пути в ядре. Дальше цепочка уже доводит дело до guest-root, после чего песочница заканчивается, а начинается хостовая файловая система.
В этой истории особенно показательно, что Anthropic после responsible disclosure не выпустила отдельный патч к механике локального запуска, а закрыла отчет как informative. При этом свежая версия Cowork по умолчанию использует облачное исполнение, что снимает проблему для стандартного сценария. Но для пользователей, которые сознательно выбирают локальный режим, риск, по сути, остается. С инженерной точки зрения это довольно жесткий месседж: безопаснее не потому, что локальная архитектура стала надежной, а потому, что опасный путь больше не является дефолтным.
Для рынка AI-агентов это плохая, но полезная новость. Плохая — потому что очередной раз выяснилось: если агенту дать богатую локальную среду, namespace'ы, доступ к файловой системе и еще оставить возможность опираться на уязвимости ядра, то «ограждение» работает ровно до следующего kernel bug. Полезная — потому что этот кейс наконец-то переводит разговор из маркетингового режима в инженерный. Неважно, как аккуратно выглядит продуктовый интерфейс и сколько там написано про sandboxing. Если в VM проброшен весь host root с правом записи, то безопасность держится на допущении, что внутри гостя никто никогда не станет root. Для Linux это допущение, мягко говоря, смелое.
Что это значит для команд
Практический вывод для разработчиков и IT-руководителей довольно прямой. Если в компании тестируют локальных AI-агентов на macOS, нужно смотреть не только на prompt-инъекции и утечки через плагины, но и на низкоуровневую изоляцию. Вопросы должны быть скучными и очень конкретными: что именно шарится в VM, в каком режиме смонтирован хост, отключены ли unprivileged user namespaces, насколько широк seccomp-профиль, разрешена ли автозагрузка модулей, какие привилегии агент получает в network namespace. Если ответов нет или они звучат как «у нас там отдельная виртуалка, все нормально», это не ответ, а приглашение для аудита.
Accomplish AI предлагает вполне приземленные меры: отключать unprivileged user namespaces, не делать seccomp слишком мягким, запрещать autoload модулей и, главное, не монтировать в гостя весь хостовый /. Вместо этого нужно шарить только реально подключенные пользователем папки, а еще лучше — монтировать их в read-only там, где это возможно. Отдельно исследователи указывают на запуск coworkd с ProtectSystem=strict в собственном mount namespace, чтобы сессионный пользователь не мог подменять бинарники, которые потом переиспользует системный демон. Это уже не общие пожелания про «усилить безопасность», а список конкретных инженерных решений, которых ждешь от продукта такого класса из коробки.
История с SharedRoot бьет по самому удобному тезису рынка AI-ассистентов: будто локальный запуск автоматически безопаснее облака. На практике локальность убирает одни риски, но создает другие — особенно если агенту дают широкий доступ к машине и пытаются закрыть вопрос одной виртуалкой поверх пользовательской сессии. Чем активнее AI-агенты будут заходить в IDE, терминалы и рабочие ноутбуки, тем меньше у индустрии остается права на декоративный sandboxing и тем выше цена любой архитектуры, в которой весь хост уже лежит внутри VM, только «надеемся, что не дотянутся».