В конце 2025 года была раскрыта критическая уязвимость CVE-2025-55182, затрагивающая механизм React Server Components. Ошибка позволяет удалённо выполнять произвольный код на сервере без аутентификации и без взаимодействия с пользователем. Уязвимость получила максимальную оценку по шкале CVSS и уже используется в реальных атаках, в том числе на инфраструктуру российских компаний.
 
Проблема особенно опасна из-за широкого распространения React и фреймворков на его основе, в первую очередь Next.js, где серверные компоненты включены по умолчанию. Уязвимость CVE-2025-55182 (React2Shell) была публично раскрыта 3 декабря 2025 года вместе с официальным security-advisory и исправлениями со стороны React и экосистемных проектов:
 
·   https://react.dev/blog/2025/12/03/critical-security-vulnerability-in-react-server-components
·   https://react2shell.com/
·   https://cloud.google.com/blog/products/identity-security/responding-to-cve-2025-55182

Что такое React Server Components

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

Для обмена данными между клиентом и сервером используется специальный протокол, передающий сериализованное описание дерева компонентов. Сервер принимает эти данные, восстанавливает структуру и выполняет соответствующий код.

Эксплуатация CVE-2025−55 182

Для эксплуатации атакующему достаточно отправить один запрос. В этом запросе атакующий:

• внедряет конструктор Function через блоб
• ссылается на него с помощью $B3 в цепочке промиса
• обманывает десериализатор, заставляя его вызвать Function с вредоносным кодом

