Сразу четыре популярных AI-инструмента для разработки оказались уязвимы к схожему сценарию: исследователи показали выход из песочницы в Cursor, Codex, Gemini CLI и Antigravity без прямой атаки на сам sandbox. Для русскоязычных команд это неприятный, но полезный сигнал: проблема уже не в том, «есть ли песочница», а в том, что делает хост-машина с файлами, которые агент оставляет в проекте.
О находках сообщает BleepingComputer со ссылкой на исследование команды Pillar Security: Эйлона Коэна, Дана Лисичкина и Ариэля Фогеля. Они несколько месяцев воспроизводили обходы и выпустили серию разборов под названием Week of Sandbox Escapes. Механика у всех кейсов почти издевательски простая. Агент остается внутри ограниченной среды и формально не нарушает правил, но записывает в рабочую директорию файл, которому позже доверяет уже внешний инструмент: расширение IDE, Git-интеграция, движок хуков, VS Code tasks или локальный демон. Дальше код или команда исполняются уже за пределами sandbox, без красивой голливудской «взломали песочницу за 30 секунд» сцены.
Pillar разложила семь находок по четырем типовым классам. Первый — denylist-подход, когда защита пытается запрещать отдельные пути и имена файлов, но неизбежно отстает от реального поведения ОС и developer tooling. Второй — конфигурация рабочего пространства, которая на бумаге выглядит как «настройки проекта», а на практике оказывается исполняемым кодом или триггером для запуска команд. Третий — allowlist «безопасных» команд, где продукт доверяет названию вроде git show, но не проверяет аргументы и реальный эффект вызова. Четвертый — привилегированные локальные демоны вне песочницы, до которых агент дотягивается через доступные интерфейсы. Во всех сценариях входной точкой становится prompt injection: вредоносная инструкция в README, issue, зависимости или diff превращается в действие на машине разработчика.
По конкретным продуктам картина получилась показательной. В Cursor один из сценариев использовал управляемую рабочим пространством конфигурацию хуков .claude, что приводило к выполнению команды уже вне sandbox; уязвимость получила идентификатор CVE-2026-48124 и была исправлена в версии 3.0.0. Второй баг позволял агенту менять интерпретатор внутри virtualenv, после чего Python-расширение редактора само подхватывало и запускало его во время discovery. Третий трюк был завязан на том, что Git-метаданные не обязаны лежать именно в каталоге .git: исследователи использовали fsmonitor и обошли path-based ограничения Cursor. Этот кейс тоже закрыт в 3.0.0, но CVE для него на момент публикации еще ожидался. В Codex CLI проблема нашлась в allowlist для «безопасных» команд: продукт доверял имени git show, хотя конкретный вызов уже нельзя было считать read-only. OpenAI закрыла эту дыру в версии 0.95.0 и, по данным издания, выплатила вознаграждение за high-severity bug bounty; CVE там тоже еще ожидался. Отдельно фигурирует история с Docker socket, общая сразу для Codex, Cursor и Gemini CLI: агент мог использовать доступ к привилегированному локальному демону как удобную площадку для запуска кода вне своей клетки. Этот сценарий тоже уже исправлен.
Интереснее всего здесь даже не список брендов, а повторяемость паттерна. Это не единичный промах одной команды и не экзотика для bug bounty-отчета, который никто не сможет воспроизвести. Еще в апреле компания Cymulate описывала схожий класс проблем под названием Configuration-Based Sandbox Escape для Claude Code, Gemini CLI и Codex CLI: файл создается внутри песочницы, а исполняется уже хостом при следующем запуске или во время фоновой проверки. Новизна нынешней истории в масштабе: один и тот же тип ошибки проявился сразу в четырех инструментах от трех разных вендоров. Для рынка агентной разработки это неприятный маркер зрелости. Индустрия очень быстро научилась продавать sandbox как базовую гарантию безопасности, но гораздо хуже разобралась с тем, что происходит на стыке агента, IDE, локальных сервисов и привычных developer workflows.
Реакция вендоров при этом оказалась неравномерной. Большинство проблем признаны и закрыты, но Google в истории с двумя находками для Antigravity отнеслась к рискам прохладнее. Речь идет о bypass для macOS Seatbelt denylist и обходе Secure Mode через конфигурацию задач .vscode. По данным Pillar, обе находки Google классифицировала как «Other valid security vulnerabilities» и понизила приоритет, посчитав их сложными для эксплуатации, поскольку требуется социальная инженерия или доверие пользователя к репозиторию с косвенной prompt injection. Логика понятная: без участия человека такие цепочки действительно реже срабатывают. Но для практики AppSec это слабое утешение. Репозиторий с README, issue или конфигом, который разработчик открыл из рабочей рутины, и есть нормальная среда эксплуатации подобных багов, а не экзотическое условие из методички threat model.
Для разработчиков и руководителей это означает довольно приземленную вещь: выход из песочницы в AI-агентах надо искать не только в системных вызовах, сокетах и сетевых правах, но и в файлах проекта. Все, что агент может записать в workspace, потенциально становится управлением для внешних компонентов: тасков, хуков, интерпретаторов, Git-механизмов, контейнерных интеграций, расширений IDE. Если команда разрешает агенту править конфиги, манифесты, служебные каталоги и dotfiles, она фактически открывает вторую поверхность атаки, где срабатывают уже не правила sandbox, а доверие локальных инструментов. Для бизнеса это не абстрактный security theater, а риск компрометации developer endpoints, утечки исходников, токенов, секретов CI/CD и доступа к внутренней инфраструктуре. Вдвойне неприятно, что такие сценарии легко маскируются под «обычные изменения в репозитории», особенно если агент работает в длинной сессии и вносит десятки правок.
Главный вывод здесь неприятно простой: рынок AI-кодеров входит в стадию, где мерить безопасность наклейкой «sandboxed» уже бессмысленно. Следующая линия обороны — контроль того, какие именно файлы агент пишет, какие локальные инструменты потом их читают и где заканчивается доверие к workspace как к данным, а не как к коду. Именно на этой границе и будет решаться, останется ли выход из песочницы редким исследовательским трюком или превратится в стандартный прием атакующих. Подробности исходной публикации можно посмотреть в .