React2Shell: все, что нужно знать на сегодняшний день

В начале декабря 2025 года в экосистеме React всплыла уязвимость, которую многие уже сравнивают с Log4Shell по потенциальным последствиям. Баг получил имя React2Shell и идентификатор CVE-2025-55182. Он затрагивает серверное использование React Server Components и позволяет удаленно выполнять произвольный код на уязвимых серверах без какой-либо аутентификации.

React как библиотека поддерживается компанией Meta (организация признана экстремистской и запрещена в РФ), а React Server Components и Next.js давно стали стандартом де-факто для современных веб-приложений. Поэтому критическая ошибка в этой связке автоматически превращается из частной проблемы фронтенд-разработчиков в глобальный риск для инфраструктуры и данных.

Ниже собран концентрированный обзор того, что к сегодняшнему дню известно о React2Shell: от технических подробностей и списка затронутых версий до индикаторов атак и практического чеклиста действий для разработчиков, специалистов по безопасности и SRE-команд.

Что такое React2Shell в двух словах

React2Shell — это критическая уязвимость в протоколе Flight, который используется для обмена данными между сервером и клиентом в React Server Components. Ошибка связана с небезопасной десериализацией данных: сервер доверяет тому, что прислал клиент, и в определенных условиях это позволяет злоумышленнику заставить сервер выполнить произвольный код.

Уязвимость получила максимальный балл по шкале CVSS — 10.0. Она затрагивает стандартные конфигурации нескольких популярных библиотек и платформ, включая React Server Components и Next.js, а эксплуатируется одним HTTP-запросом. Именно сочетание трех факторов — без аутентификации, по умолчанию и с удаленным выполнением кода — делает React2Shell настолько опасной.

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

Кого затрагивает React2Shell

Важно сразу отделить клиентский React, который рендерится в браузере, от серверных сценариев. Ошибка находится именно в серверной части — там, где React обрабатывает запросы и формирует данные для клиента в формате Flight. Если ваш проект использует только клиентский рендеринг без серверных компонентов, риск минимален. Но если у вас Next.js с App Router и серверными компонентами, ситуация совсем другая.

На момент написания статьи официально опубликованы следующие ключевые моменты по затронутым компонентам и версиям:

• Уязвимы пакеты семейства react-server-dom-* версий 19.0, 19.1.0, 19.1.1 и 19.2.0, в том числе:
  • react-server-dom-webpack
  • react-server-dom-parcel
  • react-server-dom-turbopack
• Под удар попадают фреймворки и инструменты, которые реализуют React Server Components и полагаются на эти пакеты: прежде всего Next.js с App Router, а также React Router при использовании серверных функций, Waku, плагины RSC для Parcel и Vite и другие интеграции.
• Отдельный идентификатор CVE-2025-66478 был выделен для Next.js, так как он встраивает уязвимый код React не как обычную зависимость, а в собственный репозиторий. Для Next.js опубликован собственный список затронутых и исправленных версий.

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

В случае Next.js уязвимость затрагивает приложения, использующие App Router и серверные действия. Классический Pages Router и стабильные ветки Next.js 13 и 14 в официальных обзорах указываются как неуязвимые, тогда как ветки 15 и 16 до определенных патчей признаны уязвимыми. Для точной проверки нужно сверяться с актуальной таблицей версий в официальной рекомендации Next.js и документации вашей платформы размещения.

Серверный React против клиентского: почему это важно для понимания риска

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

В классическом клиентском сценарии максимум, что может сделать злоумышленник, — это попытаться внедрить вредоносный скрипт в браузер пользователя. В случае React Server Components под удар попадает сам сервер приложения: если удается заставить его выполнить произвольный код, атакующий получает доступ ко всему, что доступно процессу Node.js или среде, в которой крутится ваш сервер.

Поэтому первый практический вывод для команд безопасности и разработки прост: не все проекты на React одинаковы с точки зрения риска. Если у вас в продакшене есть хотя бы один проект с серверными компонентами и App Router, он должен получить приоритет по аудитам и обновлениям выше, чем классические SPA на старых версиях React.

Как устроена уязвимость на техническом уровне

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

Исследователи показали, что из-за отсутствия проверки некоторых свойств и особенностей обработки прототипов возможно провести цепочку атак, которая приводит к обращению к конструктору Function в JavaScript. Этот конструктор, по сути, дает возможность собрать и выполнить любой произвольный код, если до него удается добраться через цепочку сериализованных объектов.

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

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

Масштаб и текущая активность атакующих

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

Оценки количества потенциально уязвимых ресурсов различаются, но порядок величин везде одинаков: речь идет о десятках тысяч публичных узлов и огромном количестве внутренних сервисов, о которых нельзя судить по простому сканированию из сети. Реальные цифры по внутренним системам в крупных организациях могут быть существенно выше, так как React Server Components и Next.js активно используются во внутренних порталах, панелях управления и сервисах интеграции.

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

Что ищут атакующие и какие индикаторы стоит мониторить

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

На сетевом уровне обращайте внимание на следующие особенности:

• подозрительные POST-запросы к вашим приложениям на Next.js и другим сервисам с React Server Components, особенно к маршрутам, которые ранее не использовались для приема сложных данных;
• наличие нетипичных заголовков, связанных с серверными действиями, таких как идентификаторы действий или специальные метки для Flight-протокола;
• нестандартные структуры в теле запроса, содержащие необычные последовательности символов и вложенные структуры, которые не соответствуют ожидаемому формату формы или JSON.

На уровне хостов и контейнеров полезно отслеживать:

• всплески запуска командных оболочек или интерпретаторов (например, неожиданный запуск командной строки из процесса Node.js);
• обращения к файлам вроде /etc/passwd или системным утилитам, с которыми ваше приложение обычно не работает;
• создание временных файлов и скриптов в каталогах вида /tmp или аналогичных для вашей операционной системы;
• подключение к внешним хостам, с которыми приложение ранее не взаимодействовало, особенно при использовании этих соединений сразу после обработки внешнего запроса.

Важно понимать, что одиночный подозрительный HTTP-запрос еще не означает успешную атаку. Однако совокупность необычного трафика и следов удаленного запуска команд на сервере — уже повод рассматривать сценарий инцидента с использованием React2Shell и подключать специалистов по реагированию.

Какие версии считаются исправленными

Команда React оперативно выпустила обновления для уязвимых пакетов, а разработчики Next.js опубликовали отдельный список исправленных версий. Важно не просто обновить библиотеку в локальном package.json, но и действительно пересобрать и заново развернуть приложение, чтобы новая версия попала в продакшн-окружение.

На текущий момент в публичных рекомендациях фигурируют следующие ориентиры:

• Для пакетов семейства react-server-dom-* рекомендуется переход на исправленные версии, такие как 19.0.1, 19.1.2 и 19.2.1. Эти релизы содержат исправление ошибки десериализации в протоколе Flight и должны заменить все более ранние 19.x в ваших проектах.
• Для Next.js опубликован набор версий, в которых уязвимость устранена. Среди них, в частности, 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7 и 16.0.7, а также соответствующие исправленные предварительные релизы для веток 15 и 16. Стабильные ветки 13 и 14 с классическим Pages Router не подпадают под описание проблемы.

Важный нюанс для Next.js заключается в том, что он встраивает код React Server Components напрямую, а не как стандартную зависимость из реестра npm. Поэтому простое обновление React в проекте не гарантирует устранения React2Shell: необходимо именно обновить сам Next.js до исправленной версии. Это особенно актуально для тех, кто привык полагаться на автоматические инструменты обновления зависимостей.

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

Инструменты и сервисы для обнаружения уязвимых систем

На фоне React2Shell за считанные дни появилось множество сканеров и «эксплойтов» на GitHub, часть из которых, по оценке исследователей, либо нерабочие, либо неправильно понимают суть уязвимости. Поэтому относиться к случайным репозиториям стоит с осторожностью, особенно если вы планируете запускать их в своей инфраструктуре.

Вместо этого разумнее опираться на инструменты от известных игроков рынка и официальные рекомендации исследователя, который первым сообщил о проблеме. Среди полезных направлений:

• специализированные сканеры для анализа конфигураций и lock-файлов проектов на предмет уязвимых версий React Server Components и Next.js;
• утилиты командной строки для проверки ваших доменов и сервисов на наличие известных признаков React2Shell, разработанные известными исследовательскими компаниями;
• функции обнаружения в решениях класса CNAPP, мониторинге уязвимостей и APM, которые уже получили отдельные сигнатуры для React2Shell.

Для пользователей Next.js дополнительно появился официальный инструмент в виде npm-пакета, который автоматически обновляет проект до исправленных версий. Его задача — не эксплуатировать баг, а помочь быстро закрыть все уязвимые комбинации версий, не разбираясь вручную в каждом промежуточном релизе.

При использовании внешних сканеров важно помнить: даже если конкретный инструмент не находит у вас уязвимости, это не повод откладывать обновление. Сам автор React2Shell отдельно подчеркивал, что универсального способа надежно отличить уязвимые и неуязвимые конфигурации по внешним признакам пока нет, поэтому стратегия «если сканер ничего не нашел, значит можно не патчиться» здесь особенно рискованна.

Пошаговый план действий для команд разработчиков и безопасности

React2Shell уже перешел из стадии теоретической проблемы в стадию активной эксплуатации. Поэтому подход «обсудим на следующем спринте» в данном случае равен сознательному принятию риска. Гораздо продуктивнее отнестись к ситуации как к небольшому кризису и развернуть сжатую по времени кампанию по инвентаризации и обновлению.

Один из практичных вариантов плана может выглядеть так:

