CVE-2025-55182-research

Технический proof-of-concept и углубленный анализ CVE-2025-55182, критической уязвимости RCE в React's Flight Protocol через обход пути, внедрение поддельных фрагментов и злоупотребление обработчиком $B.

Поток эксплуатации```

┌─────────────────────────────────────────────────────────────────────┐ │ 1. Attacker sends multipart form with fake chunk object │ │ → decodeReply() parses form fields 0, 1, 2 │ │ → Object has: then, status, value, _response │ └─────────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────────┐ │ 2. Self-reference makes object thenable with real function │ │ → then: "$1:proto:then" → Chunk.prototype.then │ │ → Chunk.prototype.then(this) calls initializeModelChunk(this) │ │ → Uses this._response (attacker's fake _response) │ └─────────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────────┐ │ 3. parseModelString() handles "$B1337" reference │ │ → case "B": return response._formData.get(response._prefix+id) │ │ → Calls _formData.get with attacker's _prefix + "1337" │ └─────────────────────────────────────────────────────────────────────┘ │ ▼ ┌─────────────────────────────────────────────────────────────────────┐ │ 4. getOutlinedModel() resolves _formData.get (lazy evaluation): │ │ → "$1:constructor:constructor" traverses prototype chain │ │ → Returns Function constructor │ │ → Function(code + "1337") → RCE │ └─────────────────────────────────────────────────────────────────────┘

Self-Referential Thenable (then)

then: "$1:__proto__:then" создает самоссылку, которая разрешается в настоящую функцию:``` $1:proto:then ↓ $1 → chunk 1 → "$@0" → getChunk(0) → Chunk object ↓ Chunk.proto.then → Chunk.prototype.then (actual function!)

5. initializeModelChunk(this) использует this._response - поддельный _response атакующего:```javascript value = reviveModel( chunk._response, // ← attacker's fake _response! ... );

Шаг 1: Самореферентный then внешнего объекта запускает обработку фрагментов

Шаг 2: Когда React разрешает модель, он анализирует value и встречает другой thenable с then: "$B1337". Префикс $B запускает обработчик:```javascript case "B": return response._formData.get(response._prefix + obj); // obj = "1337"

Реактовский внутренний код может обращаться к response._chunks.get() или response._chunks.has() в процессе обработки. Пустой Map удовлетворяет этим вызовам без ошибок, позволяя выполнению дойти до уязвимого обработчика $B.

Уязвимые пути выполнения

decodeReply() является точкой входа, сама по себе не уязвима.

Обход пути (getOutlinedModel()):```javascript for (key = 1; key < reference.length; key++) parentObject = parentObject[reference[key]]; // No validation!

$B Обработчик RCE (parseModelString()):```javascript case "B": return response._formData.get(response._prefix + obj); // RCE!

2. hasOwnProperty проверка в getOutlinedModel() - Блокирует обход прототипа ```javascript hasOwnProperty.call(value, name) && (value = value[name]);
   root@kitploit:~

3. Обработка __proto__ в reviveModel() - предотвращает загрязнение прототипа ```javascript void 0 !== parentObj || "proto" === i ? (value[i] = parentObj) : delete value[i];
   root@kitploit:~

