Если ты используешь React Server Components или Next.js с App Router, срочно обновляй зависимости. На конец прошлого года раскрыли уязвимость с максимальным рейтингом CVSS 10.0 — это означает, что любой может запустить произвольный код на твоём сервере без аутентификации и вообще без каких-то особых навыков.

Речь идёт о CVE-2025-55182, также известной как React2Shell. Это не очередной баг в сторонней либе, который ты сможешь обойти — это дыра в ядре React Server Components, в механизме десериализации Flight-протокола. Один неправильный HTTP POST-запрос к любому Server Function эндпоинту — и твой сервер скомпрометирован.

Что произошло с Flight-протоколом

React Server Components используют Flight — это специальный протокол для общения между сервером и клиентом. Сервер обрабатывает данные с клиента, парсит их, запускает серверную логику и отправляет обратно сериализованное дерево компонентов. Звучит просто, но здесь скрывается проблема.

Когда React десериализует входящие payload’ы, он не валидирует их должным образом. Это означает, что атакующий может внедрить вредоносные структуры данных, которые React примет как обычные. Уязвимость особенно хитрая потому что она в самом core механизме обработки — в том самом requireModule функшене, которая нужна для работы Server Actions. Атакующий может использовать свойство __proto__ в payload’е, чтобы загрязнить прототип и добиться выполнения произвольного кода прямо на твоём сервере.

Проблема касается не только React 19 самого по себе. Пострадали:**

• Все версии react-server-dom-webpack от 19.0.0 до 19.2.0
• react-server-dom-parcel от 19.0.0 до 19.2.0
• react-server-dom-turbopack от 19.0.0 до 19.2.0
• Next.js версии 15.x и 16.x (App Router)
• Canary-сборки Next.js начиная с 14.3.0-canary
• React Router, Waku, RedwoodSDK, плагины для Parcel и Vite

Будут затронуты буквально все приложения, которые используют React 19 с включёнными server components. Даже если ты думаешь, что ты в безопасности — проверь package-lock.json или yarn.lock. Может быть, инструмент уже установил патчированную версию, а может быть, нет.

Почему это так критично

Обычно remote code execution в production-окружении — это кошмар каждого разработчика. Но это ещё не самое худшее. CVE-2025-55182 получила статус pre-authentication RCE — это означает, что атакующему не нужны никакие credentials, не нужно обходить слои безопасности, не нужно вычислять сложные цепочки уязвимостей. Одного POST-запроса достаточно.

Почему это особенно опасно для бизнеса? Вот что может случиться:**

• Кража данных — весь контент, все пользовательские данные, всё, что может быть полезным для преступников
• Развёртывание ransomware — твои серверы шифруют и требуют выкуп
• Нарушение compliance — если у тебя PCI-DSS, GDPR или другие требования, взлом критичного сервера — это прямое нарушение
• Простой систем — сервер забивается под хост для бот-сетей, падает производительность, пользователи не могут работать

И самое противное — всё это может произойти без каких-то громких следов. Скрипт может работать молча, выкачивая данные в фоне, пока ты ничего не заметишь.

Версии-патчи: что обновлять

Добрая новость — патчи уже выкатили. Плохая — их нужно установить прямо сейчас. Не завтра, не в следующий спринт, а прямо сейчас.

Для разных версий пакетов нужны разные патч-версии. Это нарочно сделано так, чтобы ты не получил breaking changes, если ты зафиксировал мажор в package.json. Вот таблица:

Для Next.js аналогично — обновляйся до последних версий в своём мажоре, но обязательно проверь, что это будут версии с патчем:**

• Next.js 15.x — обновись до 15.1.5 или выше
• Next.js 16.x — обновись до 16.1 или выше
• Next.js 14.x (если ты используешь canary) — эта ветка тоже затрагивается, но обновление немного сложнее

Один нюанс, который многие пропускают: если в твоём package.json стоит "react": "^19.0.0", то это не гарантирует, что при переустановке или деплое ты получишь 19.0.1. Каретка означает только нижний лимит. Поэтому обязательно посмотри в lock-файл — что там на самом деле установлено. Если там 19.0.0 или 19.1.0 или 19.2.0 (без патч-версии) — это уязвимо.

