В инструменте с открытым исходным кодом DeepSeek Harness, предназначенном для запуска AI-агентов на машине разработчика, была обнаружена критическая уязвимость. Она позволяла изолированному агенту отключить собственную изоляцию одной командой.

Инструмент работает в изолированной среде операционной системы, поэтому агент, работающий с недоверенными файлами, не может писать за пределы своей рабочей области. Агент мог обойти это ограничение, обратившись к веб-интерфейсу инструмента на той же машине, после чего его команды выполнялись вне песочницы без запроса на одобрение.

Уязвимость работала на установке по умолчанию до того, как DeepSeek исправил инструмент 27 августа. Для её эксплуатации требовался текст, подконтрольный злоумышленнику, который агент читал, чтобы инициировать вызов.

Уязвимость зарегистрирована как CVE-2026-82533. VulnCheck, который присвоил идентификатор, опубликовал запись 8 сентября и оценил уязвимость в 9,4 из 10.

Исследовательская компания OX Research, которая сообщила об уязвимости, указала, что достаточно одной shell-команды. Команда обращалась к локальному интерфейсу инструмента и переводила сеанс агента в режим danger-full-access, который отключает изоляцию и блокирует запросы на одобрение.

Обычные команды первоначально не требовали одобрения. Одобрение применялось только при запросе доступа шире, чем уже имел сеанс. Эта команда не запрашивала права, а просто изменяла настройку сеанса.

OX Research подтвердила, что изоляция работала до срыва защиты. Команда была запущена в двух сеансах с одинаковыми настройками по умолчанию. Сеанс, который сделал вызов, смог записать данные в папку вне своей рабочей области, а второй был заблокирован.

Изоляция касается только файлов. В справочнике команд для уязвимой версии указано, что при параметре по умолчанию запись остаётся внутри рабочей области и временных папок, в то время как чтение и сетевой доступ не ограничены.

Это позволило веб-интерфейсу инструмента оставаться доступным из песочницы. Инструмент также предоставляет агенту адрес этого интерфейса и идентификатор текущего сеанса, поэтому агенту не нужно их искать.

Интерфейс не имел аутентификации. В уязвимой версии проверка, определяющая доступность запроса, читала заголовок Host и никогда не проверяла источник соединения. Комментарий в коде указывает, что эта проверка не является уровнем аутентификации.

Именно эта проверка описана в записи CVE. Поскольку она доверяла заголовку, предоставленному клиентом, удалённая машина могла выдать себя за локальную и управлять агентом. Командная строка инструмента отказывалась слушать все сетевые интерфейсы, поэтому доступ извне требовал перенаправления портов через туннель, SSH-подключение или редактор.

Тот же интерфейс обслуживал запрос на загрузку полного логa сеанса. Согласно консультации VulnCheck, вызывающий, который получает доступ к интерфейсу, мог получить все сохранённые диалоги без ключа.

Затронутые версии и что установить

Уязвимы версии 0.1.1-rc.2 и более ранние. Запись называет 0.1.2-alpha.1 как исправленную версию, однако эта версия так и не была опубликована в реестр npm, куда отправляют пользователей собственные инструкции проекта.

Версия Статус Выпущена
0.1.1-rc.2 и ранее Уязвима 0.1.1-rc.2 выпущена 21 августа
0.1.2-alpha.1 Исправлена, только на GitHub 27 августа, не в npm
0.1.2-alpha.2 Первый исправленный выпуск в npm 30 августа
0.1.2-rc.1 Текущий выпуск npm с исправлением 3 сентября

Проверка реестра npm 9 сентября показала, что первый опубликованный выпуск с изменениями аутентификации — это 0.1.2-alpha.2, выпущенный через три дня после публикации исправления на GitHub.

Рекомендации по обновлению

  1. Установите версию 0.1.2-alpha.2 или позже. Текущий выпуск в реестре — 0.1.2-rc.1.
  2. Если вы установили инструмент через стороннее приложение, проверьте версию используемого harness.
  3. Если вы не можете обновиться, остановите веб-интерфейс, когда не используете его, и удалите любые туннели, прокси или перенаправления портов к нему.

Ни один из изученных источников не предлагает способ предотвратить срыв защиты внутри песочницы при установке по умолчанию во время работы инструмента. В отчёте от 13 августа указано, что ограничение адреса прослушивания не помогает, поскольку агент уже находится на той же машине.

Исправление добавляет проверку идентичности к интерфейсу. Инструмент теперь выводит одноразовый токен при запуске; браузер обменивает этот токен на подписанный cookie, и каждый вызов интерфейса требует этот cookie.

Исправление не меняет саму изоляцию. В версии 0.1.2-rc.1 справочник по-прежнему указывает, что чтение и сетевой доступ не ограничены, а оболочка агента по-прежнему получает адрес интерфейса. Нет информации о том, может ли агент, работающий внутри своей рабочей области, получить действительный сеанс в новой схеме.

Сторонние приложения поставляют собственную копию harness, и версия — это выбор разработчика обёртки. Одна сборка для Windows закрепила версию 0.1.1-rc.2 в конце августа и перешла на 0.1.3-alpha.1 с исправлением 6 сентября. Те, кто установил harness через обёртку, должны проверить её версию.

Harness для AI-агентов — привлекательная цель атаки, так как он предоставляет доступ к shell. DeepSeek Harness выполняет команды агента под учётной записью, которая его запустила.

В собственной инструкции по безопасности проекта указано, что программное обеспечение не прошло аудит безопасности, а изоляция и запросы на одобрение не гарантируют изоляцию и не предотвращают повреждение. Проект рекомендует пользователям не полагаться на инструмент как на единственный элемент управления безопасностью при работе с недоверенным кодом.

Репозиторий имел более 216 000 звёзд 9 сентября — это количество учётных записей, которые добавили его в закладки, а не количество установок.

Исследователи неоднократно находили срывы изоляции AI-агентов в этом году, включая набор уязвимостей, при которых конфигурация самого репозитория заставляла агентов выполнять код злоумышленника за пределами их изоляции.

Сообщество описало этот же срыв в августе

Два разработчика описали ту же уязвимость на форуме обсуждений DeepSeek до появления записи CVE. 13 августа один опубликовал отчёт, показывающий процесс, всё ещё удерживаемый изоляцией, обращающийся к локальному интерфейсу и переводящий сеанс в режим danger-full-access, с результатами тестов.

14 августа другой опубликовал отчёт на том же интерфейсе, перечислив запросы, которые он принимал без каких-либо учётных данных.

Этот второй отчёт также отметил, что в проекте нет файла политики безопасности и нет приватного способа сообщить об уязвимости. Проект по-прежнему не имеет файла политики безопасности.

OX Research сообщила об уязвимости в VulnCheck 24 августа, по её временной шкале, и VulnCheck отдаёт должное Нир Задоку и Моше Симан Тову Бустану. Публикация OX не упоминает более ранние отчёты.

Проверка списка рекомендаций репозитория 9 сентября показала, что никакого уведомления о безопасности не опубликовано. Выпуск с исправлением перечисляет его среди стандартных изменений как удаление старого транспорта и требование аутентификации на основе одноразовых токенов для сетевого доступа, без уведомления о безопасности и без упоминания CVE.