На проверке CVE-2026-34908 + 34909: уязвимость UniFi OS до root

Три CVE с CVSS 10.0, три записи в CISA KEV, EPSS в Top 1% для каждой - и всё на одном UniFi Dream Machine, который одновременно рулит сетью, камерами и дверными замками клиента. Когда Bishop Fox опубликовал разбор цепочки CVE-2026-34908 + CVE-2026-34909 + CVE-2026-34910, я в тот же день поднял стенд на UniFi OS Server 5.0.6 и прогнал их публичный детектор - Vulnerable. У двух клиентов в активных проектах management-интерфейс торчал на белом IP. Просто висел на 443, как приглашение.

Ниже - разбор механики каждого звена цепочки: от конкретных HTTP-заголовков и конфигурации nginx до практического workflow fingerprinting и post-exploitation.

Архитектура UniFi OS: почему одна Improper Access Control уязвимость ломает семь продуктов​

Прежде чем разбирать эксплуатацию CVE-2026-34908 и CVE-2026-34909, нужно понять, что стоит за портом 443 на UniFi-консоли. Это не веб-интерфейс маршрутизатора в привычном понимании - это целый зоопарк. Подробнее - в нашем руководстве по уязвимости iot устройств.

По данным Ubiquiti, UniFi Cloud Gateway - gateway-файрвол, на котором крутятся приложения для сети, Wi-Fi, камер видеонаблюдения, физического контроля доступа, VoIP и централизованного управления несколькими сайтами. UniFi OS Server - замена устаревшего UniFi Network Server для self-hosted инсталляций, единый management-интерфейс для всего этого хозяйства.

Исследователи из Catchify восстановили внутреннюю архитектуру по прошивке. Картина такая: весь трафик из интернета или LAN попадает на nginx (порт 443, TLS). Nginx делает auth_request - подзапрос к Node-сервису аутентификации, подставляет или удаляет заголовки, после чего маршрутизирует запрос дальше. Путь /api/[I] идёт в unifi-core (Koa-приложение, работающее от root - запомните этот момент). Пути /proxy/<app>/[/I] проксируются на application plane: Protect (7080), Talk (30080), Network (8081), Access (12080) и другие. Все бекенды привязаны к loopback - нет маршрута из сети в Talk, Access или Network, минуя nginx.

Два архитектурных свойства делают эту уязвимость контроллера сети критической.

Первое: nginx - единственный gate. Обход его аутентификации = обход аутентификации всех семи продуктов одновременно. Второго эшелона проверки нет. Вообще.

Второе: конфигурация nginx генерируется в рантайме. Приложение unifi-core записывает конфиг в /unifi-core/http/, nginx его инклюдит. Штатный nginx.conf в прошивке - placeholder. Периметр безопасности порождается тем, что находится за ним, и меняется в зависимости от набора приложений, модели устройства и состояния setup.

Определение целевого сервиса делается через map $request_uri $target_runnable - nginx извлекает имя приложения из URL и передаёт его в заголовок X-Target-Runnable. Директива proxy_set_header безусловно перезаписывает клиентский X-UserId значением из auth-подзапроса - вот и весь механизм gate. Для атакующего это значит: одна ошибка в обработке URI - и мульти-продуктовая инфраструктура открыта целиком.

CVE-2026-34908: обход аутентификации через broken access control API​

CVE-2026-34908 (CWE-284, Improper Access Control) - уязвимость UniFi OS, позволяющая неаутентифицированному атакующему вносить несанкционированные изменения в систему. По NVD: «A malicious actor with access to the network could exploit an Improper Access Control vulnerability found in UniFi OS devices to make unauthorized changes to the system.»

Ключевые метрики:

• CVSS 3.1: 10.0 Critical
• Вектор: AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H - сетевой доступ, низкая сложность, никаких привилегий, никакого взаимодействия с пользователем, выход за scope, полное воздействие на все три параметра
• CISA KEV: добавлена 23 июня 2026, дедлайн 26 июня (3 дня, BOD 26-04)
• SSVC: active exploitation, automatable: yes, total technical impact
• EPSS: 0.8519, percentile 0.9971 - Top 1% всех CVE

Raw URI vs Normalized URI: корень проблемы​

Эксплуатация CVE-2026-34908 опирается на классическую boundary-consistency проблему - несогласованность обработки URI между слоями nginx. Баг старый как мир, но каждый раз находят заново.

По анализу Bishop Fox, nginx фронтирует все сервисы и при каждом запросе делает auth_request - подзапрос к Node-сервису, который решает, публичный маршрут или защищённый. Обход аутентификации возникает из-за расхождения в двух представлениях одного запроса.

auth_request получает raw URI - строку в том виде, в каком её отправил клиент, включая URL-encoded символы.

Маршрутизация использует normalized URI - после декодирования %2e, %2f и коллапса path-сегментов вроде /../.

