Новые уязвимости React: обновитесь или столкнетесь с остановкой работы

Разработчики React только что закончили гонку по исправлению критической уязвимости удаленного выполнения кода и теперь находятся в режиме повышенной готовности. Уязвимость React2Shell, зарегистрированная под номером CVE-2025-55182, ошеломила экосистему неаутентифицированным удаленным выполнением кода в настройках по умолчанию для React Server Components и почти 100% надежностью эксплуатации. Злоумышленники действовали быстро, разместив модули Cobalt Strike, криптомайнеры и RAT, такие как EtherRAT и Noodle RAT, как только уязвимость стала известна.

Патчи для React2Shell вышли 3 декабря 2025 года, и команды начали спешно обновлять версии во всех Next.js, Node.js бэкендах и кастомных серверах на React. Многие компании рассматривали это как инцидент «всё бросить», приоритизируя обновления зависимостей перед разработкой новых функций. На короткий момент казалось, что худшее уже позади.

Через несколько дней вышло продолжение. В то время как исследователи и команда React изучали оригинальное исправление, они обнаружили две новые уязвимости в том же протоколе React Server Components «Flight». Эти открытия теперь имеют идентификаторы CVE-2025-55183, CVE-2025-55184 и связанный внутренний случай CVE-2025-67779.

Оба новых выпуска нацелены на один и тот же класс целей: пакеты React 19.x, такие как react-server-dom-webpack версии 19.0.0–19.2.0, и фреймворки, которые по умолчанию интегрируют RSC. В этот список входят: - Next.js - react-router - Waku - @parcel/rsc - @vitejs/plugin-rsc - RWSdk

Команды безопасности теперь сталкиваются с быстрым циклом обновлений. Сначала критическая уязвимость RCE вынудила экстренные обновления. Теперь, всего через неделю, организациям необходимо провести еще один раунд обновления зависимостей, повторно протестировать производственные сборки и снова развернуть их.

Эти новые уязвимости не позволяют выполнять удаленный код, но все же классифицируются как серьезные. Одна уязвимость DoS, оцененная как высокая (CVSS 7.5), позволяет нападающему отправить один POST-запрос, который запускает бесконечный цикл на сервере React, блокируя весь другой трафик. Доступность падает до нуля, пока процесс выполняется.

Второй недостаток раскрывает исходный код серверных действий через еще один тривиальный POST-запрос. Степень серьезности попадает в категорию "средняя", но любые захардкоженные секреты, токены или учетные данные базы данных внутри этих действий становятся мгновенной добычей. Для неправильно настроенных приложений "средняя" угроза может перерасти в катастрофическую.

Второй новый эксплойт React затрагивает доступность, а не выполнение кода. CVE-2025-55183 — это уязвимость высокой степени серьезности Отказ в обслуживании в компонентах сервера React, оцененная на CVSS 7.5. Нет доступа к оболочке, нет кражи данных — просто мёртвое приложение, которое перестает реагировать.

Злоумышленникам не нужны учетные данные, специальная инфраструктура или хитроумное тайминг. Один неаутентифицированный POST запрос к RSC эндпоинту достаточно, чтобы запустить бесконечный цикл внутри сервера React. После этого процесс крутится вечно, потребляя процессорные циклы, пока каждый новый запрос ждет в очереди, пока вся служба фактически не зависнет.

При нагрузке такое поведение эскалирует от раздражающего до катастрофического. Поскольку цикл выполняется внутри главного процесса сервера React, он монополизирует цикл событий и лишает ресурсов все остальные обработчики. Новые HTTP-запросы накапливаются, время обработки истекает, и пользователи видят пустые страницы, неудачные API-вызовы или ошибки 500 на уровне фреймворка.

