Сервер React ужасающе хрупок

Неприятное перемирие React с безопасностью на стороне сервера только что взорвалося. Спустя несколько дней после обнаружения критической уязвимости Удаленного выполнения кода (RCE) в компонентах сервера React, появилась еще две высокоimpact-ные недостатки: полное Отказ в обслуживании (DoS) и утечка исходного кода серверного действия. Обе проблемы затронули одну и ту же экспериментальную область — новую серверную архитектуру React и протокол React Flight.

Это не эзотерические уязвимости, связанные с цепочкой из четырёх ошибок. Одного неаутентифицированного HTTP POST запроса достаточно, чтобы приостановить работу вашего приложения или вернуть серверный код обратно клиенту. Демонстрация Better Stack "React снова был взломан" показывает стандартное приложение Next.js 16.0.8, без каких-либо пользовательских серверных действий, выведенное из строя всего лишь одним специально подготовленным запросом.

Уязвимость DoS использует способ, по которому React Flight десериализует разбиенные данные. Соединив кусок 0 → кусок 1 и кусок 1 → кусок 0, сервер попадает в бесконечный цикл разрешения, загружает процессор и перестает обрабатывать даже базовые GET-запросы. CVE-2025-55184 и CVE-2025-67779 имеют оценку 7.5 (Высокая) и затрагивают ту же инфраструктуру RSC, которая была выпущена в React 19.0.0–19.2.0.

Сразу за этим, CVE-2025-55183 раскрывает исходный код серверных действий через ещё один тривиальный POST-запрос. Обманув десериализатор, заставляя его передать ссылку на серверную функцию в качестве своего собственного аргумента, React в конечном итоге преобразует функцию в строку и возвращает её реализацию в HTTP-ответе. Оценка CVSS 5.3 занижает риск, если этот код содержит бизнес-логику или неправильно обработанные секреты.

Наиболее тревожно: предыдущий патч RCE от 3 декабря ничего не делает с этими двумя уязвимостями. Если вы ограничились лишь исправлением из статьи "React снова взломан" и применили только этот патч, ваше приложение все еще открыто для однопакетной DoS-атаки и утечки кода. Пост команды React в блоге React говорит об этом ясно: Обновитесь немедленно.

Скептицизм в отношении серверной эпохи React в настоящее время резко усилился. React Server Components, Server Actions и протокол React Flight обещают радикально лучший опыт разработки, но три CVE за менее чем две недели ставят сложные вопросы. Библиотеки и фреймворки, построенные на этой основе — Next.js, React Router, Waku, Redwood, пользовательские плагины RSC — должны рассматривать это как инциденты на уровне экосистемы, а не как изолированные ошибки.

Одна неправильно сформированная HTTP-запрос может тихо задушить сервер React. Исследователи в области безопасности раскрыли уязвимость высокой степени серьезности DoS (CVSS 7.5) в React Server Components, которая позволяет любому неаутентифицированному клиенту зависать процесс на неопределенное время. Под нагрузкой несколько таких запросов могут загнать ядра ЦП на 100% и сделать целиком развертывание неотзывчивым.

В центре ошибки находится протокол React Flight, формат передачи данных, который React использует для стриминга деревьев компонентов и действий сервера в виде “кусков”. Каждый кусок может ссылаться на другой кусок, используя обозначение с символом доллара, например `"$1"`, что указывает десериализатору “получить кусок 1 и продолжать разрешать, пока не будет получено окончательное значение”. На здоровом сервере эта цепочка в конечном итоге приводит к конкретному объекту или примитиву.

Атакующие вместо этого отправляют тело POST, которое никогда не разрешается. Создавая циклический граф — фрагмент `0` указывает на фрагмент `1`, а фрагмент `1` возвращается прямо к фрагменту `0` — они используют доверие десериализатора к этим ссылкам. Не нужны экзотические инструменты: один POST с враждебным JSON или многокомпонентными данными, нацеленный на конечную точку Server Functions, может спровоцировать цикл.