Если raw URI начинается с auth-exempt префикса (путь, помеченный как публичный), auth_request пропускает запрос без проверки токена. Но после нормализации traversal-последовательности разрешаются, и фактический путь указывает на защищённый внутренний эндпоинт. Именно эта разница позволяет сконструировать запрос, который проходит auth-check как публичный и попадает на handler, требующий аутентификации.

OWASP описывает вариации encoded traversal: %2e%2e%2f, %2e%2e/, ..%2f - стандартные способы обмана URI-парсеров. MITRE CWE-22 (parent-weakness для CVE-2026-34909) описывает использование специальных элементов (.., path separators) для выхода за пределы разрешённых директорий. В контексте UniFi OS эти техники применяются на уровне authorization gateway, а не для чтения файлов напрямую - файловый доступ обеспечивает следующее звено цепочки.

CVE-2026-34909: directory traversal атака - от обхода пути до чтения системных файлов​

CVE-2026-34909 (CWE-22, Path Traversal) работает в тандеме с CVE-2026-34908. NVD: «A malicious actor with access to the network could exploit a Path Traversal vulnerability found in UniFi OS devices to access files on the underlying system that could be manipulated to access an underlying account.»

Метрики идентичны: CVSS 10.0, тот же вектор, CISA KEV с тем же дедлайном. EPSS - 0.6390 (percentile 0.9919, Top 1%).

Bishop Fox позиционирует CVE-2026-34908 и CVE-2026-34909 как единый блок обхода authentication gateway. По сути это два ракурса одной проблемы: CVE-2026-34908 - некорректный контроль доступа, позволяющий пройти мимо auth-check; CVE-2026-34909 - path traversal, позволяющий через manipulated путь добраться до файлов и хендлеров за пределами intended scope.

По данным BreachBits, эксплуатация CVE-2026-34909 выглядит так: неаутентифицированный атакующий отправляет crafted request, в котором traversal-последовательность обходит endpoint аутентификации и попадает на внутренний proxy handler, дающий доступ к файлам, ведущим к компрометации учётных записей. Pre-authentication атака: traversal обходит auth-check целиком.

На практике захват системы через path traversal означает доступ к конфигурационным файлам, JWT-секретам, SSH-ключам и базам аккаунтов UniFi OS. Эти артефакты - плацдарм для следующего шага.

Полная цепочка эксплойтов UniFi: от initial access до root​

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Итог: один HTTP-запрос → auth bypass → file read/command injection → root на устройстве, управляющем всей инфраструктурой. Красиво, если бы не было так страшно.

Бизнес-логика атаки: зачем это атакующему​

RCE на сетевом оборудовании - это не про один ящик. Компрометация UniFi OS = network appliance compromise с немедленным выходом на:

• Credential harvesting: JWT-секреты, RADIUS shared secrets, Wi-Fi PSK, SSH-ключи, базы аккаунтов (Data from Local System, T1005). Всё, что устройство когда-либо видело - считай утекло.
• Контроль сетевой инфраструктуры: маршрутизация, файрвол, VLAN, ACL - атакующий может перенаправлять трафик, создавать скрытые правила NAT.
• Физический доступ: через UniFi Access - дверные контроллеры. Да, буквально открыть дверь.
• Lateral movement: устройство стоит на границе сети и видит весь трафик. Идеальная точка для пивота.

По данным BreachBits, ботнеты уже активно эксплуатируют эту цепочку. Для MSP-провайдеров, управляющих десятками клиентов через Site Manager, компрометация одной консоли может означать доступ к инфраструктуре всех обслуживаемых организаций. Один Dream Machine - и ты внутри у пятидесяти компаний.

Fingerprinting и безопасная верификация уязвимости UniFi OS​

На реальном path traversal пентесте первый вопрос - есть ли UniFi OS в скоупе и какая версия.

Recon на периметре. Management обычно на портах 443 (HTTPS) или 8443 (legacy). В HTTP-ответах ищите: заголовки x-unifi-version, характерные JavaScript-бандлы с именами unifi-core, специфичные HTML-маркеры Ubiquiti. Быстрая проверка:

nmap -sV -p 443,8443 --script http-title <target>
# Ищем характерные заголовки страницы
# Версия ≤ 5.0.6 - уязвима, ≥ 5.0.8 - исправлена

Безопасная верификация. Bishop Fox выпустил публичный детектор - репозиторий BishopFox/CVE-2026-34908-check на GitHub. Скрипт использует только GET-запросы и не выполняет команд на целевом устройстве:

git clone https://github.com/BishopFox/CVE-2026-34908-check.git
cd CVE-2026-34908-check
python3 check.py --target https://<target>:443
# Результат: Vulnerable / Not Vulnerable / Unable to determine

Для массовой проверки в скоупе - Nuclei-шаблоны в официальном репозитории ProjectDiscovery: CVE-2026-34908.yaml и CVE-2026-34910.yaml:

nuclei -t http/cves/2026/CVE-2026-34908.yaml \
       -l targets.txt -o results.txt

