Исследователи нашли два способа выполнить побег из песочницы Codex, причем один из них позволял запускать команды на машине разработчика даже в самом жестком режиме read-only. OpenAI получила отчет 12 августа и закрыла обе уязвимости за восемь дней, сообщает BleepingComputer. Для команд, которые уже пускают AI-агентов в реальные репозитории, это неприятное напоминание: «просто спросить бота про чужой код» уже не выглядит безобидной операцией.
Речь идет об OpenAI Codex — coding agent, который работает как CLI-инструмент и desktop-приложение. Его модель должна выполнять действия внутри песочницы: читать код, запускать разрешенные операции и не трогать остальную систему без явного допуска. Исследователь Oren Yomtov из Accomplish AI описал два обхода этой границы. Первый получил название Heapjack, второй — Overpatch. Оба уже исправлены: Heapjack закрыт в Codex Desktop build 26.818.21641, Overpatch — в Codex CLI 0.149.0.
Heapjack выглядит особенно нервно для разработчиков, которые открывают в агенте сторонние проекты. Сценарий атаки такой: пользователь открывает чужой репозиторий в Codex и задает вопрос по коду. Вредоносный код из этого репозитория получает возможность добиться несандбоксированного выполнения команд на машине пользователя — без окна подтверждения и без видимого вывода на экран. Это не «бот случайно написал не туда файл», а полноценный обход доверенной границы.
Проблема сидела в компоненте node_repl. Codex Desktop при установке добавлял его в глобальный файл конфигурации ~/.codex/config.toml. По описанию исследователя, отдельного opt-in для этого механизма не было, а пользователи Codex CLI наследовали настройку через общий конфиг. node_repl запускал один процесс Node.js с двумя JavaScript-контекстами: доверенным, где работал код OpenAI, и недоверенным, где выполнялся код агента. Доверенный контекст подтверждал свои права случайным токеном, который создавался при каждом запуске.
Слабое место оказалось почти учебниковым: два контекста были разделены на уровне глобальных объектов, но жили в одном процессе и в одной heap-памяти. Недоверенный код мог снять heap snapshot через v8.getHeapSnapshot(), перебрать строки, похожие на UUID, и по ответам отличить неверный токен от верного. После этого атакующий мог отправить собственный запрос по тому же каналу, которым доверенный контекст общался с нативным родительским процессом вне песочницы. Родитель видел валидный токен и выполнял команду.
В proof of concept исследователи использовали системную команду open, чтобы запустить приложение уже вне дерева процессов Codex. В описании также упоминаются доступ к Unix-сокетам, включая очевидно опасный Docker daemon socket, и инструмент редактирования глобального конфига. Критичная деталь: все это работало в режиме read-only, где агент по идее не должен иметь права ничего записывать.
Вторая уязвимость, Overpatch, была проще по форме, но не менее показательной. Она находилась в open-source Codex CLI и касалась режима workspace-write. В этом режиме агенту разрешено писать только внутри папки проекта; попытка shell-команды изменить домашний каталог должна блокироваться. Исследователи обошли запрет через собственный инструмент Codex для патчей — apply_patch.
Ошибка была в том, как apply_patch выдавал права на запись. Инструмент расширял доступ до родительской папки каждого пути, указанного в патче. Если в патче упоминался /tmp, механизм фактически расширял разрешение до корня диска. Рабочая схема использовала два изменения: первое называло /tmp и служило только для расширения прав, второе через symlink добавляло строку в .zshrc в домашнем каталоге. Без первого изменения запись блокировалась. С ним следующая открытая разработчиком shell-сессия запускала строку атакующего уже без песочницы.
Общий корень у обеих историй один: механизм защиты доверял данным или памяти, которые мог контролировать атакующий. В Heapjack секретный токен лежал там же, где его мог прочитать недоверенный код. В Overpatch инструмент сам вычислял свои разрешения из путей, пришедших из потенциально вредоносного патча. Это ровно тот класс ошибок, который становится болезненнее с ростом автономности coding agents: модель может оставаться «внутри правил», но дергать доверенные инструменты так, что правила начинают работать против владельца машины.
Контекст тоже важен. В июле 2026 года исследователи Pillar Security уже показывали похожую проблему на Cursor, Codex, Gemini CLI и Google Antigravity: агент не обязан напрямую ломать песочницу, если может записать файл, который потом выполнит доверенный компонент снаружи. В обсуждении работы Yomtov пользователи отдельно зацепились за архитектуру с общим heap: изоляция V8-контекстов не равна изоляции памяти. Звучит сухо, но для инженера смысл простой: «контекст» — это не сейф, если секрет лежит в той же комнате.
Практический вывод короткий: обновить Codex Desktop до build 26.818.21641 или новее, Codex CLI — до 0.149.0 или новее, а до обновления не открывать непроверенные репозитории в агенте. Для компаний стоит добавить AI coding agents в обычную модель threat modeling: какие глобальные конфиги они меняют, какие сокеты видят, какие инструменты запускают вне песочницы, что происходит с symlink и patch workflow. Побег из песочницы Codex закрыт, но рынок только начинает привыкать к новой норме: AI-агент — это не «умный автокомплит», а процесс с правами, инструментами и очень реальной поверхностью атаки.