DeepSeek Harness CVE-2026-82533: агент в песочнице отключает собственную песочницу одной командой

VulnCheck опубликовала CVE-2026-82533 8 сентября 2026 года: критический обход аутентификации, позволявший AI-агенту для программирования отключить собственную песочницу одной shell-командой. Это программное обеспечение — DeepSeek Harness, открытая локальная среда выполнения DeepSeek для агентов-программистов, которая, по данным Cloud Security Alliance, набрала около 215 000 звёзд на GitHub за несколько недель; уязвимы все версии до 0.1.2-alpha.1. Она определяла, является ли вызывающая сторона локальной, по заголовку Host самой вызывающей стороны, поэтому запрос мог выдать себя за loopback. Поскольку её песочница ограничивала запись файлов, но не loopback-сеть, изолированный агент мог вызвать неаутентифицированный управляющий API harness на порту 3080 и переключить свою сессию в режим danger-full-access с отключёнными подтверждениями. VulnCheck оценивает её в 9,4 балла как критическую; эксплуатация в реальных условиях не заявлена. Эта запись — одна из публичного набора данных об инцидентах с ИИ, а the Orca AI Incident Archive содержит полный набор записей с датами, оценками серьёзности и источниками для каждой записи.

Проверка, которая спросила у запроса, чем он был

Уязвимым компонентом является локальный API управления агентом в составе harness — небольшой HTTP-сервис, который веб-интерфейс и командная строка используют для управления запущенной сессией. Согласно аналитической заметке Cloud Security Alliance от 10 сентября 2026 года, основанной на отчёте OX Security — компании, обнаружившей уязвимость, — этот сервис по умолчанию прослушивал порт 3080 на 127.0.0.1 и принимал решение о доверии в функции, которую заметка называет isTrustedApiRequest. Функция читала HTTP-заголовок Host и предоставляла доступ, когда значение совпадало с именем loopback-интерфейса, таким как localhost или 127.0.0.1. Заголовок Host — это метаданные, которые записывает клиент; он ничего не говорит о том, откуда пришло TCP-соединение. The Hacker News, ссылаясь 9 сентября 2026 года на затронутый исходный код, сообщает, что проверка никогда не смотрела на источник соединения и что комментарий в том же файле гласит, что проверка «не является слоем аутентификации».

Это и есть вся суть CWE-807 — доверие к недоверенным входным данным при принятии решения о безопасности, — и именно это описывается в опубликованной записи VulnCheck: предоставляемый клиентом заголовок Host с loopback-адресом принимается вместо проверки фактического источника TCP-соединения.

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

Почему запросы на подтверждение не остановили это

В харнессе действительно были запросы на подтверждение, и их не столько обходили, сколько они были неприменимы. Hacker News сообщает, что в затронутом выпуске подтверждение запрашивалось только тогда, когда команда пыталась получить более широкий доступ, чем уже был у сеанса. Вызов эскалации не запрашивал ничего подобного; он менял настройку сеанса. Агент, выполнивший его, перешёл в режим, который OX Security называет danger-full-access, с запросами на подтверждение, установленными на «никогда», и продолжал работать от имени пользователя, запустившего харнесс, полностью вне песочницы.

Доказательством существования границы для OX Security стала контролируемая пара. Издание The Hacker News сообщает, что компания запустила два сеанса с идентичными настройками по умолчанию и дала обоим одну и ту же команду: сеанс, совершивший вызов, записал в папку за пределами своего рабочего пространства, а другой был заблокирован.

Второй путь и необходимая для него предпосылка

Та же отсутствующая проверка делала харнесс доступным для вызывающих сторон, которые вообще никогда не находились внутри песочницы, но лишь при условии, которое конфигурация по умолчанию не создавала. Командная строка отказывалась привязывать API ко всем сетевым интерфейсам, поэтому порт был доступен извне только в том случае, если пользователь уже перенаправил его — через туннель, обратный прокси, SSH-перенаправление или собственную функцию перенаправления портов редактора, по данным The Hacker News; в заметке Cloud Security Alliance перечислен тот же набор. Как указано в уведомлении VulnCheck, там, где это предварительное условие выполнялось, вызывающая сторона без учетных данных могла создавать сеансы, выполнять произвольные команды и похищать сохраненные стенограммы разговоров. The Hacker News добавляет, что тот же интерфейс обслуживал запрос, который скачивает весь журнал сеанса.