Оба метода неразрушающие - не эксплуатируют Ubiquiti exploit, только детектируют уязвимую конфигурацию. Подходят для проверки без угрозы продакшену клиента. Публичные PoC-репозитории тоже доступны на GitHub (например, Boreas37/CVE-2026-34910-PoC - 7 звёзд на момент написания), но их использование допустимо только на авторизованных стендах. Не надо объяснять почему.

Затронутые продукты и предусловия эксплуатации​

Продукт	Уязвимые версии	Исправление
UniFi OS Server	≤ 5.0.6	≥ 5.0.8 (Bulletin 064)
UniFi Dream Machine (все модели)	Прошивки до Bulletin 064	Обновление по Bulletin 064
UniFi Cloud Gateway Industrial	Прошивки до Bulletin 064	Обновление по Bulletin 064

Предусловие	Значение
Сетевой доступ	Порт 443 или 8443 доступен атакующему
Аутентификация	Не требуется (PR:N)
Взаимодействие пользователя	Не требуется (UI:N)
Автоматизируемость	Да (CISA SSVC: automatable)
Сложность атаки	Низкая (AC:L)

Если management-интерфейс доступен из интернета, через VPN или из любого скомпрометированного сегмента - устройство под угрозой. Гостевой Wi-Fi, скомпрометированное IoT-устройство, рабочая станция подрядчика - достаточно сетевой видимости порта. Я на одном проекте нашёл management UniFi, доступный из гостевого VLAN - «ну а кто туда полезет», сказал админ.

Детектирование и threat hunting после патча​

Для blue team - на что смотреть в логах, чтобы понять, была ли уязвимость проэксплуатирована до обновления.

Сетевые индикаторы:

• HTTP-запросы с URL-encoded traversal-последовательностями (%2e%2e%2f, ..%2f, %2e%2e/) к портам 443/8443, особенно к путям с auth-exempt префиксами
• Всплеск запросов к /proxy/* с нестандартными User-Agent или из нетипичных IP-диапазонов
• Обращения к management-интерфейсу с адресов за пределами доверенных сегментов

Хостовые индикаторы на UniFi OS:

• Неожиданные дочерние процессы у unifi-core или application-сервисов
• Изменения в /etc/passwd, /etc/shadow, SSH authorized_keys
• Модификация nginx-конфигурации вне штатного обновления
• Новые cron-задачи или systemd-сервисы
• Нетипичные исходящие соединения (C2-каналы)

Compromise assessment checklist для пентестера / IR-инженера:

1. Зафиксировать текущую версию UniFi OS (≤ 5.0.6 = была уязвима в окне эксплуатации)
2. Сравнить текущую конфигурацию с бекапом, сделанным до июня 2026
3. Проверить SSH authorized_keys на наличие незнакомых ключей
4. Аудит пользователей и их привилегий в UniFi OS
5. Просмотреть историю изменений конфигурации сетевого оборудования
6. Проверить исходящие соединения с устройства
7. Ротировать учётные данные: Wi-Fi PSK, RADIUS secrets, административные пароли, VPN-сертификаты

Если обнаружены признаки компрометации - устройство подлежит полному пересозданию (rebuild), а не только патчу. Все секреты, которые устройство могло видеть, считаются скомпрометированными. Тут полумеры не работают.

Сегментация после патча: архитектурные выводы​

Даже после обновления до ≥ 5.0.8 архитектурная рекомендация - изолировать management plane. Выделить UniFi OS в отдельный VLAN с ACL, ограничивающим доступ только с jump host. Отключить remote access через Ubiquiti cloud, если он не критичен. Настроить IDS/IPS на сигнатуры traversal-паттернов к UniFi-эндпоинтам. Мониторить обращения к портам 443/8443 из неавторизованных сегментов.

Четыре месяца после публикации уязвимостей Ubiquiti UniFi Controller я продолжаю встречать Dream Machine с портом 443 на белом IP - у малого бизнеса, гостиниц, коворкингов. Ubiquiti-устройства ставят по принципу «настроил и забыл», и именно эта категория - первая цель ботнетов.

Главный урок этой цепочки - не в конкретных CVE, а в архитектурном антипаттерне: когда один nginx-инстанс - единственная граница аутентификации для семи продуктов, а его конфигурацию генерирует само защищаемое приложение, любая inconsistency в парсинге URI превращается в полный bypass. Я встречал аналогичные расхождения raw URI vs normalized URI в кастомных API-gateway на других проектах - это не экзотика, а распространённый антипаттерн. Разница в том, что за nginx на UniFi OS стоит не один микросервис, а вся сетевая инфраструктура, камеры и дверные замки.

Когда EPSS показывает 0.85 для CVE-2026-34908 и 0.87 для CVE-2026-34910 - обе в Top 1% - и CISA подтверждает active exploitation, это не теоретическая проблема, а текущая операционная реальность. Хочется руки в крови - на HackerLab есть задачи, где auth bypass + traversal нужно раскрутить до полного захвата самостоятельно.