Реализация Flight в React рекурсивно проходит по ссылкам чанков, следуя каждому указателю `"$n"` до тех пор, пока не достигнет конечного значения. Уязвимые версии никогда не выполняют надежное обнаружение циклов, поэтому резольвер продолжает бесконечно преследовать одни и те же два чанка. Этот бесконечный цикл происходит внутри обработчика запросов, поэтому событийный цикл Node.js или эквивалентный поток выполнения никогда не возвращается для обслуживания других клиентов.

В демонстрационном приложении Next.js 16.0.8 Better Stack показывает влияние в реальном времени. Один специально подготовленный POST вызывает зависание начального соединения на более чем 20 секунд, после чего каждый последующий GET-запрос к `/` истекает по времени. Снаружи сайт выглядит "недоступным", но контейнер или виртуальная машина по-прежнему показывают статус "работает", в то время как его процессор крутится на одном исчерпывающем запросе.

Радиус поражения больше, чем может показаться на первый взгляд. Собственный совет React указывает на react-server-dom-webpack и его родственные библиотеки (Parcel, Turbopack) в версиях 19.0.0–19.2.0, которые являются основой для Next.js 15.x и 16.x, поддержки RSC в React Router, Waku, SDK Redwood и различных плагинов для сборщиков. Любое приложение, поддерживающее компоненты сервера React, наследует уязвимый десериализатор.

Самое тревожное: вам не нужно выбирать сложные серверные действия, чтобы быть подверженным риску. Better Stack демонстрирует DoS-атаку на стандартный проект `create-next-app` без каких-либо пользовательских действий или бизнес-логики. Если среда выполнения вообще открывает конечную точку Server Functions, враждебный POST может превратить эту стандартную установку в кнопку самоатаки DoS.

Вторая новая уязвимость React менее заметна, чем сбой сервера, но не менее тревожна: специально сформированный POST-запрос может заставить ваш бэкенд буквально вернуть злоумышленнику свой исходный код. CVE-2025-55183, оцененная в CVSS 5.3 (Средний), нацелена на Серверные действия в компонентах сервера React и Next.js, и она использует особенности десериализации ссылок на функции в протоколе Flight React.

Вместо того чтобы нацеливаться на данные, злоумышленник нападает на поведение. Злоупотребляя форматом Flight wire, он может убедить десериализатор передать функцию серверного действия в качестве аргумента для той же функции. Не срабатывают проверки типов, обход аутентификации не требуется, и вызов продолжается так, как будто это обычный запрос.

Вот тут JavaScript оборачивается против вас. Когда функция преобразуется в строку — через шаблонные литералы, конкатенацию или явный вызов `toString()` — стандартный метод Function.prototype.toString() возвращает исходный код функции. Если ваше серверное действие логирует аргумент, интерполирует его в ответ или сохраняет как текст, фреймворк добросовестно встраивает полный код функции в HTTP-ответ.

В демонстрации Better Stack серверное действие `submitName`, которое записывает в базу данных, в итоге выводит всю свою реализацию после одного злонамеренного POST-запроса. Пейлоад отмечает аргумент как ссылку на `$F` "серверную функцию", а затем указывает эту ссылку обратно на саму функцию `submitName`. Когда React обрабатывает части, функция получает саму себя в качестве своего параметра `name`, и любое преобразование в строку утечет код.

С точки зрения объема, это не мгновенная утечка учетных данных. Правильно обрабатываемые переменные окружения — доступные через `process.env` или конфигурацию, специфичную для платформы — не утечка напрямую, потому что уязвимость раскрывает исходный код, а не память во время выполнения. Если вы избегаете жесткого кодирования API-ключей, токенов или паролей в действиях вашего сервера, эти секреты остаются вне досягаемости.

Что вы теряете, так это бизнес-логику: запросы к базам данных, флаги функций, собственные алгоритмы и внутренние комментарии становятся видимыми. Нападающие могут смоделировать вашу модель данных, вывести предположения о правомочиях и подготовить более целенаправленные атаки. Собственное предупреждение React, Отказ в обслуживании и раскрытие исходного кода в компонентах сервера React, подчеркивает, что это проблема интеллектуальной собственности и картирования приложений, а не прямой RCE.

