CVE-2025-55182 в React Server Components: RCE через прототипное загрязнение в Next.js

[hannadev]

CVE-2025-55182 - это критичная дыра в React Server Components, которая позволяет RCE без аутентификации. Затрагивает React 19.x и Next.js 15-16 с App Router. Понимая прототипное загрязнение в Flight протоколе, можно быстро патчить и защищать прод.

Уязвимость бьет по RSC эндпоинтам, где сервер десериализует клиентские пейлоады. Атакер шлет крафтед запрос, загрязняет прототипы и выполняет произвольный код. Это не просто теория - дефолтный Next.js app из create-next-app уязвим из коробки. Разберем механику, примеры эксплойта и фиксы, чтобы не словить RCE на проде.

Как работает прототипное загрязнение в RSC

React Server Components используют Flight протокол для сериализации компонентов и серверных вызовов между клиентом и сервером. Проблема в react-server пакете: при десериализации RSC пейлоадов сервер не проверяет данные должным образом. Атакер вставляет вредоносный объект, который загрязняет прототипы JS объектов, перехватывая стандартные методы вроде toString или valueOf.

Это приводит к RCE, потому что загрязненный прототип выполняется при обработке. Тестирование показывает 100% reliability эксплойта. В Next.js App Router это бьет по серверным эндпоинтам, включая дефолтные конфиги без кастомного кода. Логическая ошибка в десериализации позволяет переводить клиентские данные прямо в серверный код.

• Flight протокол уязвим: Сериализованные DOM элементы или функции десериализуются без санитизации, открывая путь к proto манипуляциям.
• Next.js наследует баг: App Router использует те же react-server-dom-* пакеты, так что любой билд для продакшена эксплуатируем.
• CVSS 10.0: Pre-auth RCE - полный доступ к FS, кража ключей, латеральное движение.

Версии	Статус	Фикс
React 19.0-19.2	Уязвимы	Обновить до патча
Next.js 15.x-16.x	Уязвимы	15.0.1+ или 16.0.1+
Canary 14.3.0+	Уязвимы	Перейти на stable

Эксплойт через App Router: реальные сценарии

В Next.js App Router RSC эндпоинты открыты по дефолту. Атакер шлет POST на /rsc endpoint с payload, где proto.constructor.constructor(‘evil code’)() выполняется на сервере. Без доп. проверок это дает shell с правами процесса Node.js. Даже если нет явных server functions, фреймворк сам wire’ит react-server пакеты.

Эксплойт надежен: crafted HTTP запрос вызывает unsafe deserialization. В продакшен билде из create-next-app это работает без изменений кода. Затрагивает не только Next.js - React Router RSC, Waku, RedwoodSDK, Vite/ Parcel плагины тоже в зоне риска. Прототипное загрязнение бьет по core логике перевода пейлоадов в вызовы.

1. Payload crafting: Вставь { proto: { constructor: { constructor: Function } } } в RSC stream.
2. RCE цепочка: Загрязни toString, вызови на сервере - код выполняется.
3. Impact: Доступ к DB, API keys, pivot в сеть.

// Пример упрощенного payload (не для копипаста!)
const evilPayload = {
  __proto__: {
    valueOf: () => eval('require("child_process").execSync("id")')
  }
};
// Отправить как RSC chunk в Flight формате

Защита и миграция: патчи и best practices

React выпустил фиксы 3 декабря 2025 - обнови react-server-dom-webpack/server до патченных версий. Next.js трекает как CVE-2025-66478, фикс в 15.x/16.x патчах. Проверь lockfile на уязвимые deps. В дефолтных apps просто npm update, но в кастомных - аудит RSC endpoints.

Если App Router must-have, добавь middleware для валидации RSC пейлоадов. Отключи публичные RSC если не юзаешь. Тестируй в staging: curl’ом симулируй эксплойт. Фиксы решают десериализацию, но мониторь новые CVEs - RSC еще сырой.

Решение	Сложность	Эффект
Update React/Next	Низкая	Полный фикс
Disable RSC endpoints	Средняя	Временный хак
Payload validation	Высокая	Extra security

• Audit deps: npm ls react-server-dom-webpack - найди уязвимые версии.
• CI/CD check: Добавь vulnerability scanner в pipeline.
• Важно: Даже после апдейта рестарт сервера обязателен.

Что меняет RCE в RSC для стека

Прототипное загрязнение в Flight показывает слабости RSC архитектуры. Фиксы закрывают дыру, но подчеркивают риски deserialization в SSR. Next.js App Router теперь требует строгого аудита пейлоадов. Остается открытым: как фреймворки интегрируют upstream без ревью?

Дальше думай о sandboxing серверных компонентов или переходе на verified payloads. Экосистема растет - Parcel, Vite plugins тоже патчат. Это напоминание: в RSC стэке security first, бандл second.