Критична вразливість DeepSeek Harness: як підроблений Host-заголовок обходить захист API

QVD-2026-57410 — це заявлена критична вразливість у DeepSeek Harness (DSH) версії 0.1.1-rc.2. За повідомленнями, пов’язаними з QiAnXin, ідеться про неавторизоване віддалене виконання команд (RCE) з оцінкою CVSS 3.0 на рівні 9.8. Проблема полягає в тому, що рішення про довіру до запитів до /api може ґрунтуватися на керованому клієнтом HTTP-заголовку Host — а це небезпечна заміна автентифікації. 1924

Реальний рівень загрози значною мірою залежить від способу розгортання. Документована команда запуску DeepSeek відкриває вебінтерфейс на 127.0.0.1:3080 за замовчуванням, що обмежує прямий віддалений доступ. Ситуація стає значно небезпечнішою, якщо сервіс опубліковано на не loopback-інтерфейсі або до нього можна дістатися через Docker, reverse proxy, тунель, VPN, локальну мережу чи ingress. 1118

Як працює обхід через Host-заголовок

Уразлива логіка намагається відрізнити локальні запити від віддалених за інформацією про адресу хоста в запиті. Але заголовок Host надсилає сам клієнт, тож його можна підробити. Якщо зловмисник має мережевий доступ до сервісу, він може передати значення, схоже на локальне, і змусити рівень /api сприйняти запит як довірений. У звітах це описують як обхід межі довіри, побудованої за принципом доступу лише з loopback-інтерфейсу. 1924

На високому рівні заявлений ланцюжок атаки виглядає так:

1. Отримати доступ до відкритого веб- або адміністративного endpoint DSH.
2. Надіслати запит із підробленим локальним значенням заголовка Host.
3. Обійти обмеження /api, яке має захищати внутрішні операції.
4. Викликати обмежену RPC-функціональність.
5. Зареєструвати або використати контрольований зловмисником маршрут постачальника моделі.
6. Задіяти можливості агента DSH для виконання команд на хості. 1920

Тому це не просто помилка маршрутизації чи витік інформації. Обхід веде до функцій, призначених для роботи AI-агента із системними можливостями.

Чому це може призвести до віддаленого виконання команд

DeepSeek називає Harness експериментальним програмним забезпеченням для попереднього перегляду розробниками й прямо зазначає, що проєкт не проходив аудит безпеки. У попередженні безпеки сказано, що Harness може виконувати код і команди, згенеровані моделлю, а також отримувати доступ до мережі, процесів, облікових даних і файлів, доступних цьому середовищу. 4

Підсистема LLM підтримує реєстрацію постачальників і пошук моделей, зокрема віддалену операцію discoverModels. 23 Згідно з описаним ланцюжком експлуатації, контрольований зловмисником постачальник може надати вхідні дані, потрібні для досягнення можливостей агента з виконання команд. 19

Успішна атака не означає автоматичного отримання прав root. Команди виконуватимуться з правами процесу, під яким працює DSH. Однак цього може бути достатньо, щоб читати або змінювати доступні файли, використовувати знайдені облікові дані чи API-ключі, запускати процеси, змінювати дані застосунків або створювати вихідні мережеві з’єднання.

Наслідки залежать від конфігурації. Ризик зростає, якщо сервіс має надмірний доступ до файлової системи, працює у привілейованому контейнері, бачить змонтований Docker socket або має доступ до хмарних облікових даних. Надані матеріали не доводять, що кожне розгортання автоматично призводить до повного захоплення хоста.

Які конфігурації найбільш уразливі

Насамперед варто перевірити такі сценарії:

• DSH прив’язано до 0.0.0.0 або іншої адреси, не пов’язаної лише з локальним інтерфейсом.
• Docker чи інший контейнерний рушій публікує порт 3080 за межі локального хоста.
• Reverse proxy передає адміністративний API в інтернет або недовірену локальну мережу.
• Тунель, VPN або ingress робить сервіс доступним користувачам без надійної автентифікації.
• Проксі приймає довільні значення Host від клієнта або без перевірки передає їх далі на upstream-сервіс.

