DeepSeek Harness CVE-2026-82533: Вихід із Пісочниці з CVSS 9.4

Будь-який інженер, який запускав агента AI-кодування на ноутбуці з активними SSH-ключами, вже розуміє, наскільки тонка модель загроз. CVE-2026-82533 робить її ще тоншою. Агент у пісочниці всередині DeepSeek Harness може відключити власне обмеження однією shell-командою, на стандартних налаштуваннях, без мережевого доступу та без облікових даних. Оцінка 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, — це локальний інструментарій для запуску AI-агентів кодування. Випущений у серпні 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 і дозволяє доступ, якщо значення є локальною адресою або знаходиться в налаштованому списку trustedHosts. Вона ніколи не порівнює це значення з фактичною адресою однорангового вузла з'єднання.

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

Ланцюжок експлойту — це один виклик shell. Звичайні виклики інструменту bash не потребували підтвердження. Агент звертається до свого власного локального API, підвищує сесію до danger-full-access з вимкненими запитами на підтвердження, і кожна наступна команда виконується без обмежень і без запитів. Зміна політики була записана в журналі сесії як source: {kind: 'user'}, і після виходу з пісочниці ніде не з'являлося жодної події підтвердження чи запиту. Інструментарій не міг відрізнити власний shell агента від клавіатури людини. Саме це є справді новим.

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

Що вже враховано командами безпеки

Будь-хто, хто протягом останніх п'яти років займався категоріями OWASP, вже припускав, що AI-агенти кодування є м'якою ціллю. Аргумент про розширені права добре відомий: агент має shell, читає і записує дерева вихідного коду та може отримати доступ до SSH-ключів, хмарних облікових даних, реєстрів пакетів і внутрішніх систем із робочої станції розробника. Цей ризик був закладений у ціну того дня, коли команди почали використовувати ці інструменти.

Що не було враховано — принаймні чесно — так це те, що пісочниця, покликана обмежити ці права, часто є театральним реквізитом. Команди, з якими я працював, вважають «воно працює в пісочниці» достатньою відповіддю для перевірки безпеки. Цей CVE є чистим контрприкладом. Пісочниця активно застосовувала обмеження на запис файлів у момент виходу з неї. Це підтвердив доказ концепції. Вона просто не застосовувала те, що мало значення, а саме: «агент не може спілкуватися зі своїм власним планом керування».

Другий вектор атаки — це те, що має насторожити директорів з інформаційної безпеки. Якщо порт доступний через тунель, зворотний проксі, SSH-перенаправлення або перенаправлення порту редактора, неавтентифікований віддалений зловмисник може отримати повний контроль над агентом і окремо експортувати кожну збережену розмову без API-ключа або виклику моделі. Кожен розробник, який коли-небудь запускав ssh -L для спільного використання локального сервісу з колегою, щойно став частиною моделі загроз. Так само і кожен редактор із розширенням для перенаправлення портів. Це не закладено в ціну.

Інша точка зору

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

Є також контраргумент щодо фреймінгу серйозності. UI:P у векторі означає, що потрібна взаємодія з користувачем. На практиці «агент запускає текст, контрольований зловмисником» є стандартним режимом роботи агента кодування, що працює з реальним репозиторієм і реальними залежностями. Тому UI:P тут не виконує жодної захисної роботи. Якщо що, оцінка 9.4 занижує операційний ризик для команд, які запускають ці агенти для обробки pull request від зовнішніх учасників або для дерев залежностей, отриманих із публічних реєстрів. Це, мабуть, слід відстежувати в каталозі CISA KEV з моменту виявлення реальних спроб експлуатації.

Ключові висновки

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

Виправлення було випущено за три дні. Шаблон проєктування, що породив цю помилку, присутній у кожному новому інструментарії агентів цього кварталу. Закрийте CVE. А потім прочитайте код кордону довіри вашого власного інструментарію, перш ніж це зробить хтось інший.