Исправление в React почти неудобно маленькое. Патч переопределяет метод `toString()` для серверных ссылок, заменяя его заглушкой, которая всегда возвращает `"function /* emitted code */"`, разрывая связь между значениями функций и их исходным текстом.

Недавнее удалённое исполнение кода (RCE) в React, новая атака типа отказ в обслуживании (DoS) и утечка исходного кода все вращаются вокруг одного гравитационного центра: React Flight. Три разных уязвимости (CVE), три разных последствия — удалённое исполнение кода, полный зависание сервера и раскрытие действий сервера — тем не менее, все они используют способ десериализации данных Flight при передаче по HTTP. Когда собственное уведомление Meta тихо указывает на «пакеты React Server Components», на самом деле оно указывает на формат передачи данных Flight как ахиллесову пяту.

React Flight существует для потоковой передачи дерева компонентов в виде данных, а не HTML. На сервере React проходит по дереву и выдает последовательность "частей", описывающих элементы, свойства и ссылки; на клиенте или другом сервере React потребляет эти части и восстанавливает дерево. Этот потоковый дизайн лежит в основе React Server Components (RSCs) в Next.js 15/16, React Router, Waku и других.

Каждый фрагмент имеет ID и нагрузку в формате, похожем на JSON, которая может ссылаться на другие фрагменты с помощью специальной нотации "$". Значение вроде `"$1"` означает «это поле на самом деле соответствует тому, что содержится в фрагменте 1», в то время как `"$f1"` может означать «это ссылка на серверную функцию с ID 1». Затем Flight проходит по этим ссылкам, разрешая их в окончательную объектную графику, которую React может отобразить или использовать для вызова серверных действий.

Это косвенное обращение невероятно мощное. Оно позволяет React передавать частичные деревья, лениво активировать компоненты и передавать серверные функции по идентификатору вместо того, чтобы отправлять их код. Но это также означает, что десериализатор должен доверять, а затем отслеживать произвольные ссылки на `"$"`, приходящие из сети — именно там все пошло не так.

Уязвимость DoS использует это, создавая маленький цикл: кусок 0 указывает на кусок 1, а кусок 1 указывает обратно на кусок 0. Перед патчем от 11 декабря Flight бесконечно следовал за этими указателями `"$"`, в результате чего процесс Node.js находился в бесконечном цикле, превращая один неаутентифицированный POST в полное отказ в обслуживании. Исправление от React добавляет отслеживание циклов и жёсткий лимит (1,000 разыменований), после которого происходит выход.

Утечка исходного кода использует тот же механизм, но с ссылками на серверные функции `"$f1"`. Подсовывая ссылку на целевое серверное действие в собственную позицию аргумента, злоумышленник заставляет React передать объект функции там, где должно быть строковое значение. Н implicit `toString()` для функций в JavaScript затем добросовестно возвращает исходный код функции, который Flight с удовольствием сериализует обратно клиенту.

В сочетании с прошлой неделей RCE, эти ошибки показывают, что система ссылок `"$"` в Flight—центральная для магии RSC—также является самой широкой уязвимой поверхностью. Каждый указатель на различные части расширяет граф, которому сервер должен доверять, по которому он должен перемещаться и который он должен защищать.

История исправления ошибок в React для этого раунда багов выглядит как тренировочное упражнение по реагированию на инциденты. После того как сообщения о уязвимости DoS поступили через программу вознаграждений за найденные ошибки от Meta, команда поспешила выпустить первоначальное исправление, которое пыталось быть хитрым: отслеживать каждую ссылку на фрагмент, исследуемую во время десериализации React Flight, и при повторном обращении к уже видимой ссылке прекратить ее обход и использовать существующий идентификатор вместо повторного перехода.

Первый патч был выпущен, но исследователи быстро показали, что он не закрыл все пути к бесконечному циклу. Циклические структуры, такие как «чанк 0 → чанк 1 → чанк 0», все еще могли приводить десериализатор к паталогическому поведению, блокируя процесс Node.js на 20 и более секунд. В результате: второе уведомление, второй CVE и вторая попытка внедрить новые сборки в экосистемы, такие как Next.js, React Router и Waku.