Для маршрута через песочницу требуется другое предварительное условие: текст, который агент прочитает и на основании которого будет действовать. В заметке Cloud Security Alliance описывается изолированный агент, обрабатывающий предоставленный злоумышленником промпт, внедрённый в комментарий к коду, файл README или текст issue. Ни один из маршрутов не требует украденного ключа, и в заметке отмечается, что удалённому маршруту вообще не нужно взаимодействовать с моделью, как только порт будет открыт.

Таким образом, подверженная риску группа — это все, кто запускал harness в версии 0.1.1-rc.2 или более ранней с настройками по умолчанию; количество звёзд лишь приблизительно указывает на этот набор. The Hacker News насчитало более 216 000 звёзд 9 сентября 2026 года и предупредило, что звезда — это закладка, а не установка.

Что установлено, а что — нет

Установлено из самой записи CVE: VulnCheck является органом нумерации, он зарезервировал идентификатор 29 августа 2026 года и опубликовал запись 8 сентября в 16:59 UTC; слабость — CWE-807; затронутый диапазон — все версии до 0.1.2-alpha.1; а заслуга принадлежит Ниру Задоку и Моше Симану Тову Бустану. Две оценки, которые содержит запись, — 9,4 по CVSS 4.0 и 9,6 по CVSS 3.1 — исходят от VulnCheck, а не от второго независимого оценщика; NVD указывает обе метрики с VulnCheck в качестве источника, поэтому это одна оценка, выраженная в двух рамках, а не две согласующиеся оценки.

Установлено по репозиторию: коммит с исправлением 3e24087 под названием «fix(web): authenticate the browser Host API» датирован 24 августа 2026 года и, согласно GitHub API, добавляет модуль браузерной аутентификации вместе с 210 строками сквозных тестов для нового потока. Релиз с тегом dsh-v0.1.2-alpha.1 последовал 27 августа в 17:06 UTC.

Не установлено: использование. Ни запись CVE, ни консультация VulnCheck, ни примечания к выпуску DeepSeek не описывают эксплуатацию в реальных условиях, а NVD указывает зрелость эксплойта как не определённую. Модель EPSS организации FIRST присвоила уязвимости вероятность эксплуатации 1,24% в течение следующих 30 дней на уровне 68,9-го процентиля в ленте от 27 октября 2026 года. В архиве не зафиксировано реального ущерба для этой записи; ей присвоен уровень уверенности A — хорошо задокументировано, а первичные источники согласуются.

Даты, включая два отчёта, которые поступили первыми

Два разработчика пришли к одному и тому же выводу ещё до того, как появился CVE, на который можно было бы указать. The Hacker News сообщает о публикации на собственной дискуссионной доске проекта от 13 августа 2026 года, где показано, что процесс, всё ещё ограниченный песочницей, достиг локального интерфейса и переключил сессию в danger-full-access, с выводом тестов, а также о второй публикации от 14 августа со списком запросов, которые этот интерфейс принял без учётных данных. Во второй публикации также отмечалось, что в проекте не было файла политики безопасности и закрытого канала для сообщения об уязвимости; The Hacker News проверила 9 сентября и обнаружила, что файл политики безопасности по-прежнему отсутствует.

Хронология OX Security относит её отчёт в VulnCheck к 24 августа 2026 года — та же дата, которую GitHub указывает для коммита с исправлением. В сообщении коммита об отчёте не говорится ничего, а публичное изложение OX Security, в том виде, как его описывает The Hacker News, не упоминает более ранние публикации в сообществе. Были ли эти два события 24 августа связаны между собой, публичные источники не утверждают, и данная статья этого не предполагает.

Разрыв между исправлением и раскрытием информации — не редкость. В заметке Cloud Security Alliance отмечается, что OX Security подтвердила исправление 30 августа, за девять дней до того, как VulnCheck опубликовала CVE.

Где исправление было применено, а где — нет