1. Соберите перечень всех приложений с React Server Components и Next.js. Используйте поиск по репозиториям, внутренние каталоги сервисов и данные из систем мониторинга. Отдельно учтите внутренние админки, панели и интеграционные сервисы, которые редко всплывают в пользовательских списках.
2. Для каждого сервиса определите используемые версии библиотек. Проанализируйте package.json, lock-файлы и фактические версии в продакшн-окружении. Не полагайтесь только на то, что написано в репозитории, если у вас сложные цепочки сборки и выкладки.
3. Приоритизируйте обновление. В первую очередь патчьте публично доступные сервисы с обработкой чувствительных данных или с доступом к внутренним системам. Ниже по списку будут внутренние приложения, доступные только из корпоративной сети.
4. Обновите React Server Components и Next.js до исправленных версий. Обновление должно завершаться пересборкой и полным redeploy в продуктивную среду. Если используете отдельный инструмент автоматического обновления для Next.js, прогоните его по всем проектам.
5. Временно усилье защиту на периметре. Включите специальные правила веб-экранов, которые уже предлагают облачные и сетевые провайдеры. Это не панацея, но дополнительный фильтр для массовых сканирований и грубых эксплойтов.
6. Проанализируйте журналы за последние дни. Ищите признаки необычных запросов к маршрутам Next.js и серверным компонентам, всплески ошибок, а также нетипичные команды и процессы на серверах приложений.
7. Зафиксируйте уроки и обновите процессы. Пропишите в стандартных процедурах мониторинг и ускоренное обновление для серверных компонент и ключевых библиотек, чьи уязвимости могут дать RCE по умолчанию.

Если вы обнаружили признаки возможной компрометации или используете инфраструктуру крупного облачного провайдера, имеет смысл параллельно открыть запрос в их службу поддержки безопасности. Многие из них уже отслеживают React2Shell на своем уровне и смогут дополнить вашу картину наблюдениями со стороны сетевой и облачной инфраструктуры.

Почему React2Shell сравнивают с Log4Shell и что это говорит о будущем

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

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

Для отрасли это очередное напоминание, что одних проверок кода на уровне конкретного репозитория уже недостаточно. Нужны прозрачные перечни компонентов (SBOM), инструменты, которые отслеживают уязвимости в цепочке зависимостей, и процессы, позволяющие быстро отреагировать, когда критический баг обнаруживается не у вас, а где-то глубоко в используемом стеке.

Долгосрочные меры: как уменьшить ущерб от подобных уязвимостей в будущем

Даже после установки всех патчей вопрос «как сделать так, чтобы следующий React2Shell был для нас менее болезненным» останется актуальным. Здесь речь уже не только о конкретных версиях библиотек, а об архитектуре и принципах построения приложений.

Несколько направлений, которые стоит рассмотреть:

• Изоляция сервисов. Сервер, который рендерит интерфейс и обрабатывает серверные компоненты, не обязан иметь прямой доступ ко всей базе данных или внутренним сервисам. Чем меньше у него прав, тем меньше ущерб при RCE.
• Минимизация критичных серверных действий. Не все операции должны выполняться через серверные действия React или Next.js. Самые опасные функции (управление доступом, работа с ключами, финансовые операции) лучше вынести в отдельные, хорошо защищенные сервисы.
• Жесткие ограничения исходящих соединений. Если приложение на Node.js не может произвольно подключаться к любым адресам в интернете, злоумышленнику будет сложнее организовать вывод данных или загрузку второго этапа атаки.
• Поведенческий мониторинг. Отслеживание нетипичных процессов, системных вызовов и сетевых паттернов вокруг приложений с RSC поможет заметить атаку даже в случае нулевого дня, когда конкретная уязвимость еще неизвестна.
• Регулярные учения по реагированию. React2Shell показал, что окно между раскрытием и эксплуатацией почти исчезло. Командам нужны отработанные сценарии, как действовать в первые часы после появления информации о критической уязвимости.

Главное, что дает React2Shell в качестве урока: риск от библиотек уровня React нельзя воспринимать как абстрактную «проблему фронтенда». В современном стеке такие компоненты глубоко интегрированы в серверную логику, и их уязвимости веб-приложений должны рассматриваться на одном уровне с RCE в ядре операционной системы или ключевых системных сервисах.

Где следить за обновлениями по React2Shell

Ситуация вокруг React2Shell развивается очень быстро: выходят новые версии библиотек, обновляются рекомендации по детектированию и появляются дополнительные материалы от аналитиков и облачных провайдеров. Чтобы оставаться в курсе, имеет смысл следить за несколькими источниками:

• Сайт исследователя React2Shell с кратким описанием уязвимости и ссылками на официальные рекомендации React и Next.js.
• Официальный блог React с подробным описанием затронутых пакетов и версий и инструкциями по обновлению.
• Блог Next.js с отдельным советом по исправлению уязвимости в проектах на App Router и списком патчей.
• Материалы Vercel по защите размещенных приложений и подробным разбором включенных правил защиты на стороне платформы.
• Блоги крупных вендоров безопасности и аналитических компаний, которые публикуют новые индикаторы компрометации и правила для SIEM, EDR и сетевых экранов.

Если у вас в продакшене есть приложения на React Server Components или Next.js, имеет смысл формально назначить ответственных за отслеживание новых рекомендаций по React2Shell в ближайшие недели. Пока уязвимость активно используется в дикой среде, игнорировать эту тему — значит сознательно жить с повышенным уровнем риска.