У декодері Brotli виявили вразливість із ризиком віддаленого виконання коду

У еталонному C-декодері Brotli виявили вразливість: спеціально підготовлені стиснені дані можуть призвести до віддаленого виконання коду. Як пише Broccoli2Shell, виправлені версії Brotli 1.0.10, 1.1.1 і 1.2.1 вийшли 21 жовтня 2026 року. Перевіряти потрібно не лише безпосереднє використання декодера: Node.js, бібліотеки Python та інші програми можуть розпаковувати Brotli без явного виклику в коді застосунку.

Як працює помилка і де виникає ризик

Помилка пов’язана з перемиканням між блоками потоку Brotli. Раніше декодер не завжди розрізняв некоректний потік і ситуацію, коли йому просто бракувало вхідних даних. На швидкому шляху результат однієї з перевірок узагалі ігнорувався. Підготовлений потік міг змусити декодер записувати дані за межами внутрішнього буфера розміром вісім байтів і пошкодити сусідні дані стану. Можливі наслідки — витік даних із пам’яті або виконання коду.

Вразливий C-декодер Brotli версій від 1.0.3 до 1.2.0, зокрема його копії всередині інших проєктів. Декодери, переписані іншими мовами, не дають змоги виконати код через цю помилку. Після виправлення обробка пошкодженого потоку припиняється з помилкою формату.

Один зі шляхів до вразливості — HTTP-відповіді. Вбудований fetch() у Node.js автоматично розпаковує відповіді з Content-Encoding: br. У Python це можуть робити requests через urllib3, aiohttp і httpx із доповненням для Brotli, якщо потрібний пакет установлено. Тому ризик виникає, наприклад, у застосунку, який отримує дані за зовнішньою URL-адресою. Інший шлях — стиснені тіла запитів: їх розпаковують певні обробники в Express 5.0.0–5.3.0 і body-parser 2.0.0–2.3.0. Сам по собі сервер на node:http цього не робить.

Express і body-parser не містять цієї помилки: оновлення лише цих пакетів її не усуне. Node.js постачається із власною копією Brotli, тож для нього важлива версія Node.js, а не системної бібліотеки. Застосунки також можуть звертатися до декодера безпосередньо — наприклад, під час роботи з архівами, кешами й повідомленнями з черг.

Які версії та копії перевірити

Для Node.js виправлення доступні у версіях 22.23.4, 24.22.1 і 26.12.1; гілки, підтримку яких завершено, теж уразливі. Для Python потрібні Brotli версії не нижче 1.2.1 і brotlicffi версії не нижче 1.2.1.0. Навіть якщо застосунок не імпортує ці пакети безпосередньо, вони можуть увімкнути підтримку Brotli в HTTP-клієнті. На момент розкриття вразливості pip-audit, Dependabot і Safety не завжди позначали вразливі версії пакетів у PyPI. Тому лише автоматичної перевірки залежностей недостатньо.

Окремо потрібно з’ясувати, звідки програма отримує C-декодер. Для динамічно підключеної системної бібліотеки важливо встановити виправлення з оновлень дистрибутива й перезапустити процес. Вбудовані та статично скомпільовані копії потребують оновлення самого проєкту й нового складання. Серед проєктів із такими копіями названі DuckDB, Apache Arrow і p7zip. Для деяких інших проєктів виправлення вже внесли до гілок розробки, але вони ще не потрапили до релізів. Оновлення системного libbrotli не захистить вбудовані копії.

Що це означає для сайтів і застосунків

Насамперед розробникам варто перевірити сервіси, які завантажують дані за сторонніми URL-адресами або приймають тіла запитів із Content-Encoding: br. Це стосується не лише робочого сервера: у матеріалі окремо названі тестові середовища, контейнерні образи, CI та безсерверні середовища. Після оновлення потрібно перескласти образи, перезапустити процеси й оновити зафіксовані версії залежностей, інакше наступне складання може повернути вразливий пакет. Ризик під час завантаження даних із зовнішніх адрес пов’язаний і з автоматичним розпакуванням у HTTP-клієнтах, а не лише з обробкою вхідних запитів.

Якщо оновитися одразу не можна, для Python запропоновано тимчасовий варіант — видалити Brotli і brotlicffi разом із доповненнями, які встановлять їх знову. Для вхідних запитів можна відхиляти тіла з Content-Encoding: br на проксі або WAF. Але видалення br із вихідного Accept-Encoding не забезпечує повного захисту: сервер, до якого звертається застосунок, усе одно може надіслати таку відповідь. Для Node.js повноцінний спосіб усунути проблему — оновити середовище виконання.

Дослідники Imperva домоглися виконання коду на стандартному образі Node.js 24.22.0 для Linux arm64, передавши дані як через завантажену відповідь, так і через тіло запиту Express. Опублікований 22 жовтня приклад експлуатації, за описом матеріалу, дає змогу виконати код лише на спеціально послабленому складанні. Станом на 22 жовтня повідомлень про атаки в реальних системах не було.

Моя думка

Я б почала з перевірки версій середовища й залежностей в образі, який справді запущено, а не лише у файлах проєкту. Тут легко не помітити автоматичне розпакування відповіді: у коді видно звичайний запит за URL-адресою, а шлях до декодера з’являється через установлений пакет.

Для мене це ще й нагадування, що оновлення бібліотеки на машині й оновлення застосунку — різні завдання. Якщо декодер вбудовано у складання, виправлення має потрапити саме до нього.

Джерела

Звідки новина. Текст — переказ своїми словами, факти — з джерела, думка — автора.

1. Broccoli2Shell: Brotli decoder RCE in Node.js, Python and more broccoli2shell.com

Про автора

Елізе Еверс

початківчиня frontend-розробниця

Вивчаю HTML, CSS і JavaScript на вечірніх курсах. Для практики відтворюю невеликі сторінки й записую, де гублюся в документації.

Усі публікації автора