На данный момент существует большее количество публичных эксплойтов, один из них поставляется в виде Chrome Extension (https://github.com/mrknow001/RSC_Detector). Будем использовать его для демонстрации в дальнейшем.

Эксплуатация уязвимости
 
Несомненно, React Server Components может использоваться внутри образа контейнера, запущенного под управлением Kubernetes.

В качестве примера, воспользуемся демо-приложением, с уязвимой версией React. Приложение собрано и публично доступно в виде Docker образа — https://hub.docker.com/r/4c69/cve-2025−55 182

Для примера демонстрации воспользуемся эксплойтом и прочитаем переменные окружения:

Взгляд Luntry
 
Используя богатую функциональность сертифицированного решения Luntry, обнаружить и защититься от эксплуатации CVE-2025-55182 (и не только) можно на всех этапах жизненного цикла приложения. Это особенно важно для российских компаний, стремящихся соответствовать требованиям ФСТЭК России и обеспечить безопасность КИИ
 
В Runtime
 
Так, например, сразу после эксплуатации уязвимости и выполнения команды env мы увидим соответствующую аномалию на вкладке Monitor Mode:

Дополнительно важно отметить, что Runtime политики Luntry основаны не на сигнатурах конкретных уязвимостей, а на анализе поведения процессов и приложений во время выполнения. Благодаря поведенческому подходу такие политики способны выявлять и блокировать подозрительную активность даже в случае ранее неизвестных уязвимостей (0-day).

Например, попытки запуска shell-процессов из web-контекста, нетипичные обращения к системным утилитам или аномальные цепочки процессов будут обнаружены независимо от того, известна ли конкретная CVE на момент атаки. Таким образом, обнаружить эксплуатацию CVE-2025−55 182 (React2Shell) можно было бы, даже если бы уязвимость ещё оставалась 0day.

Чтение переменных окружения — довольно популярная техника среди злоумышленников. Специально для таких случаев у нас есть Runtime Rules. В отличие от Runtime Policy, они работают по принципу чёрного списка: можно самостоятельно настраивать, о каких событиях получать уведомления, или воспользоваться нашей встроенной библиотекой правил, которая покрывает матрицу MITRE ATT&CK для контейнерных угроз.
В том числе там есть правило для обнаружения чтения переменных окружения. Так выглядит сработка по этому правилу:

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

Полезной функциональностью в помощь для расследования инцидентов будет Reaction Policies. Создав такой тип политики, при срабатывании некоторых условий в аномалии (например, аномальное взаимодействие с ФС контейнера или запуска исполняемого файла, которого не было ранее в образе) можно собрать артефакты для дальнейшей форензики в виде дампа файловой системы, RAM, а также остановить контейнер.

Например, создадим политику, которая сделает дамп файловой системы контейнера, при действиях реального злоумышленника — в момент создания файла для дальнейшего закрепления внутри скомпрометированного контейнера.

В результате действий предполагаемого злоумышленника, видим успешный статус о создании дампа.

В S3 хранилище наблюдаем сам дамп.

Также на основе сгенерированной модели поведения можно создавать Prevention Policies, которые позволяют явно задавать, запуск каких исполняемых файлов разрешён или запрещён в контейнере. Для этого выберем нужную нагрузку, перейдем в настройки и сгенерируем политику.

После применения Runtime Policy, в которой разрешён только легитимный процесс node, через который запущено наше тестовое приложение, попробуем прочитать файл /etc/passwd:

Сделать это не получится, поскольку на контейнер действует Prevention Policy, разрешающая запуск только определённых исполняемых файлов. При попытке запустить неразрешённую команду система заблокирует её выполнение и сформирует соответствующий Alert.

На этапе сборки

Узнать о CVE-2025−55 182 можно и на этапе сканирования образа. Luntry поддерживает сканирование контейнерных образов в Runtime, CI и Registry, что позволяет выявлять уязвимости до деплоя и уже в работающих workloads. Кроме того, результаты сканирования обогащаются внешними источниками данных — метрикой вероятности эксплуатации из EPSS, информацией о наличии публичного эксплойта, а также сведениями о фактах эксплуатации уязвимости «in-the-wild» из каталога CISA KEV (Known Exploited Vulnerabilities). Всё это позволяет выстраивать более точечную и риск-ориентированную приоритизацию уязвимостей — с учётом не только CVSS, но и реальной вероятности атаки.

Если двигаться с правой стороны (Runtime) в левую (к Development) по принципам ShiftLeft (Right-to-Left Security), то на ранних стадиях Luntry помогает предотвращать попадание уязвимых зависимостей в продакшн ещё на этапе CI, блокируя сборку при обнаружении критичных CVE или уязвимостей с высоким EPSS. Таким образом, контроль смещается максимально «влево», но при этом сохраняется защита на Runtime-уровне — если уязвимость всё же дошла до продакшна или появилась как 0-day.

В Luntry появился новый функционал — Security Gates, который позволяет контролировать соответствие приложений заданным требованиям безопасности и блокировать дальнейший деплой при их нарушении. Например, можно настроить проверку, которая остановит деплой приложения, если в его образе обнаружена критическая уязвимость CVE-2025−55 182 (React2Shell).

Security Gates можно применять не только на этапе CI, но и в Registry и Runtime. Например, в Runtime, SOC сможет получить уведомление о появлении в периметре уязвимости критического уровня, которая доступна для эксплуатации по сети и для которой существует эксплойт.
 
На постэксплуатации уязвимости
 
Если злоумышленнику все-таки удалось проэксплуатировать уязвимость, то оказавшись в контейнере он начнет проводить разведку — посмотрит какие права у него есть, попробует создать или прочитать какие-нибудь ресурсы в Kubernetes кластере. Все это так или иначе сгенерирует ряд запрос в Kubernetes API, которые мы можем увидеть благодаря интеграции с Kubernetes Audit Log.

Luntry предоставляет обширную библиотеку правил, покрывающую матрицу MITRE ATT&CK для контейнерных угроз. Кроме того, можно создавать собственные детекты для выявления вредоносных запросов к Kubernetes API и других подозрительных действий.

Выводы:

1. Уязвимость CVE-2025−55 182 (React2Shell) решение могло обнаружить и защитить от нее, даже если бы она была 0day.
2. Возможности Luntry позволяют защитить окружение от подобных уязвимостей на всем жизненном цикле: от сборки до runtime.
3. Встроенная в Luntry экспертиза, база знаний и конструкторы правил, политик, позволяют работать с системой командам с начальным и продвинутым уровнем знаний в данной области.

💡 Хотите проверить, насколько защищена ваша контейнерная инфраструктура от атак нового поколения?
Запросите демонстрацию возможностей Luntry или разверните пилотный проект, чтобы увидеть, как наше сертифицированное решение блокирует угрозы в реальном времени.

👉 Связаться с экспертами Luntry