Для современных стеков React это означает, что любое приложение, использующее компоненты сервера React, подвержено риску: Next.js, пользовательские настройки RSC с react-server-dom-webpack и экспериментальные маршрутизаторы, поддерживающие RSC. Если ваш деплой маршрутизирует трафик через небольшую группу рабочих процессов Node.js, одна тщательно подготовленная POST-запись для каждого рабочего процесса может вывести из строя всю группу. Горизонтальное масштабирование помогает лишь до тех пор, пока злоумышленники не уравняют количество ваших экземпляров.

Исследователи Рёта К. из GMO Flatt Security и Шинсаку Номура из Bitforest обнаружили и сообщили о баге, который позже был зафиксирован как CVE-2025-67779. Их работа демонстрирует, насколько хрупок всё еще поток данных "Flight" в React Server Components при обработке непроверенного ввода. Под слоем JSX, RSC полагается на специальный потоковый протокол, который никогда не был защищен так, как традиционная API-поверхность.

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

В совокупности с инцидентом React2Shell на прошлой неделе, CVE-2025-55183 подчеркивает тенденцию: внутренности сервера React теперь находятся в непосредственном радиусе риска безопасности. Любое приложение, которое рассматривает RSC конечные точки как "просто сантехнические детали фреймворка" и оставляет их открытыми для публичного интернета, по умолчанию наследует этот риск.

Средняя серьезность кажется обнадеживающей, пока ваш сервер не начинает раздавать свои собственные схемы. CVE-2025-55184 снова нацеливается на React Server Components, на этот раз злоупотребляя тем же протоколом Flight, чтобы приоткрыть завесу серверных действий. Никаких цепочек XSS, никаких гимнастик с SSRF — просто еще один неаутентифицированный POST-запрос к стандартной конфигурации React 19.x.

Под капотом проблема заключается в том, как React десериализует и реагирует на специально подготовленные полезные нагрузки Flight. Злоумышленник может попросить сервер сериализовать серверное действие таким образом, чтобы вернуть его исходный код вместо просто вывода. Собственное предупреждение React, Отказ в обслуживании и раскрытие исходного кода в компонентах сервера React, подтверждает, что это работает против пакетов, таких как react-server-dom-webpack версии 19.0.0–19.2.0 и фреймворков, которые их встраивают.

На первый взгляд, утечка исходного кода кажется менее драматичной, чем RCE или уязвимость DoS с CVSS 7.5. Но действия сервера часто служат свалкой для секретов, особенно в спешке или устаревших кодовых базах. Как только злоумышленник может прочитать этот код, все, что вы захранили в нем, становится добычей.

Хардкодированные секреты часто включают: - API ключи для сторонних сервисов (Stripe, Twilio, SendGrid) - Имена пользователей и пароли баз данных - Секреты подписи JWT или клиентские секреты OAuth - Эндпоинты внутренних сервисов и токены доступа

Эта уязвимость особенно наказывает команды, которые рассматривали код на стороне сервера как безопасный хранилище. Лучшая практика подразумевает, что секреты хранятся в переменных окружения, менеджерах секретов или защищённых хранилищах KMS, а не встроены в функции. CVE-2025-55184 превращает каждое нарушение этих рекомендаций в прямой вектор утечки данных.

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

Последний скандал с безопасностью React сводится к одному месту: React Server Components и их странному протоколу передачи данных "Flight". RSC позволяют приложениям рендерить компоненты на сервере и передавать сериализованные UI "полезные нагрузки" в браузер, который восстанавливает их обратно в живые компоненты. Flight — это собственный формат сериализации, который преобразует древовидные структуры компонентов, пропсы и серверные действия в поток байтов, который React может восстановить на другом конце.

Этот этап реконструкции — именно то место, где всё идет наперекосяк. Flight должен десериализовать всё, что отправляет клиент, и в затронутых версиях React рассматривал части этого полезного груза как в основном надежные. Исходная ошибка React2Shell (CVE-2025-55182) показала, как данные Flight, контролируемые злоумышленником, могут привести к полной удалённой выполнению кода, с почти 100%-ной надежностью против непатченных серверов.