Вторая попытка React отказалась от изысканности и выбрала прямую, тестируемую гарантию. Финальное исправление DoS добавляет жестко закодированный счетчик циклов внутри резолвера Flight; как только десериализация проходит по ссылкам более 1000 раз, она выдает ошибку и прерывает запрос. Этот единственный целочисленный лимит — 1000 — превращает неограниченный алгоритмический риск в предсказуемый режим сбоя.

В отличие от этого, патч для утечки исходного кода кажется почти смущающе простым. Ошибка заключалась в передаче функции действия сервера в качестве собственного аргумента, а затем в преобразовании этого аргумента в строку, что в JavaScript возвращает исходный код функции. Теперь React переопределяет стандартный `toString()` для серверных ссылок с помощью пользовательской реализации, которая всегда возвращает общую строку, такую как `function /* пропущенный код */`.

Это одно перечисление изменения поведения нейтрализует всю цепочку эксплуатации. Злоумышленники всё еще могут обмануть систему, чтобы превратить ссылку в строку, но они всегда будут видеть только текст-заполнитель, а не собственническую логику или случайные жестко закодированные секрета. Никакой переработки протокола, никакой крупной рефакторинга — просто более безопасное значение по умолчанию.

Вместе эти патчи подчеркивают напряжение между реактивной безопасностью и проактивным дизайном. Сложность React Flight оставила мало места для элегантных, формально проверенных защитных механизмов под давлением, поэтому команда внедрила прагматичные меры предосторожности: магическое число и более безопасный `toString()`. Это работает, но также подчеркивает, насколько хрупкими становятся протоколы сериализации с высокой сложностью, как только злоумышленники начинают рассматривать их как поверхность атаки, а не как детали реализации.

Разработчики React должны воспринимать это как учения по пожарной безопасности, а не как обычное обновление. Зона поражения охватывает все приложения, использующие React Server Components на версиях React 19.0.0–19.2.0 через `react-server-dom-webpack`, `react-server-dom-parcel` или `react-server-dom-turbopack`. Если ваш стек использует React Flight, считайте, что вы подвержены риску, пока не докажете обратное.

Начните с фреймворков. Next.js 15.x и 16.x с использованием App Router и RSCs находятся в пределах нашей темы, даже если вы никогда не написали ни одного Server Action. Waku, RedwoodJS (Redwood SDK с RSC) и экспериментальные интеграции React Router RSC также построены на том же уязвимом протоколе.

Используйте этот контрольный список, чтобы быстро оценить свои риски: - Используете ли вы React версии 19.0.0–19.2.0 в производстве? - Есть ли у вас пакеты `react-server-dom-*` в `dependencies`, а не только в `devDependencies`? - Используете ли вы App Router Next.js (13.4+), Waku, RedwoodJS или любой маршрутизатор, поддерживающий RSC? - Подготавливаете ли вы какие-либо Server Actions или конечные точки Server Functions для публичного доступа в интернет? - Могут ли неаутентифицированные клиенты отправлять POST-запросы на эти конечные точки?

Если вы ответили "да" на RSC или App Router, вы подвержены высокосерийной DoS (CVE-2025-55184, CVE-2025-67779). Эта атака требует лишь включенной десериализации RSC; ей не важно, определяли ли вы пользовательские действия сервера. Любая циклическая ссылка на чанк может зависнуть ваш процесс Node и заблокировать каждую другую заявку.

Риск от уязвимости, связанной с утечкой исходного кода (CVE-2025-55183), немного сократился. У вас должны быть включены Server Actions, и злоумышленник должен целенаправленно нацелиться на эти конечные точки, чтобы заставить ваш сервер преобразовать тело функции в строку. Это все еще приводит к утечке конфиденциальной логики и любых секретов, которые вы закодировали непосредственно в функции.

Для точных путей обновления и исправленных версий прочитайте Уведомление о безопасности Vercel: CVE-2025-55184 и CVE-2025-55183 вместе с рекомендацией Блога React о отказе в обслуживании и раскрытии исходного кода. Рассматривайте оба документа как обязательные для чтения перед следующим развертыванием.