4. Проверка типа в initializeModelChunk() - Проверяет слушателей ```javascript "function" === typeof listener ? listener(value) : fulfillReference(response, listener, value);
   root@kitploit:~

Воздействие и версии

Оценка воздействия

Затронутые версии

• react-server-dom-webpack: 19.0.0, 19.1.0, 19.1.1, 19.2.0
• react-server-dom-turbopack: Те же версии
• Next.js: 15.x, 16.x (до исправлений), канареечные сборки с 14.3.0-canary.77+

Исправленные версии

• React: 19.0.1+, 19.1.2+, 19.2.1+
• Next.js: 15.0.5, 15.1.9, 15.2.6, 15.3.6, 15.4.8, 15.5.7, 16.0.7+

Почему сигнатурное обнаружение WAF не работает

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

Основная проблема: кодирование на нескольких уровнях

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

Это создает фундаментальное несоответствие: WAF видит закодированные байты, но приложение — декодированные строки.

Каким сигнатурам нужно было бы соответствовать

Наивный WAF может искать шаблоны вроде constructor, __proto__, resolved_model или child_process. Однако JSON допускает юникод-экранирование для любого символа:

Код JavaScript внутри полезной нагрузки имеет еще больше вариантов кодирования:

Разрыв в обнаружении

Когда все методы кодирования объединены:

• Ключи JSON становятся юникод-последовательностями (\u0074\u0068\u0065\u006e для then)
• Идентификаторы JS становятся числовыми массивами (S(99,104,105,108,100,95,...) для child_process)
• Исходная полезная нагрузка не содержит ни одного распознаваемого ключевого слова

WAF, сканируя тело HTTP, видит только escape-последовательности и числа — ничего, что соответствует традиционным сигнатурам атак.

Почему это важно для защитников

1. Сигнатурные правила создают ложную уверенность — полезная нагрузка достигает сервера незамеченной
2. Кодирование бесконечно — каждый символ может быть экранирован по-разному; регулярные выражения не могут перечислить все варианты
3. Атака соответствует протоколу — все кодирования являются допустимыми JSON/JavaScript согласно спецификации

Соображения по обнаружению заголовков

Заголовок Next-Action идентифицирует запросы Server Action. Хотя имена заголовков не могут быть юникод-кодированы (RFC 7230 требует токенов ASCII), различия в нормализации между WAF и сервером создают пробелы в обнаружении:

Рекомендации по защите

Установка исправлений — единственная надежная мера защиты. Правила WAF не могут полностью заблокировать эту атаку из-за гибкости кодирования.

Необходимые версии:

• React: 19.0.1+, 19.1.2+, 19.2.1+
• Next.js: 15.0.5+, 15.1.9+, 15.2.6+, 15.3.6+, 15.4.8+, 15.5.7+, 16.0.7+

Если исправление откладывается, рассмотрите:

1. Декодирование перед сопоставлением — WAF должен декодировать \uXXXX, \xXX и нормализовать вызовы fromCharCode() перед сопоставлением с шаблоном
2. Структурное обнаружение — ищите JSON-структуры, содержащие _response, _prefix, _chunks или циклические ссылки ($@0)
3. Нормализация заголовков — сопоставляйте заголовок next-action без учета регистра с обрезкой пробелов
4. Блокировка Server Actions — если не используете Server Actions, полностью блокируйте запросы с заголовком Next-Action
5. Мониторинг времени выполнения — оповещайте о вызовах Function() с динамическими строковыми аргументами

Ключевой вывод: Одно лишь сопоставление с шаблоном не сработает против этого класса атак. Поверхность кодирования слишком велика для перечисления.

Обход ограничений проверки тела запроса AWS WAF

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

Ограничения проверки тела

AWS WAF проверяет только часть тела запроса:

Проблема OversizeHandling

Правила WAF определяют, как обрабатывать запросы, превышающие лимиты проверки:

Если ваше правило WAF использует OversizeHandling: CONTINUE (обычное значение по умолчанию), обход тривиален.

Стратегия обхода: дополнение перед полезной нагрузкой

Разместите безвредные данные-дополнение перед эксплойтом, чтобы они оказались за пределами окна проверки:``` ┌─────────────────────────────────────────────────────────────────┐ │ Multipart Form Body │ ├─────────────────────────────────────────────────────────────────┤ │ [Field: padding] 65KB of 'A' characters │ │ ↑ WAF inspects first 8-64KB (sees only this) │ ├─────────────────────────────────────────────────────────────────┤ │ [Field: 0] {"then":"$1:proto:then", ...} │ │ [Field: 1] "$@0" │ │ [Field: 2] [] │ │ ↑ Exploit payload - beyond WAF inspection limit │ └─────────────────────────────────────────────────────────────────┘

Паттерн разделен по частям:``` Chunk 1 ends with: ..."$ ← WAF sees "$" alone (no match for $@) Chunk 2 starts with: @0"... ← WAF sees "@" alone (no match for $@)

Рекомендации по поведению WAF

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

Рекомендации по смягчению

1. Измените OversizeHandling на MATCH ```json "OversizeHandling": "MATCH"
   root@kitploit:~

Это блокирует любые запросы, превышающие лимит проверки, при соблюдении условий правила.

2. Увеличение лимита проверки тела запроса (только CloudFront/API Gateway) Настройте до 64 КБ в параметрах веб-ACL, но это не полностью предотвращает обход.

3. Добавьте правило блокировки на основе размера Блокируйте POST-запросы с заголовком Next-Action, превышающим разумный размер (например, 10 КБ).

4. Исправьте приложение — единственное полное решение.

Тестовые скрипты

См. прилагаемые тестовые скрипты:

• test-simple.cjs — Базовый тест полезной нагрузки без фрагментации
• test-oversize.cjs — Тестирует размеры дополнения от 0 до 128 КБ
• test-chunked-v2.cjs — Фрагментированная передача с разделением по $@
• test-chunked-bypass.cjs — Несколько стратегий фрагментации (5 байт, 10 байт, разделение по шаблону)

Использование:```bash

Start vulnerable Next.js server (port 3000)

cd nextjs-test && npm run dev

Run tests

node test-simple.cjs # Baseline node test-oversize.cjs # Oversize body bypass node test-chunked-v2.cjs # Chunked $@ split node test-chunked-bypass.cjs # All chunking strategies

С полезной нагрузкой "$1:constructor:constructor":

1. chunk[1]["constructor"] → [Function: Object]
2. Object["constructor"] → [Function: Function]

Заблокированные пути, которые мы пробовали

Хотя мы получили Function, для выполнения произвольного кода (RCE) требуется вызвать его с контролируемыми аргументами. Эти пути не сработали:

1. Thenable путь (заблокирован)```javascript // Attempt: { then: Function } // When awaited, V8 calls: Function(resolve, reject) // resolve.toString() = "function () { [native code] }" // Result: SyntaxError - invalid parameter name

3. Путь итератора (Заблокирован)```javascript // Function.bind(null, code) needs TWO calls to execute // React only calls iterator once // Result: Returns bound function, doesn't execute