Новые Уязвимости CVE—CVE-2025-55183 (DoS, CVSS 7.5) и CVE-2025-55184 (утечка исходного кода)—затрагивают одну и ту же уязвимость: небезопасная десериализация ненадежного ввода. Вместо того чтобы открывать оболочку, подготовленные полезные нагрузки Flight теперь заставляют среду выполнения RSC входить в бесконечный цикл или обманывают её, заставляя повторно выводить исходный код действий сервера. Разные последствия, одна и та же корневая причина: React бесконтрольно обрабатывает враждебные данные, отправленные по протоколу, который никогда не предназначался для открытого интернета.

Исследователи безопасности любят такую поверхность, потому что она как сложная, так и повсеместная. Полет манипулирует: - Ссылками на компоненты - Идентификаторами действий сервера - Произвольными сериализованными значениями и "токенами"

Каждый из этих элементов является потенциальным гаджетом для цепочки эксплуатации. Добавьте к этому тот факт, что RSC внедряются в популярные стеки, такие как Next.js, react-router, Waku и @vitejs/plugin-rsc, и любая ошибка в Flight мгновенно приобретает масштаб интернет-проблемы.

Злоумышленникам не требуется сложная инфраструктура для ее злоупотребления. Один неаутентифицированный POST-запрос к RSC-эндпоинту в приложении Next.js по умолчанию — без дополнительного промежуточного ПО, без пользовательских маршрутов — может доставить вредоносный полезный нагрузку Flight. Для CVE-2025-55183 эта полезная нагрузка заставляет серверный рендеринг React входить в бесконечный цикл, блокируя процессор и не позволяя обработать другие запросы, пока процесс не завершится аварийно или хост не убьет его.

CVE-2025-55184 менее заметен, но гораздо опаснее для неаккуратных кодовых баз. Другой специально подготовленный POST может заставить сервер вернуть исходный код серверного действия, раскрывая хардкодированные API-ключи, пароли от баз данных или внутреннюю логику. Так как фреймворки автоматически связывали эти конечные точки, многие команды развернули RSC, полагая, что "умолчание фреймворка" означает "безопасно", только чтобы обнаружить, что их уровень сериализации стал высокоценной, не требующей аутентификации поверхностью атаки.

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

Злобный запрос на уязвимость DoS (CVE-2025-55183, CVSS 7.5) может выглядеть почти оскорбительно просто. Концептуально это всего лишь:

```http POST /react?on_server_action=1 HTTP/1.1 Host: yourapp.com Content-Type: application/json ```

{"actionId":"loop","args":[{"$type":"flight","payload":"{}"}]}

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

Автоматизация делает это еще хуже. Простой скрипт на Python или бот на Node.js может просканировать диапазоны IP на наличие открытых RSC-эндпоинтов и отправлять этот POST-запрос на тысячи целей в минуту. Коммерческие ботнеты могут легко добавить это в свои схемы, так же как они когда-то добавляли проверки на Shellshock или Heartbleed.

Малоопытные атакующие получают наибольшую выгоду. Тот, кто не может написать ни одного компонента React, все равно может запустить PoC на GitHub, подставить новый URL и начать атаковать серверы. Для уязвимости с раскрытием исходного кода (CVE-2025-55184) тот же скрипт может переключиться на немного другую полезную нагрузку, которая выводит исходный код серверного действия прямо в тело ответа.

Сравните это с типичной цепочкой RCE или эксплойтом SSRF. Они часто требуют глубокого понимания архитектуры памяти, цепочек гаджетов, облачных метаданных или внутренней сетевой архитектуры. Они легче ломаются, требуют настройки под каждую цель и часто вызывают тревогу во время разведки.

Здесь успех выглядит почти бинарно: если ваш стек использует уязвимые версии react-server-dom-webpack (19.0.0–19.2.0) или такие фреймворки, как Next.js с включенным RSC, стандартный POST просто работает. Никаких флагов функций, никаких неправильных конфигураций, никакого социального инжиниринга.