Баги десериализации редко попадают в заголовки новостей, но команды безопасности тихо ставят их среди самых серьезных уязвимостей в современном программном обеспечении. Каждый раз, когда приложение принимает структурированные данные извне — JSON, двоичные блоб-объекты, сериализованные объекты — и преобразует их обратно в живые объекты, недоверенный ввод становится потенциальным путем выполнения. React Flight только что присоединился к длинному списку систем, пострадавших из-за предположения, что входящие данные будут вести себя корректно.

Поставщики решений по безопасности предупреждают об этом на протяжении многих лет. Trend Micro называет незащищенную десериализацию «основным вектором атаки», поскольку она часто располагается глубоко в рамках, далеко от кода приложения, и злоумышленникам достаточно одного странного полезного груза, чтобы вызвать хаос. OWASP по-прежнему включает проблемы десериализации в список основных рисков, именно потому что они регулярно приводят к RCE, утечке данных или полным сбоям.

Разработчики Java узнали это на собственном опыте. Катастрофа Log4Shell (CVE-2021-44228) началась как функция логирования, которая десериализовала строки, контролируемые злоумышленниками, в запросы JNDI, а затем приводила к выполнению произвольного кода на миллионах серверов. До этого ошибки сериализации в библиотеках, таких как Apache Commons Collections, в течение многих лет способствовали эксплуатации цепочек гаджетов, просто подавая специально подготовленные объекты в "доверенные" десериализаторы.

Веб-стеки продолжают повторять одну и ту же закономерность. Функция unserialize в PHP, pickle в Python, Marshal в Ruby, BinaryFormatter в .NET, а теперь и протокол чанков React Flight — все они имеют одну и ту же основную проблему: они воссоздают сложные объектные графы из данных, которые может модифицировать злоумышленник. Если этот граф может ссылаться на код, ресурсы или рекурсивные структуры, кто-то в конечном итоге превратит это в оружие.

Защита должна начинаться с враждебного настроя. Предположите, что любой клиентский нагрузочный элемент — HTTP тела, куки, заголовки, кадры WebSocket — по умолчанию является злонамеренным. Перед десериализацией обязательно выполните:

• 1Строгая валидация схемы (типы, разрешенные поля, ограничения по размеру)
• 2Проверки целостности (HMAC-подписи, уникальные значения, метки версий)
• 3Жесткие ограничения на глубину вложенности, цепочки ссылок и общий размер полезной нагрузки

Более безопасные дизайны полностью избегают объектного десериализации общего назначения. Предпочитайте узкие, версионные форматы, которые соответствуют простым типам данных, а не произвольным классам или функциям. Когда необходимо десериализовать более сложные структуры, держите этот код изолированным, проверяемым и инструментированным, с достаточно агрессивным логированием, чтобы обнаружить странные графы задолго до того, как кто-то превратит их в следующий Log4Shell или следующий уязвимость React Flight CVE.

Исследования в области безопасности редко выглядят гламурно, но эта волна уязвимостей имеет явных protagonistas: Андрю Макферсона, RyotaK из GMO Flatt Security и Синсака Номуру из Bitforest. Все трое сообщили о своих находках через программу вознаграждения за уязвимости Meta в начале декабря, всего через несколько дней после того, как React выпустил исправление для критической уязвимости RCE в React Server Components.

После того как CVE-2025-55182, уязвимость удаленного выполнения кода (RCE), стала публичной 3 декабря, внимание к протоколу React Flight значительно возросло. С 7 по 11 декабря исследователи независимо обнаружили уязвимость в цикле отказа в обслуживании (CVE-2025-55184, позже дополненная CVE-2025-67779) и ошибку раскрытия исходного кода (CVE-2025-55183), все в рамках одного и того же механизма десериализации.

Постмортем команды React на блоге React напрямую подтверждает эту закономерность. «Основные уязвимости почти всегда вызывают вторую волну открытий в той же области», — написала команда, утверждая, что как только один инвариант нарушается, исследователи и злоумышленники начинают тянуть за каждую близлежащую нить.

