В DeepSeek Harness нашли уязвимость с оценкой 9,4 из 10: AI-агент мог одной командой отключить собственную файловую песочницу и продолжить работать без запросов на подтверждение. Для разработчиков и компаний, которые запускают кодовых агентов на рабочих машинах, это неприятное напоминание: «sandbox» в README не равен изоляции уровня production.
О проблеме сообщает The Hacker News. Уязвимость получила идентификатор CVE-2026-82533, запись опубликовала VulnCheck 8 сентября 2026 года. Ошибку обнаружила OX Research: по данным исследователей, агенту было достаточно обратиться к локальному веб-интерфейсу DeepSeek Harness и перевести текущую сессию в режим danger-full-access. После этого команды выполнялись уже без файловых ограничений и без нового approval prompt.
DeepSeek Harness — open-source-инструмент DeepSeek для запуска AI coding agents на машине разработчика. Его задача звучит разумно: агент получает shell, но его команды идут через операционную песочницу, чтобы работа с недоверенным репозиторием не превращалась в запись файлов куда попало. Проблема оказалась в управляющем контуре самого инструмента. Агент, уже запущенный внутри sandbox, мог достучаться до локального интерфейса harness, который менял настройки сессии.
Механика бага особенно неприятна своей простотой. В affected-релизах обычные команды не требовали подтверждения, а approval срабатывал только когда команда напрямую просила более широкие права, чем уже есть у сессии. Вызов локального интерфейса формально не «просил» расширенный доступ — он менял режим самой сессии. OX Research проверила это на двух сессиях с одинаковыми настройками: та, где агент сделал вызов к интерфейсу, смогла записать файл вне workspace; вторая была заблокирована песочницей.
Отдельный слой риска — сама модель изоляции. В документации affected-версии указано, что по умолчанию ограничиваются записи в файловую систему: они должны оставаться в workspace и временных папках. А вот чтение файлов и сетевой доступ не изолированы. Это значит, что локальный веб-интерфейс оставался доступен изнутри sandbox, а shell агента дополнительно получал адрес этого интерфейса и идентификатор текущей сессии. Агенту не надо было сканировать localhost или угадывать параметры — всё лежало рядом.
У интерфейса не было нормальной аутентификации. В affected-релизе проверка доступа опиралась на HTTP-заголовок Host и не проверяла реальный источник соединения. В коде, по данным отчёта, прямо было указано, что эта проверка не является auth layer. Для локального сценария этого уже хватало, а при пробросе порта через tunnel, SSH forward, прокси или редактор риск становился шире: внешний клиент мог выдать себя за локальный и управлять сессией. Через тот же интерфейс можно было скачать полный лог сессии, включая сохранённые диалоги.
Затронуты версии 0.1.1-rc.2 и более ранние. Исправление появилось в GitHub 27 августа в 0.1.2-alpha.1, но этот релиз не был опубликован в npm, хотя инструкции проекта ведут именно туда. Первый исправленный npm-релиз — 0.1.2-alpha.2 от 30 августа. Текущая на момент проверки The Hacker News версия в npm — 0.1.2-rc.1, опубликованная 3 сентября, с тем же исправлением. Практический вывод короткий: ставить 0.1.2-alpha.2 или новее, а лучше текущий rc, если вы уже используете DeepSeek Harness.
Фикс добавил проверку личности для веб-интерфейса. Теперь инструмент печатает одноразовый токен в стартовом адресе; браузер обменивает его на подписанную cookie, и дальнейшие вызовы к интерфейсу требуют эту cookie. Это закрывает очевидный unauthenticated control plane. Но само устройство sandbox не поменялось: в 0.1.2-rc.1 документация всё ещё говорит, что чтение и сеть не ограничены, а адрес интерфейса по-прежнему передаётся в окружение shell. Это не автоматическая катастрофа, но хороший повод не путать исправленный web auth с полноценной изоляцией агента.
Пользователям wrapper-приложений стоит проверить не только собственную версию, но и то, какую копию harness везёт десктопная оболочка. По данным источника, один Windows-билд в конце августа был закреплён на 0.1.1-rc.2 и перешёл на 0.1.3-alpha.1, где исправление уже есть, только 6 сентября. Если обновиться нельзя, остаётся приземлённая гигиена: не держать веб-интерфейс поднятым без нужды, убрать туннели и port forward до него, не запускать агента на недоверенных репозиториях под основной пользовательской учёткой.
Эта история бьёт не только по DeepSeek Harness. Кодовые агенты стали удобной прослойкой между репозиторием, shell и рабочей машиной разработчика, а значит — привлекательной целью. Сам проект предупреждает, что sandbox и approval prompts не гарантируют изоляцию и не предотвращают ущерб; формулировка честная, но её легко пропустить между npm install и первым запуском. У репозитория было более 216 тыс. звёзд на GitHub 9 сентября, и даже если звёзды не равны установкам, масштаб интереса понятен.
Самый тревожный сигнал — ранние публичные сообщения. Два разработчика описали похожий escape на discussion board DeepSeek ещё 13 и 14 августа: один показал переход в danger-full-access из sandbox, другой перечислил запросы к интерфейсу без credentials и указал на отсутствие security policy. По данным The Hacker News, к 9 сентября в репозитории всё ещё не было security advisory, а релиз с фиксом описывал изменение как обычную правку транспорта и добавление one-time-token authentication. Для экосистемы AI-агентов следующий спор будет не о том, нужен ли sandbox, а о том, кто и как доказывает, что агент действительно не может переписать правила своей клетки изнутри.