Этот низкий барьер для входа изменяет расчет рисков. Уязвимости, которые так легко использовать в качестве оружия, быстро обнаруживаются в массовых сканированиях, руководствах по программам-вымогателям и кампаниях типа "бросай и надейся". Разработчики, которые рассматривают их как «просто» DoS или «только» риск раскрытия исходного кода, могут узнать на собственном опыте, что именно простота делает их катастрофическими.

Стэки React, которые используют React Server Components, по умолчанию находятся в зоне риска. Самая важная проблема — это версии react-server-dom-webpack от 19.0.0 до 19.2.0, которые содержат все три ошибки: первоначальную уязвимость RCE, а также новые уязвимости CVSS 7.5 DoS и утечку исходного кода. Если этот пакет присутствует в вашем дереве зависимостей в указанном диапазоне, вы подвержены риску.

Основные фреймворки уже признали влияние. Next.js, Waku, @parcel/rsc, @vitejs/plugin-rsc и несколько пользовательских RSC-рантаймов все полагаются на одну и ту же реализацию протокола Flight. Официальное уведомление Vercel по Next.js, Безопасный бюллетень: CVE-2025-55184 и CVE-2025-55183, отслеживает, какие версии Next.js и React вы должны использовать.

Чтобы быстро проверить проект Node, ищите в вашем lock-файле, а не доверяйте package.json. В проектах npm откройте package-lock.json и ищите:

• 1"react-server-dom-webpack"
• 2поля версий между "19.0.0" и "19.2.0"
• 3любые вложенные зависимости, которые косвенно затягивают эти версии

Пользователи Yarn должны сделать то же самое в файле yarn.lock. Используйте текстовый поиск по "react-server-dom-webpack@19." и подтвердите, что разрешенная версия не ниже 19.2.1 или какой бы ни была указана исправленная версия вашего фреймворка. Если существует несколько записей, каждая уязвимая должна быть обновлена.

Монорепозитории и рабочие пространства усложняют ситуацию. Каждое приложение или пакет могут использовать разные версии React и инструменты RSC, поэтому необходимо просматривать каждый package-lock.json или yarn.lock в папках apps/, packages/ и examples/. CI-образы и Dockerfile, которые содержат node_modules, должны быть пересобраны после обновления зависимостей.

Если вы запускаете Next.js на управляемой платформе, такой как Vercel, проверьте как версии ваших пакетов, так и страницу статуса вашего провайдера. Поставщики фреймворков откатывают патчи, но это ничего не значит, если ваш lockfile по-прежнему удерживает вас на уязвимой реализации Flight.

История безопасности React в декабре напоминает спринт под огнем. 3 декабря Meta выпустила экстренное исправление для CVE-2025-55182, уязвимости удаленного выполнения кода “React2Shell”, которая превращала неаутентифицированные POST-запросы в почти 100% надежное RCE на инфраструктуре React Server Components. В течение нескольких дней исследователи и команда React снова вернулись к коду, проверяя те же пути протокола Flight, которые только что были укреплены.

К 7 декабря у техников были прототипы новых исправлений, которые адресовали еще две ошибки, выявленные во время постмортем-тестирования: проблема с высокой степенью серьезности DoS (CVE-2025-55183, CVSS 7.5) и ошибка средней степени серьезности, связанная с утечкой исходного кода (CVE-2025-55184), а также связанный внутренний случай CVE-2025-67779. 8 декабря началась тихая, но агрессивная фаза координации, в которую были вовлечены основные хостинг-провайдеры и авторы фреймворков в частные каналы, прежде чем какие-либо релизы npm стали доступными.

Этот этап координации имел значение. Платформы, такие как Vercel, а также разработчики Next.js, react-router, Waku, @parcel/rsc, @vitejs/plugin-rsc и RWSdk получили ранние технические детали, чтобы они могли выпустить меры по смягчению последствий или экстренные обновления до публичного раскрытия. К 10 декабря большинство крупных хостов уже внедрили фильтры и обновили образы, чтобы ослабить тривиальные атаки на основе POST против RSC конечных точек.