Как срочно защитить систему, пока идёт обновление

Патчирование — это долгий процесс, если у тебя большой проект с кучей зависимостей. Не ждать же целый день, пока npm install доделает все свои дела. Есть временные меры, которые смогут подержать оборону до момента, когда ты откатишь полное обновление.

WAF-правила — поставь их прямо сейчас. Если твой сервер стоит за облачным балансировщиком (AWS, Google Cloud, Azure), у них есть встроенные WAF-консоли. Нужно добавить фильтр, который будет отклонять запросы с подозрительными Flight-chunk структурами, в частности запросы с __proto__ свойствами. Это не остановит всех, но отсеет базовые эксплойты.

Отключи Server Functions — если у тебя есть возможность, временно отключи Server Functions в production. Да, это означает, что часть функциональности не будет работать, но это лучше, чем компромисс. Например, если твоё приложение больше про статический контент, а Server Functions используются только в части фич, ты можешь их выключить отдельно.

Запускай сервер с минимальными правами — если даже атакующий получит RCE, он не должен иметь доступ ко всей системе. Используй отдельного пользователя, ограничь права доступа к файлам и базам данных, запускай контейнеры с read-only filesystem где возможно. Так, если даже код запустится, он не сможет нанести максимальный урон.

Мониторь логи — включи детальное логирование на своих эндпоинтах Server Functions. Ищи странные структуры в payload’ах, необычные заголовки next-action или rsc-action-id, попытки использования __proto__. Многие облачные провайдеры уже добавили автоматические детекторы таких попыток.

Как правильно откатить патч

Если ты никогда не обновлял React в production, сейчас это нужно делать очень аккуратно. Вот план действий:

1. Создай отдельную ветку из мастера. На ней будешь экспериментировать.

2. Обнови package.json вручную — не удаляй node_modules, не очищай кэш npm. Просто измени версии в package.json:

"react": "^19.2.2",
"next": "^16.1.0",
"react-server-dom-webpack": "^19.2.2"

3. Запусти npm install (или yarn install, если используешь yarn). Дай ему время скачать и установить всё.

4. Запусти локальный бенч — проверь, что приложение запускается, что нет ошибок на старте. Если у тебя есть E2E тесты, запусти их. Если нет — хотя бы немного покликай по интерфейсу.

5. Запусти production build — npm run build. Проверь, что всё компилируется без ошибок. Если что-то сломалось, скорее всего будут сообщения об этом на этапе сборки.

6. Залей на staging — развёрни на тестовом окружении, дай команде потестить. Хотя бы день.

7. Откатись на production — если на staging всё окей, заливай на production. Но делай это во время low-traffic периода (ночью, в выходные, когда пользователей мало). Если что-то сломается, откатиться будет проще.

Что ещё нужно знать про эту уязвимость

Оказывается, CVE-2025-55182 — это не единственная проблема в React Server Components. Пока ребята фиксили эту уязвимость, нашли ещё две:**

• CVE-2025-55184 и ещё пара номеров — отказ в обслуживании (DoS). Это CVSS 7.5, не такое критичное, как RCE, но тоже неприятно. Атакующий может завалить твой сервер бесполезными запросами и вывести его из строя.
• CVE-2025-55183 — утечка исходного кода. CVSS 5.3. Менее критично, но всё равно неприятно — твой бизнес-логика может быть раскрыта.

Все эти уязвимости закрыты в тех же версиях патчей, которые мы обсуждали выше. Так что когда ты обновляешь React 19.2.2 и Next.js 16.1, ты закрываешь сразу все три дыры.

Что дальше

Уязвимости вроде CVE-2025-55182 показывают, как важно держать зависимости в актуальном состоянии. Да, обновления иногда ломают код, да, это требует времени на тестирование. Но риск остаться с критичной дырой в production — это куда больнее. Поэтому стоит подумать о том, как организовать процесс обновлений в своей команде: может быть, автоматические checks через dependabot, может быть, выделенный день в неделю для ревью и апдейта критичных пакетов. И уж точно стоит подписаться на уведомления безопасности от React и Next.js — они будут слать вам прямо в морду, когда появляется что-то критичное. Так что, когда в следующий раз раскроют уязвимость, ты уже будешь знать, что нужно делать.