Сам факт, що сервіс називають «внутрішнім», не є засобом авторизації. Будь-який зловмисник, який може дістатися endpoint і впливати на потрібні заголовки запиту, може спробувати цей обхід.

Публічний PoC, статус CVE та ознаки експлуатації

Кілька повідомлень стверджують, що технічні деталі або proof-of-concept для QVD-2026-57410 уже оприлюднені. 192027 Це підвищує терміновість ізоляції та перевірки систем, але наявність публічного PoC не є доказом компрометації конкретної інсталяції.

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

QVD-2026-57410 — це ідентифікатор QVD, а не CVE. Подібний номер CVE-2026-57410 у базі NVD стосується іншої вразливості — підвищення привілеїв у MailerPress. 17

Що робити адміністраторам

1. Спочатку приберіть сервіс із мережі

Не публікуйте адміністративний і API-сервіс DSH у відкритому інтернеті. Прив’яжіть його до loopback-інтерфейсу або окремої мережі керування. Для віддаленого адміністрування використовуйте контрольований VPN чи bastion-хост.

2. Обмежте доступ на кожному мережевому рівні

Налаштуйте правила firewall, хмарних security group, контейнерної мережі та reverse proxy так, щоб доступ мали лише явно довірені джерела. Не покладайтеся на внутрішній маршрут або «локальне» значення заголовка як доказ особи користувача.

3. Перевіряйте та перезаписуйте заголовки проксі

На edge-проксі відхиляйте неочікувані значення Host. Якщо проксіювання необхідне, перезаписуйте upstream-заголовок Host на заздалегідь визначене значення, а не передавайте без перевірки значення від клієнта. Заголовки з IP клієнта слід вважати надійними лише тоді, коли вони надходять від контрольованого проксі.

4. Додайте автентифікацію, незалежну від Host

Захистіть адміністративні та внутрішні RPC-операції справжньою автентифікацією й авторизацією — наприклад, через шлюз із надійною автентифікацією, mTLS і контроль доступу для окремих операцій. Перевірка Host може допомагати з маршрутизацією, але ніколи не має бути єдиним механізмом встановлення особи.

5. Зменште ризик пошуку постачальників і вихідних запитів

Вимкніть або обмежте llm.discoverModels, якщо ця функція не потрібна. Якщо пошук моделей необхідний, дозвольте лише визначені endpoint постачальників і запровадьте контроль вихідного трафіку. Блокування доступу до чутливих внутрішніх і хмарних metadata-адрес може зменшити наслідки зловживання шляхом пошуку постачальника як примітивом для серверних запитів. Документація DSH для LLM підтверджує наявність реєстрації постачальників і пошуку моделей. 23

6. Перевірте виправлення за офіційними матеріалами

Надані джерела визначають 0.1.1-rc.2 як уражену версію та показують подальшу активність у репозиторії, але не підтверджують, що конкретна новіша збірка усуває цю вразливість. Перевірте актуальні release notes і security advisories DeepSeek, перш ніж вважати оновлення достатнім. У власному попередженні про безпеку проєкт і надалі називає Harness експериментальним і непридатним для production-розгортання. 410

7. Перевірте систему та замініть секрети, якщо сервіс був доступний

Перегляньте журнали reverse proxy і DSH у пошуках аномальних запитів до /api, підроблених локальних значень Host, неочікуваної реєстрації постачальників, запуску процесів, змін файлів і незвичних вихідних з’єднань. Замініть облікові дані, доступні процесу DSH. Якщо є ознаки виконання команд або закріплення в системі, ізолюйте та перебудуйте уражений хост чи контейнер, а не припускайте, що простого перезапуску сервісу достатньо.