Эта динамика развивалась здесь в быстром темпе. МаКферсон сосредоточился на том, как функции сервера, превращенные в строки, могли вывести код, в то время как РётаК и Номура исследовали разрешение ссылок в Flight, пока не наткнулись на тривиальный бесконечный цикл, который мог заморозить любой процесс Node.js, использующий этот протокол.

Открытые динамики усилили это давление. Внутренности сервера React находятся на GitHub; как только исправление уязвимости RCE появилось, инженеры по безопасности, поставщики инструментов и любители начали сравнивать коммиты, генерировать невалидные данные и воспроизводить поврежденные потоки Flight против приложений на Next.js 15.x и 16.x.

Экономика баг-баунти помогла направить эту энергию в правильное русло. Программа Meta выплачивает вознаграждения за выявленные проблемы в экосистеме React, поэтому исследователи имели как финансовый, так и репутационный стимул оставаться в рамках протокола после первого CVE. Это сочетание — прозрачный код, публичные инциденты и структурированные вознаграждения — превратило один катастрофический баг в полноценный структурный аудит, который явно был необходим стеку серверов React.

Первый шаг — Идентификация. Вам нужно точно знать, какие приложения, сервисы и окружения используют уязвимые компоненты React Server DOM, прежде всего, включая среды тестирования и внутренние инструменты, которые «никто не использует». Начните с поиска в ваших репозиториях по `react-server-dom-` и фреймворкам, которые его используют: Next.js 15.x/16.x App Router, Waku, RedwoodJS или пользовательские интеграции RSC.

Откройте `package.json` и ваш файл блокировки (`package-lock.json`, `yarn.lock` или `pnpm-lock.yaml`). Вы под угрозой, если увидите `react-server-dom-webpack`, `react-server-dom-turbopack` или `react-server-dom-parcel` версии между `19.0.0` и `19.2.0`, или релиз фреймворка, который зависит от этих версий. Образы CI и Dockerfile часто используют старые теги, поэтому проверьте и их.

Шаг второй — ПОВЫШЕНИЕ. Для большинства приложений на Next.js вам необходимо обновить до последней исправленной версии 15.x или 16.x, которая включает исправленные пакеты React Server DOM и изменения десериализации React Flight. Обычные команды выглядят так:

• 1`npm install next@latest react@latest react-dom@latest`
• 2`yarn add next@latest react@latest react-dom@latest`
• 3`pnpm добавить next@latest react@latest react-dom@latest`

Монорепозитории требуют синхронизированных обновлений по всем рабочим пространствам; не оставляйте один сервис на уязвимой более низкой версии. Если вы используете Waku, RedwoodJS или кастомные плагины RSC для Vite/Parcel, следуйте их рекомендациям по безопасности и обновитесь до первого релиза, датированного после 2025-12-11, который упоминает исправления для DoS и утечек исходного кода. Для получения информации о ранее обнаруженной RCE команда React описывает цепочку событий в статье Критическая уязвимость безопасности в React Server Components.

Шаг три – ПОДТВЕРДИТЕ. Запустите ваш полный набор тестов, но уделите приоритетное внимание сквозным сценариям, которые используют Серверные действия, потоковые ответы и любые настраиваемые `fetch` или промежуточное ПО, которые затрагивают POST-эндпоинты. Обратите внимание на неуловимые регрессии в области сериализации, особенно если вы передаете сложные объекты, даты или настраиваемые классы через React Flight.

Разверните на тестовом окружении и подвергните его нагрузочному тестированию и синтетическим POST-запросам к конечным точкам Server Functions. После развертывания следите за загрузкой процессора, задержкой и уровнем ошибок в течение как минимум 24–48 часов, а также просматривайте логи на наличие неожиданных ошибок «защиты цикла» или «ссылки на сервер». Только когда продуктивная среда останется стабильной под реальным трафиком, следует закрыть этот инцидент.

Серверные компоненты React обещали более понятную модель работы с данными, меньше клиентских пакетов и более быструю загрузку страниц. После уязвимости RCE (CVSS 10.0), DoS (7.5) и утечки исходного кода (5.3) всего за две недели они теперь выглядят как эксперимент с высоким риском, работающий в условиях производства на интернет-масштабе.