Публичные патчи были выпущены 11 декабря, когда обновленные версии react-server-dom-webpack и связанных пакетов React 19.x появились в npm с улучшенной сериализацией Flight и более строгой обработкой серверных действий. В тот же день команда React опубликовала уведомление, в котором были подробно изложены CVE-2025-55183, CVE-2025-55184 и CVE-2025-67779, подчеркивая, что новая уязвимость RCE не была повторно введена и что исправление React2Shell по-прежнему актуально.

Охотники за уязвимостями сыграли значительную роль в сжатии этого временного отрезка. Исходный отчет Лаклан Давидсона о RCE 29 ноября стал причиной выхода исправления 3 декабря, а последующие проблемы были выявлены Ретой К. (GMO Flatt Security), Синсаку Номурой (Bitforest) и Эндрю МаКферсоном (AndrewMohawk), все они работали через систему баг-баунти Meta. Этот стабильный поток оплаченных отчетов превратил то, что могло стать катастрофой в замедленном действии, в бурную, но контролируемую неделю исправлений, вместо того чтобы превратиться в месяцы хаоса с нулевыми днями.

Приложения React, использующие серверные компоненты, требуют быстрого трехступенчатого процесса блокировки: обновление, проверка, затем аудит. Уязвимости CVE-2025-55183 (DoS, CVSS 7.5) и CVE-2025-55184 (утечка исходных данных) затрагивают протокол Flight, и никакие хитрые сетевые решения не спасут вас, если ваши зависимости останутся устаревшими.

Начните с обновлений. Для большинства проектов это означает переход на исправленную версию React 19 и последнюю версию безопасности вашего фреймворка. В npm выполните: - `npm install react@latest react-dom@latest react-server-dom-webpack@latest --save` - Для Next.js: `npm install next@latest --save`

Пользователи Yarn должны зеркалить эти обновления: - `yarn add react@latest react-dom@latest react-server-dom-webpack@latest` - `yarn add next@latest` Фреймворки, построенные на компонентах сервера React, такие как Next.js, Waku, `@parcel/rsc`, `@vitejs/plugin-rsc` и RWSdk, предоставляют свою собственную обработку Flight, поэтому вы должны отслеживать и устанавливать каждую выпущенную версию с советами по безопасности для каждого проекта, а не только для основного React.

Следующим шагом будет проверка. Обновление без подтверждения версий оставляет вас в неведении, находятся ли CVE-2025-55183 и CVE-2025-55184 в вашем дереве. Используйте: - `npm ls react react-dom react-server-dom-webpack next` - или `yarn why react react-dom react-server-dom-webpack next` чтобы подтвердить, что каждая разрешенная версия соответствует исправленным версиям, объявленным на страницах безопасности React и Next.js.

Обратите внимание на вложенные зависимости. Монорепозитории и старые lock-файлы часто закрепляют уязвимые версии `react-server-dom-webpack` (19.0.0–19.2.0), даже после обновления на верхнем уровне. Повторно создайте lock-файлы с помощью команд `rm package-lock.json && npm install` или `rm yarn.lock && yarn install`, если дерево все еще показывает сборки до исправления.

Защита в глубину означает, что вы должны предположить, что CVE-2025-55184 уже скомпрометировал ваш код. Проведите быструю проверку на наличие захардкоженных секретов в действиях сервера и обработчиках RSC: - `git grep -i "api_key\|apikey\|secret\|token\|password"` - просканируйте резервные `.env` файлы и "временные" встроенные учетные данные - проверьте логи и вспомогательные средства отладки, которые выводят содержимое запросов или конфигурацию

Поворачивайте все, что хоть немного чувствительно: пароли к базам данных, ключи API третьих сторон, ключи подписи JWT, секреты клиентов OAuth и токены внутреннего сервиса. Если атакующие один раз получили доступ к вашему исходному коду, эти секреты останутся действительными до тех пор, пока вы их не аннулируете.

