Проєкт 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, що призводить до stored XSS під час перегляду сторінки оренд у LuCI
- CVE-2026-62947: обхід шляху в cgi-io, що дозволяє читати довільні файли, доступні root. Потребує автентифікованої сесії з дозволом на завантаження й відповідним шаблоном доступу до файлів — це не анонімне читання файлів
Вразливості LuCI: патчі ще не прийняті
Паралельно з релізом компанія Hacker House опублікувала результати аудиту LuCI та uhttpd із застосуванням ШІ-асистованого фаззингу. Виявлено ін’єкцію команд, обхід шляху та XSS у необов’язкових компонентах LuCI. У процесі підготовки виправлень OpenWrt виявив додаткову stored XSS-вразливість і відсутність захисту від CSRF.
Ключові знахідки, за даними pull request #8878:
- luci-app-commands: символ конвеєра (pipe) обходив список дозволених аргументів, дозволяючи виконувати команди від root. OpenWrt встановив, що цей шлях працює без сесійного cookie та CSRF-токена, якщо адміністратор налаштував команду як одночасно публічну (public=1) і параметризовану (param=1)
- 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, робить вікно до початку активної експлуатації мінімальним. Оновлення прошивки слід виконати в найближчі години, а не дні.
