Критическая уязвимость в серверных пакетах React: эксплойты опубликованы, патч обязателен

Разработчикам на React и Next.js пора ускорить плановое обновление. Уязвимость в серверных пакетах для рендеринга на стороне сервера позволяет выполнить произвольный код на сервере. Оценка опасности - 10.0 по шкалам CVSS 2.0 и 3.1, выше не бывает. Идентификаторы - CVE-2025-55182 и BDU:2025-15156; второй номер присвоен в BDU (Банке данных угроз безопасности информации). Проблему подтвердил производитель, Meta Platforms Inc. Патч вышел, но публичные эксплойты тоже, поэтому между раскрытием деталей и массовыми атаками почти не осталось времени. В зоне риска команды, которые держат серверный рендеринг в публичном доступе: интернет-магазины, личные кабинеты, внутренние порталы. Хостинг, облако или собственный сервер - разницы нет, важна лишь доступность сервиса извне. Уязвимость затрагивает не браузер посетителя, а инфраструктуру компании. Значит, последствия касаются и бизнеса, и службы безопасности. Для SOC повод поставить на контроль обращения к серверным компонентам и вызовы функции runInThisContext(). React давно перестал быть нишевым инструментом, поэтому редкой эту проблему не назовёшь. Начинать логично с внешних сервисов, где цена простоя выше всего.

Описание

Корень проблемы - функция requireModule() в пакетах react-server-dom-webpack, react-server-dom-parcel и react-server-dom-turbopack. Механизм десериализации даёт сбой на специально подготовленном параметре hasOwnProperty. Атакующий отправляет сформированный HTTP-запрос, и серверный процесс доверяет данным из запроса, выполняя их как код. Класс проблемы - десериализация ненадёжных данных, CWE-502. Эксплуатация не требует учётных данных, а следов в журналах входа почти не остаётся. Поэтому привычные сценарии поиска подозрительных авторизаций тут не работают. Смотреть надо на необычные запросы к эндпоинтам серверных компонентов, на запуск новых процессов из среды Node.js и на вызовы runInThisContext(). Вызовы идут на стороне сервера, так что браузерные политики безопасности и расширения защиты бесполезны. Сканеры для проверки периметра уже выложили в открытых репозиториях GitHub, значит, проверить инфраструктуру можно без ожидания подрядчика. Автоматика даёт быстрый ответ, но не заменяет ручную проверку конфигурации. Заодно стоит пройтись по цепочке зависимостей. В монорепозиториях фиксация версий часто прячет уязвимый пакет глубже, чем видно в манифесте верхнего уровня. Ошибки десериализации в JavaScript-окружении встречаются регулярно: среде приходится доверять структуре данных, пришедшей извне. Здесь это доверие обходится без пароля.

Список уязвимого ПО шире, чем подсказывает название. Кроме React версий до 19.2.1 в связке с серверными пакетами под удар попадает фреймворк Next.js от Vercel, включая канареечные сборки. Проверить стоит и проекты на React Router, Waku, Expo, Redwood SDK. Доказательства концепции и готовые сканеры лежат в открытом доступе, поэтому порог входа для атакующего низкий, а сроки у всех разные. Последствия варьируются от кражи данных до развёртывания программ-вымогателей и полного контроля над сервером. Для сервиса с оплатой это ещё и риск простоя, а для баз с персональными данными - риск разбирательств с регулятором. Инвентаризация нужна в первую очередь там, где серверный рендеринг смотрит в интернет. Правда, часть команд узнает о проблеме только от сканеров или из внешних отчётов. Поэтому проверку стоит провести даже при отсутствии срабатываний в мониторинге. Чем больше сервисов в контуре, тем выше шанс, что один из них остался без присмотра.

Обновления вышли. Ветку React нужно поднять до 19.2.1, 19.1.2 или 19.0.1 - выбор зависит от канала поддержки. Для Next.js актуальны 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7 и 16.0.7 и выше; исправление есть и в канареечной 14.3.0-canary.77. Если перезапуск сервиса откладывается, помогает смена стандартного порта 3002 на нестандартный. Межсетевой экран уровня приложений (WAF) отсечёт часть подозрительных запросов к эндпоинтам серверных компонентов. Доступ по белому списку изолирует уязвимое ПО от публичной сети, а запрет на загрузку файлов для непривилегированных пользователей закрывает обходной путь. Компенсирующие меры снижают риск, но не убирают его: обход WAF для подобных запросов возможен. Мониторинг стоит направить на вызовы runInThisContext() и на события десериализации. Системы класса SIEM (управление событиями информационной безопасности и корреляция данных) и IDS/IPS (обнаружение и предотвращение вторжений) с известными индикаторами компрометации добавят контроль. Логи серверных компонентов стоит хранить дольше обычного: разбор инцидента без них превращается в догадки. Аудит собственного кода на похожие ошибки десериализации займёт время, зато снимет класс проблем целиком. График релизов теперь определяет не удобство команды, а скорость, с которой чужие сканеры находят открытые серверы.