Крупные хостинг-провайдеры, такие как Vercel, уже внедрили сетевые меры для смягчения неаутентифицированного злоупотребления Flight. Эти фильтры дают время, но не исправляют ваше приложение; одна неправильно настроенная прокси, самостоятелльный развертывание или будущая уязвимость могут снова вернуть вас в рулетку RCE и DoS. Только обновлённые зависимости действительно закрывают эти новые уязвимости React.

Неделя ада для React ставит трудный вопрос: можно ли доверять Серверным Компонентам в масштабах, или же экосистема выпустила недоделанный бэкенд-рантайм в продакшн? Три уязвимости (CVE) менее чем за две недели, все использующие один и тот же протокол Flight, наводят на мысль, что это больше, чем просто разовая ошибка. Похоже, это системная проблема проектирования в том, как React обрабатывает сериализованные данные из сети.

React Server Components обещали чистое разделение между клиентом и сервером, но на практике они превратили React в фреймворк серверного приложения. Как только вы принимаете POST-запросы, десериализуете сложные полезные нагрузки и выполняете Серверные действия, вы больше не являетесь «просто фронтендом». Вы становитесь бэкендом, открытым для сети, с теми рисками безопасности, которые это предполагает.

Эти рядовые уязвимости поднимают неудобные вопросы о зрелости RSC. CVE-2025-55182 предоставил неаутентифицированный RCE, в то время как CVE-2025-55183 и CVE-2025-55184 продолжили с CVSS 7.5 для DoS и раскрытия исходного кода, все доступные через тривиальные POST-запросы. Эта схема больше похожа не на несчастный случай, а на модель безопасности, которая никогда не проходила должного противостоящего обзора.

Рост все еще описывает часть истории. RSC находятся на переднем крае, интегрированы с Next.js, react-router, Waku, @parcel/rsc, @vitejs/plugin-rsc и многими другими, все двигается быстро. Когда протокол, такой как Flight, лежит в основе нескольких фреймворков, единственный дефект десериализации мгновенно превращается в инцидент на уровне всего экосистемы.

Команды безопасности предупреждали, что это произойдет. Unit 42 уже отслеживает активное использование уязвимости CVE-2025-55182, включая маячки Cobalt Strike, кражу учетных данных в облаке и загрузки криптомайнинга. Wiz обозначил React2Shell как "критическую" именно потому, что настройки по умолчанию подвергали производственные приложения риску без какого-либо подтверждения.

Фронтенд-разработчики теперь берут на себя обязанности, которые раньше принадлежали бэкенд- и платформенным командам. Обработка секретов в Server Actions, валидация входных данных, применение ограничений по скорости и сегментация сетевого доступа больше не могут считаться «проблемами эксплуатации». Если ваше React-приложение общается напрямую с базами данных, очередями и внутренними API, вы пишете бэкенд-код, независимо от своей должности.

Разработка с приоритетом на безопасность должна смещаться влево в сам инструментальный набор React. Это означает: - Моделирование угроз для новых возможностей фреймворка - Обязательные настройки по умолчанию с обеспечением безопасности - Агрессивное тестирование протоколов, таких как Flight - Первоклассная поддержка управления секретами и политиками

Ожидайте увеличения внимания злоумышленников к современным фреймворкам. Unit 42 и Wiz отмечают тренд: эксплойты теперь нацелены на структурированные стеки — React, Next.js, Nuxt, Remix — потому что одна ошибка открывает доступ к тысячам приложений. Для более глубокого анализа цепочки DoS и утечки исходного кода, статья Aikido о Уязвимости DoS в React & Next.js (CVE-2025-55184): Что вам нужно исправить после React2Shell показывает, как быстро эти проблемы распространяются среди провайдеров.

