Отдельный риск: уже есть публичные PoC-эксплойты, массовое сканирование началось буквально в первые сутки после публикации advisory, а крупные облака (AWS, Google Cloud и др.) фиксируют реальные попытки эксплуатации со стороны группировок, в том числе связанных с государственными актёрами.

Какие есть патчи

React выпустил исправления для всех затронутых веток: 19.0.1, 19.1.2 и 19.2.1, где логика декодирования Flight-payload переработана и больше не допускает опасной десериализации.

Next.js, в свою очередь, обновил все поддерживаемые линии:

1. для Next.js 15 доступны патч-релизы: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7;
2. для Next.js 16 — патч 16.0.7;
3. если вы сидите на canary-сборках Next.js 14 (≥14.3.0-canary.77) с поддержкой React 19/RSC — рекомендуется откатиться на последний стабильный 14.x, где RSC-имплементация ещё не включает уязвимый код.

Параллельно Vercel и облачные провайдеры задеплоили временные фильтры трафика (WAF-правила, сигнатуры для IDS/IPS), но сами подчёркивают: это только дополнительный слой защиты, а основное средство — обновление зависимостей и повторный деплой приложений.

Уроки для команд

Эта история очень наглядно показывает несколько вещей:

1. фронтенд-фреймворк с серверными возможностями (RSC, Server Actions) наследует классические backend-уязвимости — RCE, небезопасная десериализация, атаки на внутренние протоколы;
2. SCA-сканеры и мониторинг CVE по зависимостям теперь must-have даже для «просто фронта»;
3. нужна формализованная процедура реагирования: кто следит за advisory React/Next.js, кто оценивает затронутые сервисы, кто отвечает за быстрый патч-релиз и ротацию секретов.

И даже при наличии таких багов ущерб сильно ограничивается, если вы соблюдаете принцип минимально необходимых привилегий: контейнеры изолированы, у Next.js-сервиса только нужные доступы, секреты лежат в secret-manager’е, а не в «толстом» .env. Тогда даже критический RCE не превращается автоматически в полный захват инфраструктуры.

Что делать владельцам проектов на Next.js 14, 15 и 16

Ниже — практические шаги по версиям. Я ориентируюсь на официальные advisory React и Next.js плюс сводки от Vercel и крупных вендоров.

Если у вас проект на Next.js 14

Проверить, затронут ли вы вообще

Открой package.json:

1. если "next": "14.x" (стабильные 14-е релизы) и вы сидите на React 18 — конкретно CVE-2025-55182 вас не касается, потому что уязвима реализация RSC в React 19;
2. если "next": "14.3.0-canary.77" или выше canary, и/или вы вручную подвезли React 19 и RSC-пакеты, проект может быть уязвим.

Проверьте код:

1. используете ли вы App Router c серверными компонентами (app/ с export const dynamic, server actions, async-компоненты и т.п.);
2. есть ли прямое использование react-server-dom-* пакетов.

Рекомендованные действия

Если вы на стабильном Next.js 14 + React 18:

1. всё равно обновитесь до последнего патча 14.x, чтобы иметь актуальные баг-фиксы и security-улучшения не по этому CVE, а в целом;
2. убедитесь, что вы не тянете React 19 через peerDependencies/overrides, и не используете экспериментальный RSC-стек.

Если вы на canary-ветке 14 с React 19 / RSC:

1. Зафиксируйте состояние (теги в Git, бэкапы).
2. Откатитесь на стабильный 14.x согласно официальной рекомендации React/Next:

   
   npm install next@14 react@18 react-dom@18
   

   и приведите код к поддерживаемому API, если использовали экспериментальные фичи.
3. Пересоберите и задеплойте проект.
4. На всякий случай проверьте логи на наличие странных запросов к внутренним RSC-endpoint’ам за последние дни.