React выпустил исправления для CVE-2026-126187 - уязвимости в протоколе Flight, которую используют React Server Components. Ошибка позволяет удалённо выполнить код без аутентификации. Оценка CVSS 4.0 - 9.5.
Как работает атака
Проблема в том, как Flight передаёт бинарные данные. Если один ответ содержит несколько представлений одного ArrayBuffer, а один из них контролирует атакующий, писатель может отправить заголовок с длиной данных, но не отправить сами данные. Клиентский парсер доверяет заголовку и продолжает читать следующие строки как содержимое предыдущей. В результате в поток попадает строка, которая загружает модуль. Приложение исполняет её как часть своего бандла.
Звучит как редкая комбинация, и это действительно не универсальный эксплойт. Нужны несколько условий: несколько typed array в одном ответе, общий буфер, контролируемые байты и потребитель, который передаёт владение буфером. Но если условия совпали, код исполняется на сервере в SSR или edge-среде. Клиентские приложения без серверного рендеринга не затронуты.
Уязвимы пакеты react-server-dom-webpack, react-server-dom-parcel и react-server-dom-turbopack в ветках 19.0.0-19.0.8, 19.1.0-19.1.9, 19.2.0-19.2.8 и 19.3.0. Исправления вышли 10 ноября: 19.0.9, 19.1.10, 19.2.9 и 19.3.1. Обычно эти пакеты приходят транзитивно через Next.js, React Router или Vite, поэтому обновлять нужно фреймворк, а не только пакет в package.json.
До обновления можно снизить риск, если не передавать несколько представлений одного ArrayBuffer в RSC-ответах и копировать данные перед сериализацией. После обновления стоит проверить lockfile: если react-server-dom-* всё ещё ниже исправленной версии, приложение продолжает использовать уязвимый писатель. В логах стоит искать бинарные строки Flight с заявленной длиной, которой не хватает байтов, и сообщения о закрытии соединения после ответов с большими typed array.
Это уже вторая серьёзная ошибка Flight за год. В декабре 2025 React исправлял CVE-2025-55182 с оценкой 10.0. Разработчикам стоит относиться к обновлениям RSC-фреймворков как к security-релизам, даже если в приложении нет очевидной серверной логики.
Практическая проверка важнее чтения описания. Пакеты почти всегда приходят транзитивно, поэтому смотреть надо на то, что реально попало в сборку, а не на список зависимостей в package.json. Если lockfile показывает react-server-dom-webpack, react-server-dom-parcel или react-server-dom-turbopack ниже исправленной версии, приложение рендерит через уязвимый писатель. Обновление фреймворка обычно закрывает вопрос, но проверить разрешённую версию всё равно нужно.
Приоритет зависит от того, что именно работает на сервере. Публичный SSR или edge-рендеринг с пользовательскими данными в RSC-ответах - худший вариант. Внутренний инструмент без доступа извне рискует меньше, но и его стоит обновить, пока исправление свежее. Если обновление невозможно, помогает запрет на передачу нескольких представлений одного ArrayBuffer и копирование данных перед сериализацией. Это не полноценная замена патчу, но снижает вероятность срабатывания условий.
Отдельно стоит проверить CI и кэши зависимостей. Старый lockfile в кэше может вернуть уязвимую версию даже после обновления основного проекта. Для команд, которые собирают много репозиториев, полезен поиск по lockfile и по установленным пакетам на машинах разработчиков. В этом случае скорость важнее аккуратности: чем дольше живёт старая версия Flight, тем больше шансов, что кто-то соберёт с ней новый сервис.
Ссылки
- https://www.cve.org/CVERecord?id=CVE-2026-126187
- https://www.stepsecurity.io/blog/cve-2026-126187-react-flight-rce