Разработчики React только что прошли экспресс-курс по современному управлению рисками в вебе: предполагайте компрометацию,Patch мгновенно и никогда не доверяйте своим абстракциям. Три CVE менее чем за две недели — CVE-2025-55182, CVE-2025-55183 и CVE-2025-55184 — показывают, как быстро популярный фреймворк может стать вектором атаки. Рассматривайте каждое обновление React, особенно касающиеся React Server Components, в первую очередь как релиз безопасности, а во вторую как релиз функций.

Это означает, что "обновление по возможности" больше не актуально. Если вы используете React 19.x с react-server-dom-webpack 19.0.0–19.2.0 или такие фреймворки, как Next.js, react-router, Waku, @parcel/rsc, @vitejs/plugin-rsc или RWSdk, вам нужно срочно установить патчи или принимать на себя риски RCE, CVSS 7.5 DoS и утечек исходного кода как бизнес-решение. CI-пайплайны должны останавливать сборки на устаревших версиях безопасности, а не только на устаревших конфигурациях TypeScript.

Одноразовые обновления не являются стратегией. Каждая команда React должна подписаться на уведомления о безопасности для: - React и react-server-dom-webpack (уведомления npm + Уведомления о безопасности GitHub) - Вашего основного фреймворка (Next.js, Remix и др.) - Вашего хостинг-провайдера или PaaS (Vercel, Netlify, Cloudflare, AWS Amplify)

Списки рассылки по безопасности и RSS-каналы звучат устарело, пока «простой POST-запрос» не выведет ваше приложение из строя. Настройте оповещения в GitHub Dependabot, Snyk или Renovate, чтобы уязвимости, такие как CVE-2025-55182, не стали неожиданным потоком сообщений в Twitter. Рассматривайте обновления зависимостей как часть спринта, а не побочные задачи.

Даже после этих патчей хрупкое ядро остаётся: десериализация недоверенных данных по протоколу Flight. Любая система, которая декодирует сложные, вложенные объекты из сети — RSC, RPC на основе JSON, GraphQL — находится в месте атаки, которое нравится злоумышленникам. Более безопасные кодировки, строгие схемы и жесткая проверка ввода должны быть требованиями дизайна, а не запоздалыми мыслями.

Фронтенд-стеки теперь выполняют серверный код, обрабатывают секреты и orchestrate инфраструктуру. Месяц уязвимостей React напоминает, что «безопасность фронтенда» – это всего лишь безопасность веба — и веб становится надежным только тогда, когда код пользовательского интерфейса получает такую же паранойю, которая раньше распространялась только на базы данных и системы аутентификации.

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

Две новые уязвимости затрагивают компоненты сервера React. Первая (CVE-2025-55183, высокая степень серьезности) представляет собой атаку типа "отказ в обслуживании" (DoS), которая вызывает бесконечный цикл. Вторая (CVE-2025-55184, средняя степень серьезности) позволяет злоумышленникам просматривать исходный код ваших серверных действий.

Какие версии React и Next.js подвержены риску?

Уязвимости затрагивают пакеты React, такие как `react-server-dom-webpack`, версии с 19.0.0 до 19.2.0. Фреймворки, использующие компоненты серверной части React, в частности Next.js, находятся под угрозой. Пользователям настоятельно рекомендуется немедленно обновить до последних исправленных версий.

Как мне устранить эти уязвимости в React?

Основное решение заключается в обновлении ваших зависимостей React, в частности пакетов, связанных с компонентами серверной части React, до последних версий, выпущенных 11 декабря 2025 года или позже. Vercel также внедрила меры по смягчению последствий для пользователей Next.js на своей платформе.

Связаны ли эти новые уязвимости с предыдущей уязвимостью RCE (React2Shell)?

Да, они были обнаружены исследователями безопасности во время тестирования патчей для оригинального уязвимости RCE (CVE-2025-55182). Они используют аналогичный вектор атаки через протокол 'Flight', но не повторно внедряют риск удаленного выполнения кода.