Тег в GitHub и реестр пакетов обновлялись не синхронно, и именно это стоит знать, если вы установили харнесс так, как предлагают его инструкции. Пакет командной строки @deepseek-ai/dsh вышел в версии 0.1.1-rc.2 21 августа 2026 года, а затем — ничего до 0.1.2-alpha.2 30 августа. Версия 0.1.2-alpha.1, которую CVE указывает как исправление, полностью отсутствует в реестре, поэтому первый исправленный релиз, доступный для установки, появился на три дня позже исправления. Для этой статьи метаданные реестра npm были получены 28 октября 2026 года; The Hacker News сообщил о том же расхождении 9 сентября.

В примечаниях к выпуску это не было представлено как выпуск с исправлениями безопасности. Среди рутинных изменений указано, что веб-интерфейс теперь требует аутентификации с помощью одноразового токена для сетевого доступа, без ссылки на CVE и без уведомления о безопасности, и The Hacker News не обнаружила 9 сентября в списке уведомлений о безопасности репозитория никакого уведомления. Механизм, как его описывает Cloud Security Alliance, таков: harness выводит одноразовый токен при запуске, браузер обменивает этот токен на подписанный cookie, и каждый последующий вызов должен предъявлять этот cookie — доверие привязано к секрету, выданному при старте процесса, а не к заявленному сетевому источнику.

Сторонние сборки — это слабое звено. Настольные обёртки поставляются с собственной копией харнесса, поэтому то, какая версия будет у пользователя, зависит от выбора сопровождающего обёртку; The Hacker News обнаружил одну сборку для Windows, закреплённую на 0.1.1-rc.2 в конце августа, которая 6 сентября перешла на 0.1.3-alpha.1, содержащую исправление.

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

Что рекомендуют источники записи

• Любую установку версии 0.1.1-rc.2 или более ранней следует считать затронутой независимо от способа упаковки, включая копию, встроенную в десктопную обёртку.

• Установите версию 0.1.2-alpha.2 или более позднюю из npm; самой новой версией в реестре на 27 октября 2026 года была 0.2.2-alpha.2.

• Если вы не можете выполнить обновление, останавливайте веб-интерфейс, когда он не используется, и удалите любые туннели, прокси или пробросы портов, ведущие к порту 3080.

• Проверьте, доступен ли порт 3080 откуда-либо, кроме loopback, включая проброс портов контейнера, обратные прокси и SSH-туннели.

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

Все пять взяты из заметки Cloud Security Alliance и материала The Hacker News; в самой записи CVE нет никаких рекомендаций по устранению, кроме указания исправленной версии.

Почему Cloud Security Alliance рассматривает это как паттерн

В заметке Cloud Security Alliance этот CVE ставится в один ряд с двумя другими задокументированными ею в 2026 году случаями нарушения изоляции кодирующих агентов: GuardFall от 1 июля, когда десять из одиннадцати популярных open-source кодирующих агентов можно было склонить к выполнению shell-команд, которые должны были блокировать их защитные механизмы, и результаты исследования о передаче доверия от 22 июля, когда изолированный агент записал файл, который позднее выполнил доверенный компонент вне песочницы. В заметке прямо указано, что все три случая взяты из её собственного исследования, а не из исчерпывающего обзора рынка, и что не установлено, распространяется ли эта закономерность за пределы рассмотренных ею агентов. Она утверждает лишь то, что эти сбои относятся к разным уровням — защитным механизмам команд, доверию ниже по цепочке и теперь аутентификации плоскости управления, — и поэтому рекомендует рассматривать архитектуру песочницы как вопрос закупки, а не как уже выполненное требование.

Собственная документация DeepSeek по безопасности не противоречит такой трактовке. В файле SAFETY.md репозитория указано, что программное обеспечение «не проходило аудит безопасности и не должно рассматриваться как безопасное или готовое к эксплуатации», а также что песочница, запросы на подтверждение и элементы управления разрешениями «не гарантируют изоляцию и не предотвращают ущерб». Пробел в аутентификации, позволивший агенту выйти через API управления, закрыт в текущих сборках. Асимметрия, из-за которой побег оказался коротким — граница вокруг операций записи и ничего вокруг сети — остаётся заявленным ограничением песочницы, а не дефектом, который патч должен был исправить.