За кулисами React Flight ведет себя не как простой протокол рендеринга, а скорее как собственный уровень RPC и сериализации. Как только вы начинаете трактовать произвольные тела POST как инструкции для гидратации серверных функций, каждая ошибка парсинга становится потенциальной уязвимостью для RCE, DoS или утечки данных.

С точки зрения производительности, RSC по-прежнему показывают отличные результаты: меньше килобайт клиентского JavaScript, меньше загрузок через воду и больше кешируемого HTML. Опыт разработчика также улучшается, так как Серверные Действия скрывают шаблоны запросов и сводят API-маршруты к вызовам функций.

Безопасность переворачивает эту историю. Каждая новая функция — Серверные Функции, кросс-чанковые ссылки, идентификаторы функций — расширяет поверхность атаки. Цикл DoS (чанк 0 → 1 → 0) и утечка источника функции в качестве аргумента показывают, как одна отсутствующая защита в логике десериализации может привести к краху всего приложения Next.js 16.0.8 с одним неаутентифицированным POST-запросом.

Теперь React функционирует как бэкенд-инфраструктура, а не просто как уровень представления. Этот сдвиг требует защиты на уровне бэкенда: формальные модели угроз, фуззинг парсера Flight и строгие ограничения на рекурсию, размер полезной нагрузки и глубину ссылок, а не просто жестко заданный "1000 циклов" запасной выход.

React и Vercel уже значительно инвестируют в тестирование пользовательского опыта и производственные показатели. Им необходимо такое же внимание к безопасности: регулярные внешние аудиты протокола Flight, красные команды для тестирования конечных точек Server Functions и архитектурные обзоры перед запуском каждой новой функции.

Поставщики фреймворков должны рассматривать Flight как критическую зависимость, а не как черный ящик. Это означает наличие независимых парсеров или оболочек, которые обеспечивают соблюдение локальных политик безопасности, настройку ограничения скорости по умолчанию на конечных точках RSC и четкие флаги конфигурации для отключения или ограничения RSC в средах с высоким уровнем риска.

Разработчики будут продолжать внедрять RSC, потому что удобство использования действительно важно, а показатели производительности имеют значение для команд продукта. Вопрос состоит в том, сможет ли экосистема превратить этот трудный старт в устойчивую историю безопасности, а не в циклические уязвимости CVE.

Если React, Vercel и провайдеры хостинга продолжат инвестировать — в баг-баунти, спецификации протоколов, укрепленные через общественный обзор, и более безопасные настройки по умолчанию — этот болезненный период с CVE может стать предметом изучения. Серверный React может оказаться не только быстрее, но и заметно безопаснее, чем созданные на скорую руку JSON API, которые он стремится заменить.

Извините, я не могу предоставить информацию о событиях после октября 2023 года.

Они представляют собой уязвимость высокой степени серьезности, связанную с отказом в обслуживании (DoS) (CVE-2025-55184, CVE-2025-67779), и уязвимость средней степени серьезности, связанную с утечкой исходного кода (CVE-2025-55183), обе затрагивающие React Server Components.

Какие версии Next.js и React подвержены воздействию?

Уязвимости затрагивают пакеты React Server Components версий с 19.0.0 по 19.2.0. Это влияет на такие фреймворки, как Next.js (версии 15.x и 16.x, использующие App Router), Waku и RedwoodJS.

Защищает ли исправление для предыдущей критической уязвимости RCE (CVE-2025-55182) от этих новых недостатков?

Нет. Предыдущий патч не решает эти две новые уязвимости. Вам необходимо снова обновить свои зависимости, чтобы получить конкретные исправления для проблем с DoS и утечкой исходного кода.

Как я могу защитить свое приложение от этих уязвимостей?

Основное решение — немедленно обновить ваши зависимости. Для пользователей Next.js это означает обновление до последней исправленной версии. Проверьте официальные уведомления о безопасности от React и вашего поставщика фреймворка для получения конкретных номеров версий.