Разработчики OpenWrt выпустили версию 24.10.8, закрывающую критическую уязвимость в сетевом стеке — переполнение буфера в службе odhcpd, отвечающей за раздачу адресов по DHCPv6. Уязвимость получила идентификатор CVE-2026-53921 и оценку 9.8 по шкале CVSS 3.1 — это максимум для большинства реальных сценариев, при том что для атаки не требуется ни аутентификация, ни какие-либо привилегии в сети. Достаточно отправить специально сформированный DHCPv6-запрос REQUEST на 547 UDP-порт устройства.
Суть проблемы в том, что odhcpd работает от имени root, а при обработке определённых опций IA (Identity Association) программа записывает данные ответа в буфер фиксированного размера — 512 байт — без должной проверки границ. Исследователи описали два независимых пути переполнения. В первом атакующий сначала отправляет SOLICIT, создавая пять привязок IA_NA, а затем провоцирует переполнение через последующий REQUEST. Второй путь проще: хватает одного специально составленного REQUEST-пакета. Уязвимый код — функции dhcpv6_ia_handle_IAs() и build_ia() — присутствовал в master-ветке odhcpd вплоть до коммита e432dd6 и во всех более ранних релизах. Патч добавляет проверку оставшегося места в буфере перед тем, как туда что-либо дописывается. Публичный proof-of-concept на Python уже существует для обоих сценариев переполнения.
На встроенном оборудовании, где обычно отсутствуют механизмы защиты вроде stack canaries и рандомизации адресного пространства (ASLR), теоретическая возможность выполнения произвольного кода превращается в практическую. То есть речь не просто об отказе в обслуживании — успешная эксплуатация грозит полным захватом маршрутизатора.
Здесь возникает нестыковка, которую пока никто не прокомментировал официально. В release notes к версии 24.10.8 переполнение через RECONF_ACCEPT описано отдельно как уязвимость высокой степени опасности, но без собственного CVE — и охарактеризовано как «network-adjacent», то есть требующее нахождения атакующего в той же сети. При этом в самом векторе CVSS для CVE-2026-53921 указано AV:N — «Network», подразумевающее атаку из любой точки интернета. Ни advisory на GitHub, ни текст релиза не объясняют, как соотносятся эти два описания и идёт ли речь об одной и той же уязвимости или о двух разных. По состоянию на 28 июля эксплуатация в реальных условиях не зафиксирована, уязвимость отсутствует в каталоге CISA KEV (версия от 27 июля) — впрочем, отсутствие записи в каталоге само по себе ничего не доказывает.
Пользователям веток 24.10 нужно ставить 24.10.8, тем, кто на новой линейке — 25.12.5. Прошивки доступны через стандартный OpenWrt Firmware Selector. Сама ветка 24.10 пока находится на поддержке, но её конец жизненного цикла запланирован на сентябрь 2026 года, так что миграция на 25.12 — вопрос времени, а не выбора.
Кроме центральной уязвимости, релиз закрывает целый букет проблем в odhcpd, доступных до аутентификации: запись за границами буфера, use-after-free, утечка памяти, отказ в обслуживании, чтение за пределами стека и подмена ответов в механизме neighbour discovery proxy. Отдельно исправлены три уязвимости класса request smuggling в веб-сервере uhttpd. Найдена и XSS через инъекцию имени хоста DHCPv6 (CVE-2026-62948) — вредоносное имя устройства в сети провоцирует выполнение скрипта в браузере администратора, когда тот открывает страницу leases в LuCI. Ещё одна проблема — CVE-2026-62947 в модуле cgi-io, path traversal, дающая доступ к произвольным файлам, читаемым от root. Правда, здесь всё не так драматично, как звучит: нужна авторизованная сессия, права на скачивание через cgi-io и подходящее разрешение на wildcard-чтение файлов — это не анонимная дыра.
Параллельно и независимо от релиза 24.10.8 идёт другая история — аудит веб-интерфейса LuCI и uhttpd, проведённый компанией Hacker House. Их технический директор Мэттью Хики, известный под псевдонимом Hacker Fantastic, использовал ИИ-ассистированный подход для анализа основных веток кода: коммит LuCI от 27 мая (3b4f44d8e3d9d5de35127b42dd449babe2d19fe5) и коммит uhttpd от 13 июня (7b1bec45826bd78c8afc993435bdc0f1df2fe399). Результат — семь находок, три из которых позволяют скомпрометировать устройство вообще без авторизации: directory traversal в luci-app-bmx7, хранимая XSS в luci-app-olsr и командная инъекция в luci-app-commands. Ещё четыре требуют учётных данных администратора LuCI, но при их наличии позволяют выполнять произвольные команды на устройстве.
Интереснее оказалась переклассификация: из пяти находок, изначально считавшихся пост-аутентификационными, одна на деле может сработать и без сессии — если администратор сам настроил команду в luci-app-commands как публичную (public='1') и параметризованную (param='1'). Полезная нагрузка через OLSR тоже может быть внедрена без учётных данных, но выполнится только тогда, когда администратор откроет страницу соседних узлов сети.
Мейнтейнер OpenWrt Хауке Мертенс опубликовал 26 июля Pull Request 8878, указав Hacker House как источник находок. Издание The Hacker News проверило его состояние 28 июля — запрос всё ещё был открыт и не смёржен. Внутри PR девять коммитов, но их количество не совпадает с числом отчётов: шесть соответствуют находкам Hacker House, два касаются дополнительных проблем, обнаруженных самой командой OpenWrt в процессе подготовки исправлений, и один правит опечатку в имени файла, не связанную с безопасностью. Две находки из отчёта Hacker House к моменту публикации PR уже были исправлены в master-ветке и в счёт девяти коммитов не вошли.
Среди конкретных изменений — устранение возможности обойти список разрешённых аргументов в luci-app-commands с помощью символа вертикальной черты (bare pipe), из-за чего команды выполнялись от root даже без сессионной куки и CSRF-токена, если параметры команды были публичными и параметризованными. В luci-app-ddns закрыты сразу две дыры: командная инъекция через настройку ddns_dateformat и path traversal через service_name — причём именно в процессе исправления этой части OpenWrt наткнулась на дополнительную хранимую XSS, изначально не входившую в отчёт Hacker House. В luci-proto-openvpn обнаружена инъекция shell-команд через параметр keytype и path traversal через параметры директории с ключами. Наконец, в luci-app-olsr вредоносный узел mesh-сети может объявить специально сформированное имя хоста, которое выполнится как скрипт в браузере администратора при просмотре списка соседних узлов.
Важная оговорка по поводу непроверенного пути в luci-app-commands: он срабатывает только если это дополнительное приложение вообще установлено на устройстве, и только если администратор сам, осознанно, настроил какую-то команду как публичную с параметрами — это не универсальная уязвимость, угрожающая каждому роутеру на OpenWrt. Но если условия выполнены, атака даёт выполнение команд с правами root.
Отдельный pull request, не связанный с LuCI напрямую, касается пакета ddns-scripts — там та же небезопасная настройка ddns_dateformat используется вне веб-интерфейса. Риск в том, что оператор с делегированными правами на настройку DDNS может подставить в значение параметра shell-синтаксис, который выполнится при следующем запуске обновления сервиса — в том числе после перезагрузки или переконфигурации. По состоянию на 28 июля этот PR тоже оставался открытым и не смёрженным.
Ещё две находки — path traversal с несанкционированным чтением файлов в luci-app-bmx7 и командная инъекция через ttyd_start в luci-app-dockerman — были уже исправлены в master-ветке LuCI, но, по подтверждению OpenWrt, всё ещё требуют бэкпорта в стабильные релизные ветки. С bmx7 вышла путаница: Hacker House включила эту находку в своё раскрытие от 8 июля, назвав её путём к полной компрометации устройства без аутентификации, тогда как публичный advisory OpenWrt описывает её более узко — как неавторизованный доступ к файлам, читаемым через CGI. Более того, в качестве репортёра там указана некая "nebusecurity", а не Hacker House, и в самой компании не знают, идёт ли речь о дублирующихся отчётах разных исследователей или же кредит был распределён ошибочно.
Отдельного внимания заслуживает то, как именно эти уязвимости искали. Hacker House описывает четырёхэтапный процесс, который они называют inference-fuzzing: сначала строится модель угроз, затем код многократно прогоняется через языковую модель для генерации широкого пула потенциальных проблем, после чего более точная модель отсеивает ложные срабатывания, и лишь затем исследователи вручную проверяют оставшееся — читают код и, где это практически возможно, тестируют поведение во время выполнения. На этапе поиска использовалась модель Qwen 3.6 35B Heretic, ориентированная на полноту охвата, для финальной триаж-фильтрации в открытых проектах применялась Claude Opus 4.6 от Anthropic, а для полностью офлайн-аудитов, где закрытый исходный код клиента не должен покидать его инфраструктуру, использовалась Qwen 3.5 115B. Подтверждение находок шло через ручной код-ревью и стандартные методы DAST (динамического тестирования безопасности приложений) там, где это было технически осуществимо; в отчёт попадали только подтверждённые уязвимости, хотя эксплойт-пейлоады иногда приходилось корректировать вручную уже на этапе проверки. Политика раскрытия у компании стандартная для индустрии: открытым проектам даётся 7–10 рабочих дней на подтверждение получения отчёта, после чего начинается совместная работа над сроками исправления; если ответа нет — компания оставляет за собой право опубликовать ограниченные детали, чтобы подтолкнуть к реакции.
Искусственный интеллект использовался и на стороне OpenWrt при подготовке исправлений — часть предложенных коммитов содержит служебную пометку «Assisted-by: Claude:claude-opus-5», а автоматический ревью в PR по LuCI прямо указывает, что был сгенерирован с помощью Claude Code. При этом финальную верификацию находок и качества патчей всё равно выполняли живые люди — исследователи и мейнтейнеры проекта.
Администраторам, использующим OpenWrt, стоит как можно скорее обновиться до 24.10.8 либо 25.12.5, отдельно проверить и при необходимости обновить пакеты, установленные вручную, пересмотреть делегированные права доступа к LuCI, удалить неиспользуемые дополнительные приложения и явно проверить, не настроена ли где-то команда в luci-app-commands одновременно как публичная и параметризованная. По состоянию на 28 июля оба открытых pull request — 8878 и патч для ddns-scripts — всё ещё не имели присвоенных идентификаторов CVE, оценок CVSS, полного перечня затронутых версий и номеров исправленных стабильных пакетов. Ни в одном из них не сообщается о зафиксированных случаях эксплуатации в реальных условиях. The Hacker News на момент публикации своего материала ожидало от команды OpenWrt ответа по поводу сопоставления с CVE, точного списка затронутых версий и текущего статуса патчей.
Изображение носит иллюстративный характер
Суть проблемы в том, что odhcpd работает от имени root, а при обработке определённых опций IA (Identity Association) программа записывает данные ответа в буфер фиксированного размера — 512 байт — без должной проверки границ. Исследователи описали два независимых пути переполнения. В первом атакующий сначала отправляет SOLICIT, создавая пять привязок IA_NA, а затем провоцирует переполнение через последующий REQUEST. Второй путь проще: хватает одного специально составленного REQUEST-пакета. Уязвимый код — функции dhcpv6_ia_handle_IAs() и build_ia() — присутствовал в master-ветке odhcpd вплоть до коммита e432dd6 и во всех более ранних релизах. Патч добавляет проверку оставшегося места в буфере перед тем, как туда что-либо дописывается. Публичный proof-of-concept на Python уже существует для обоих сценариев переполнения.
На встроенном оборудовании, где обычно отсутствуют механизмы защиты вроде stack canaries и рандомизации адресного пространства (ASLR), теоретическая возможность выполнения произвольного кода превращается в практическую. То есть речь не просто об отказе в обслуживании — успешная эксплуатация грозит полным захватом маршрутизатора.
Здесь возникает нестыковка, которую пока никто не прокомментировал официально. В release notes к версии 24.10.8 переполнение через RECONF_ACCEPT описано отдельно как уязвимость высокой степени опасности, но без собственного CVE — и охарактеризовано как «network-adjacent», то есть требующее нахождения атакующего в той же сети. При этом в самом векторе CVSS для CVE-2026-53921 указано AV:N — «Network», подразумевающее атаку из любой точки интернета. Ни advisory на GitHub, ни текст релиза не объясняют, как соотносятся эти два описания и идёт ли речь об одной и той же уязвимости или о двух разных. По состоянию на 28 июля эксплуатация в реальных условиях не зафиксирована, уязвимость отсутствует в каталоге CISA KEV (версия от 27 июля) — впрочем, отсутствие записи в каталоге само по себе ничего не доказывает.
Пользователям веток 24.10 нужно ставить 24.10.8, тем, кто на новой линейке — 25.12.5. Прошивки доступны через стандартный OpenWrt Firmware Selector. Сама ветка 24.10 пока находится на поддержке, но её конец жизненного цикла запланирован на сентябрь 2026 года, так что миграция на 25.12 — вопрос времени, а не выбора.
Кроме центральной уязвимости, релиз закрывает целый букет проблем в odhcpd, доступных до аутентификации: запись за границами буфера, use-after-free, утечка памяти, отказ в обслуживании, чтение за пределами стека и подмена ответов в механизме neighbour discovery proxy. Отдельно исправлены три уязвимости класса request smuggling в веб-сервере uhttpd. Найдена и XSS через инъекцию имени хоста DHCPv6 (CVE-2026-62948) — вредоносное имя устройства в сети провоцирует выполнение скрипта в браузере администратора, когда тот открывает страницу leases в LuCI. Ещё одна проблема — CVE-2026-62947 в модуле cgi-io, path traversal, дающая доступ к произвольным файлам, читаемым от root. Правда, здесь всё не так драматично, как звучит: нужна авторизованная сессия, права на скачивание через cgi-io и подходящее разрешение на wildcard-чтение файлов — это не анонимная дыра.
Параллельно и независимо от релиза 24.10.8 идёт другая история — аудит веб-интерфейса LuCI и uhttpd, проведённый компанией Hacker House. Их технический директор Мэттью Хики, известный под псевдонимом Hacker Fantastic, использовал ИИ-ассистированный подход для анализа основных веток кода: коммит LuCI от 27 мая (3b4f44d8e3d9d5de35127b42dd449babe2d19fe5) и коммит uhttpd от 13 июня (7b1bec45826bd78c8afc993435bdc0f1df2fe399). Результат — семь находок, три из которых позволяют скомпрометировать устройство вообще без авторизации: directory traversal в luci-app-bmx7, хранимая XSS в luci-app-olsr и командная инъекция в luci-app-commands. Ещё четыре требуют учётных данных администратора LuCI, но при их наличии позволяют выполнять произвольные команды на устройстве.
Интереснее оказалась переклассификация: из пяти находок, изначально считавшихся пост-аутентификационными, одна на деле может сработать и без сессии — если администратор сам настроил команду в luci-app-commands как публичную (public='1') и параметризованную (param='1'). Полезная нагрузка через OLSR тоже может быть внедрена без учётных данных, но выполнится только тогда, когда администратор откроет страницу соседних узлов сети.
Мейнтейнер OpenWrt Хауке Мертенс опубликовал 26 июля Pull Request 8878, указав Hacker House как источник находок. Издание The Hacker News проверило его состояние 28 июля — запрос всё ещё был открыт и не смёржен. Внутри PR девять коммитов, но их количество не совпадает с числом отчётов: шесть соответствуют находкам Hacker House, два касаются дополнительных проблем, обнаруженных самой командой OpenWrt в процессе подготовки исправлений, и один правит опечатку в имени файла, не связанную с безопасностью. Две находки из отчёта Hacker House к моменту публикации PR уже были исправлены в master-ветке и в счёт девяти коммитов не вошли.
Среди конкретных изменений — устранение возможности обойти список разрешённых аргументов в luci-app-commands с помощью символа вертикальной черты (bare pipe), из-за чего команды выполнялись от root даже без сессионной куки и CSRF-токена, если параметры команды были публичными и параметризованными. В luci-app-ddns закрыты сразу две дыры: командная инъекция через настройку ddns_dateformat и path traversal через service_name — причём именно в процессе исправления этой части OpenWrt наткнулась на дополнительную хранимую XSS, изначально не входившую в отчёт Hacker House. В luci-proto-openvpn обнаружена инъекция shell-команд через параметр keytype и path traversal через параметры директории с ключами. Наконец, в luci-app-olsr вредоносный узел mesh-сети может объявить специально сформированное имя хоста, которое выполнится как скрипт в браузере администратора при просмотре списка соседних узлов.
Важная оговорка по поводу непроверенного пути в luci-app-commands: он срабатывает только если это дополнительное приложение вообще установлено на устройстве, и только если администратор сам, осознанно, настроил какую-то команду как публичную с параметрами — это не универсальная уязвимость, угрожающая каждому роутеру на OpenWrt. Но если условия выполнены, атака даёт выполнение команд с правами root.
Отдельный pull request, не связанный с LuCI напрямую, касается пакета ddns-scripts — там та же небезопасная настройка ddns_dateformat используется вне веб-интерфейса. Риск в том, что оператор с делегированными правами на настройку DDNS может подставить в значение параметра shell-синтаксис, который выполнится при следующем запуске обновления сервиса — в том числе после перезагрузки или переконфигурации. По состоянию на 28 июля этот PR тоже оставался открытым и не смёрженным.
Ещё две находки — path traversal с несанкционированным чтением файлов в luci-app-bmx7 и командная инъекция через ttyd_start в luci-app-dockerman — были уже исправлены в master-ветке LuCI, но, по подтверждению OpenWrt, всё ещё требуют бэкпорта в стабильные релизные ветки. С bmx7 вышла путаница: Hacker House включила эту находку в своё раскрытие от 8 июля, назвав её путём к полной компрометации устройства без аутентификации, тогда как публичный advisory OpenWrt описывает её более узко — как неавторизованный доступ к файлам, читаемым через CGI. Более того, в качестве репортёра там указана некая "nebusecurity", а не Hacker House, и в самой компании не знают, идёт ли речь о дублирующихся отчётах разных исследователей или же кредит был распределён ошибочно.
Отдельного внимания заслуживает то, как именно эти уязвимости искали. Hacker House описывает четырёхэтапный процесс, который они называют inference-fuzzing: сначала строится модель угроз, затем код многократно прогоняется через языковую модель для генерации широкого пула потенциальных проблем, после чего более точная модель отсеивает ложные срабатывания, и лишь затем исследователи вручную проверяют оставшееся — читают код и, где это практически возможно, тестируют поведение во время выполнения. На этапе поиска использовалась модель Qwen 3.6 35B Heretic, ориентированная на полноту охвата, для финальной триаж-фильтрации в открытых проектах применялась Claude Opus 4.6 от Anthropic, а для полностью офлайн-аудитов, где закрытый исходный код клиента не должен покидать его инфраструктуру, использовалась Qwen 3.5 115B. Подтверждение находок шло через ручной код-ревью и стандартные методы DAST (динамического тестирования безопасности приложений) там, где это было технически осуществимо; в отчёт попадали только подтверждённые уязвимости, хотя эксплойт-пейлоады иногда приходилось корректировать вручную уже на этапе проверки. Политика раскрытия у компании стандартная для индустрии: открытым проектам даётся 7–10 рабочих дней на подтверждение получения отчёта, после чего начинается совместная работа над сроками исправления; если ответа нет — компания оставляет за собой право опубликовать ограниченные детали, чтобы подтолкнуть к реакции.
Искусственный интеллект использовался и на стороне OpenWrt при подготовке исправлений — часть предложенных коммитов содержит служебную пометку «Assisted-by: Claude:claude-opus-5», а автоматический ревью в PR по LuCI прямо указывает, что был сгенерирован с помощью Claude Code. При этом финальную верификацию находок и качества патчей всё равно выполняли живые люди — исследователи и мейнтейнеры проекта.
Администраторам, использующим OpenWrt, стоит как можно скорее обновиться до 24.10.8 либо 25.12.5, отдельно проверить и при необходимости обновить пакеты, установленные вручную, пересмотреть делегированные права доступа к LuCI, удалить неиспользуемые дополнительные приложения и явно проверить, не настроена ли где-то команда в luci-app-commands одновременно как публичная и параметризованная. По состоянию на 28 июля оба открытых pull request — 8878 и патч для ddns-scripts — всё ещё не имели присвоенных идентификаторов CVE, оценок CVSS, полного перечня затронутых версий и номеров исправленных стабильных пакетов. Ни в одном из них не сообщается о зафиксированных случаях эксплуатации в реальных условиях. The Hacker News на момент публикации своего материала ожидало от команды OpenWrt ответа по поводу сопоставления с CVE, точного списка затронутых версий и текущего статуса патчей.