Проект OpenWrt выпустил версию 24.10.8, устраняющую критическую уязвимость CVE-2026-53921 (CVSS 3.1: 9.8) — переполнение стекового буфера в демоне odhcpd, обрабатывающем DHCPv6-запросы. Неаутентифицированный атакующий, имеющий сетевой доступ к UDP-порту 547, может отправить специально сформированный пакет DHCPv6 REQUEST и перезаписать стековый буфер, что на типичном встраиваемом оборудовании с высокой вероятностью приводит к выполнению произвольного кода с правами root. Публичный код эксплойта на Python уже доступен. Пользователям ветки 24.10 необходимо обновиться до 24.10.8, ветки 25.12 — до 25.12.5.
Техническая анатомия CVE-2026-53921
Согласно официальному advisory, уязвимость затрагивает две независимые точки переполнения в пути обработки DHCPv6-запросов. В обоих случаях специально сформированные опции IA заполняют фиксированный 512-байтный стековый буфер, после чего код дописывает данные ответа без проверки оставшегося пространства.
Первый путь эксплуатации требует предварительного создания пяти привязок IA_NA через пакет SOLICIT, второй срабатывает от единственного сформированного REQUEST. Оба задокументированы с рабочими PoC-скриптами на Python.
Критичность усугубляется тем, что odhcpd работает с правами root, а встраиваемое оборудование, на котором обычно развёрнут OpenWrt, как правило, не имеет защитных механизмов — стековых канареек и ASLR. Это делает переход от переполнения буфера к полноценному выполнению кода реалистичным сценарием, а не теоретической возможностью.
Затронуты все версии odhcpd до коммита e432dd6 включительно, содержащие функции dhcpv6_ia_handle_IAs() и build_ia(). Исправление реализовано через проверку оставшейся ёмкости буфера ответа перед добавлением данных.
Примечательная деталь: между advisory и примечаниями к релизу существует расхождение в классификации. Advisory группирует оба пути переполнения под CVE-2026-53921, тогда как примечания к релизу 24.10.8 выделяют переполнение RECONF_ACCEPT как отдельную проблему высокой критичности без собственного CVE. Аналогично, примечания к релизу описывают вектор атаки как «сетевой смежный» (Adjacent), тогда как CVSS-вектор в advisory использует AV:N (Network). Ни один из источников не объясняет это расхождение.
Дополнительные уязвимости в релизе 24.10.8
Помимо основной уязвимости, релиз устраняет целый спектр проблем в сервисах, включённых по умолчанию:
- odhcpd: запись за пределами буфера, использование после освобождения, утечка памяти, отказ в обслуживании, чтение за пределами стека, подмена через прокси обнаружения соседей
- uhttpd: три уязвимости контрабанды HTTP-запросов (HTTP request smuggling)
- CVE-2026-62948: внедрение имени хоста через DHCPv6, приводящее к хранимому XSS при просмотре страницы аренд в LuCI
- CVE-2026-62947: обход пути в cgi-io, позволяющий читать произвольные файлы, доступные root. Требует аутентифицированной сессии с разрешением на загрузку и соответствующим шаблоном доступа к файлам — это не анонимное чтение файлов
Уязвимости LuCI: патчи ещё не приняты
Параллельно с релизом компания Hacker House опубликовала результаты аудита LuCI и uhttpd с применением ИИ-ассистированного фаззинга. Выявлены внедрение команд, обход пути и XSS в опциональных компонентах LuCI. В ходе подготовки исправлений OpenWrt обнаружил дополнительную хранимую XSS-уязвимость и отсутствие защиты от CSRF.
Ключевые находки, по данным pull request #8878:
- luci-app-commands: символ конвейера (pipe) обходил список разрешённых аргументов, позволяя выполнять команды от root. OpenWrt установил, что путь работает без сессионного cookie и CSRF-токена, если администратор настроил команду как одновременно публичную и параметризованную
- luci-app-ddns: внедрение команд через настройку ddns_dateformat и обход пути через service_name
- luci-proto-openvpn: внедрение команд через параметр keytype и обход пути через key-directory
- luci-app-olsr: вредоносный узел mesh-сети может объявить имя хоста со скриптом, который выполнится в браузере администратора при просмотре страницы соседей OLSR
Важно учитывать контекст: эти уязвимости не являются универсальными неаутентифицированными RCE, затрагивающими каждый маршрутизатор OpenWrt. Неаутентифицированный путь через luci-app-commands требует установки опционального приложения и сознательной настройки администратором публичной параметризованной команды. Остальные пути выполнения команд требуют аутентифицированного доступа к LuCI. По состоянию на 28 июля оба pull request (#8878 и ddns-scripts) оставались открытыми и не были объединены с основной веткой.
ИИ в обнаружении и исправлении
Этот случай примечателен масштабным применением ИИ на обеих сторонах процесса. Hacker House описывает четырёхэтапную методологию «инференс-фаззинга»: модель Qwen 3.6 35B Heretic генерирует широкий пул потенциальных уязвимостей, затем модель более высокой точности (по данным исследователей, Anthropic Claude Opus 4.6 для открытых проектов) фильтрует ложные срабатывания. Финальная верификация выполняется вручную. Со стороны OpenWrt несколько коммитов в pull request содержат метку «Assisted-by: Claude:claude-opus-5», а автоматизированный обзор указывает на использование Claude Code.
Рекомендации
- Немедленно обновите прошивку до OpenWrt 24.10.8 или 25.12.5 через OpenWrt Firmware Selector
- Обновите отдельно установленные пакеты — они не обновляются автоматически вместе с прошивкой
- Проверьте конфигурацию luci-app-commands: убедитесь, что ни одна команда не настроена одновременно как публичная (public=1) и параметризованная (param=1)
- Удалите неиспользуемые опциональные приложения LuCI, особенно luci-app-bmx7, luci-app-olsr, luci-app-commands
- Пересмотрите делегированные разрешения LuCI, ограничив доступ к cgi-io
- Запланируйте миграцию на ветку 25.12 до сентября 2026 года — окончания поддержки безопасности ветки 24.10
По состоянию на 28 июля ни CVE-2026-53921, ни другие описанные уязвимости не были внесены в каталог CISA KEV, и официальные материалы OpenWrt не сообщали об эксплуатации в дикой природе. Однако наличие публичного PoC-кода для критической уязвимости в сервисе, работающем от root на оборудовании без ASLR, делает окно до начала активной эксплуатации минимальным. Обновление прошивки следует выполнить в ближайшие часы, а не дни.
