DeepSeek Harness CVE-2026-82533: Побег из песочницы с оценкой CVSS 9.4

Любой инженер, который запускал агента для ИИ-кодирования на ноутбуке с активными SSH-ключами, уже знает, что модель угроз крайне ненадёжна. CVE-2026-82533 делает её ещё тоньше. Изолированный агент внутри DeepSeek Harness может отключить собственное ограничение одной командой оболочки — при настройках по умолчанию, без сетевого доступа извне и без учётных данных. Оценка по CVSS 4.0 составляет 9.4.

Цифры

Начнём с оценки. 9.4 по CVSS 4.0 — это не «исправим в следующем спринте». Вектор CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:P/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H говорит сам за себя: уязвимость доступна по сети, низкая сложность эксплуатации, привилегии не требуются, высокое влияние на конфиденциальность, целостность и доступность, а также высокое влияние на последующую систему. Единственный смягчающий фактор — взаимодействие с пользователем, что в контексте агента означает «агент выполняет команду, которую попросил злоумышленник». Это и есть основная работа агента для кодирования.

Затем охват. DeepSeek Harness, или dsh, — это локальный инструмент для запуска ИИ-агентов кодирования. Выпущенный в августе 2026 года, он набрал более 215 000 звёзд на GitHub за несколько недель, что в описании уязвимости характеризуется как один из самых популярных инструментов разработчика года. Это не нишевой исследовательский проект. Это инструмент, установленный на десятках тысяч рабочих станций разработчиков и работающий с полномочиями того, кто его запустил.

Хронология раскрытия чёткая и сжатая. Как сообщил OX Security, исследователи Нир Задок и Моше Симан Тов Бустан подтвердили уязвимость путём выполнения кода и раскрыли её организации VulnCheck как CNA 24 августа 2026 года. Исправление появилось в DeepSeek Harness 0.1.2-alpha.1 27 августа. OX Research повторно протестировала 30 августа и подтвердила устранение уязвимости. CVE-2026-82533 был опубликован 8 сентября 2026 года. Три дня от раскрытия до патча для инструмента в альфа-версии — это быстро. Три дня — это также больше, чем нужно мотивированному злоумышленнику для создания оружия на основе публичного описания.

Классификация CWE — CWE-807 «Опора на ненадёжные входные данные при принятии решения в области безопасности» — весьма показательна. Это не новый класс уязвимостей. Это та же категория ошибок, которая переоткрывалась в веб-фреймворках на протяжении двух десятилетий. Новое здесь — масштаб последствий: ненадёжный ввод — это заголовок, а решение безопасности, которое он контролирует, — «может ли этот вызывающий отключить песочницу?»

Что действительно нового

Технический механизм стоит изучить внимательно, потому что он будет воспроизводиться в других инструментах. DeepSeek Harness предоставляет свой API управления агентами на 127.0.0.1:3080 без аутентификации. Единственная функция, isTrustedApiRequest, читает заголовок Host HTTP-запроса и разрешает доступ, если значение является петлевым адресом или присутствует в настроенном списке trustedHosts. При этом значение никогда не сравнивается с реальным адресом однорангового соединения.

Комментарий к этой функции ясно показывает, что она была разработана для защиты от DNS-rebinding. Против браузера это работает. Браузеры не могут подделывать заголовок Host. Против оболочки внутри песочницы это вообще не работает, потому что обычный HTTP-клиент может задать любое значение Host. Сама песочница — будь то bubblewrap в Linux, Landlock или Seatbelt в macOS — ограничивала запись файлов, но оставляла открытой петлевую сеть. В Linux аргументы bubblewrap передавали --unshare-pid, но не --unshare-net. В macOS профиль Seatbelt использовал (allow default) с наложенным сверху (deny file-write*). Песочница была ориентирована на файлы. API был доступен по сети изнутри песочницы. Эти два механизма никогда не пересекались.

Цепочка эксплуатации — один вызов оболочки. Обычные вызовы инструмента bash не требовали подтверждения. Агент обращается к своему локальному API, повышает сеанс до режима danger-full-access с отключёнными запросами подтверждения, и все последующие команды выполняются без ограничений и без запросов. Изменение политики записывалось в журнал сеанса как source: {kind: 'user'}, и после побега нигде не появлялось никаких событий подтверждения или запроса. Инструмент не мог отличить оболочку агента от действий человека за клавиатурой. Вот что действительно ново.

Моё мнение: настоящий сбой здесь — не проверка заголовка. Это архитектурное решение, при котором привилегированный API управления и изолированная оболочка разделяют одно сетевое пространство имён и взаимодействуют без какой-либо криптографической привязки. Производственные инциденты в сфере финтеха, которые я видел и которые похожи на этот, обычно связаны с доверием внутренних сервисных сетей заголовку X-Forwarded-For. Та же схема, другая обёртка.

Что уже учтено командами безопасности

Все, кто серьёзно занимался категориями OWASP последние пять лет, уже предполагали, что агенты для ИИ-кодирования — лёгкая мишень. Аргумент о расширенных полномочиях хорошо понятен: агент держит оболочку, читает и записывает исходные деревья, имеет доступ к SSH-ключам, облачным учётным данным, реестрам пакетов и внутренним системам с рабочей станции разработчика. Этот риск был учтён с того дня, когда команды начали использовать эти инструменты.

Что не было учтено честно — это то, что песочница, призванная ограничить эти полномочия, нередко оказывается театральной декорацией. Команды, с которыми я работал, принимают «работает в песочнице» как достаточный ответ при проверке безопасности. Эта CVE — чёткий контрпример. Песочница активно применяла ограничения записи файлов в момент побега. Proof of concept подтвердил это. Просто она не применяла то, что имело значение: «агент не может разговаривать с собственной управляющей плоскостью».

Второй вектор атаки — это то, от чего CISO должны испытывать тревогу. Если порт доступен через туннель, обратный прокси, SSH-перенаправление или перенаправление порта редактора, неаутентифицированный удалённый злоумышленник может полностью захватить управление агентом и отдельно экспортировать все сохранённые переписки без API-ключа или вызова модели. Каждый разработчик, когда-либо запускавший ssh -L для публикации локального сервиса коллеге, теперь является частью модели угроз. То же касается каждого редактора с расширением для перенаправления портов. Это не было учтено.

Альтернативный взгляд

Стандартная интерпретация этой CVE будет такой: «ИИ-агенты опасны, нужно больше изоляции». Я считаю, что это неправильный вывод. Больше слоёв песочницы поверх сломанной границы доверия лишь сдвигает ворота. Неудобный вывод: настоящая проблема в том, что инструменты для агентов проектируются с той же беспечной предпосылкой «localhost безопасен», которая породила десятилетие ошибок CSRF и DNS-rebinding, а индустрия торопится выпускать эти инструменты, прежде чем эта предпосылка будет проверена.

Есть и контраргумент к трактовке серьёзности. UI:P в векторе означает, что требуется взаимодействие с пользователем. На практике «агент выполняет текст, контролируемый злоумышленником» — это режим работы по умолчанию для агента кодирования, работающего с реальным репозиторием и реальными зависимостями. Таким образом, UI:P не выполняет здесь никакой защитной функции. Более того, оценка 9.4 скорее преуменьшает операционный риск для команд, запускающих этих агентов против пул-реквестов от внешних участников или против деревьев зависимостей из публичных реестров. Как только будет зафиксирована эксплуатация в реальной среде, эту уязвимость, вероятно, следует отслеживать в каталоге CISA KEV.

Ключевые выводы

• Немедленно обновите DeepSeek Harness до версии 0.1.2-alpha.1 или более поздней. Любая версия, выпущенная до 27 августа 2026 года, уязвима при настройках по умолчанию.
• Проверьте любой локальный API управления агентами на наличие верификации адреса однорангового узла. Никогда не доверяйте заголовку Host как сигналу аутентификации. Привяжите привилегированные конечные точки к Unix-сокету с правами файловой системы или требуйте токен для каждого сеанса, который изолированная оболочка не может прочитать.
• Считайте петлевую сеть доступной изнутри вашей песочницы, если только вы явно не изолируете сетевое пространство имён. Проверьте флаги bubblewrap на наличие --unshare-net. Проверьте профиль Seatbelt на наличие сетевых правил, а не только запретов file-write*.
• Исходите из того, что любой инструмент разработчика, прослушивающий localhost, находится в одном шаге ssh -L от удалённого доступа. Ведите инвентаризацию перенаправлений портов и расширений редакторов на машинах разработчиков так же, как вы ведёте инвентаризацию VPN-туннелей.
• Записывайте изменения политики с указанием реального инициатора, а не source: {kind: 'user'}. Если ваш журнал сеанса не может отличить оболочку агента от клавиатуры человека, ваш аудиторский след — это выдумка.

Исправление было выпущено за три дня. Шаблон проектирования, породивший эту ошибку, встречается в каждом новом инструменте для агентов в этом квартале. Установите патч для CVE. Затем прочитайте код границы доверия вашего собственного инструмента, пока это не сделал кто-то другой.