Déroulement de l'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érent (then)

Le then: "$1:__proto__:then" crée une auto-référence qui se résout en une vraie fonction :``` $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! ... );

Étape 1 : Le then autoréférentiel de l'objet extérieur déclenche le traitement des morceaux

Étape 2 : Lorsque React résout le modèle, il analyse value et rencontre un autre thenable avec then: "$B1337". Le préfixe $B déclenche le gestionnaire :```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. Une Map vide satisfait ces appels sans erreur, permettant à l'exécution d'atteindre le gestionnaire $B vulnérable.

Chemins de code vulnérables

decodeReply() est le point d'entrée, non vulnérable en lui-même.

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

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

2. hasOwnProperty check in getOutlinedModel() - Bloque le parcours du prototype ```javascript hasOwnProperty.call(value, name) && (value = value[name]);
   root@kitploit:~

3. Gestion de __proto__ 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 et 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 basée sur les signatures des WAF échoue

Cette section explique pourquoi les règles traditionnelles de correspondance de motifs des WAF 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 central : Encodage à plusieurs couches

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 le traitement :

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 à quoi les signatures devraient correspondre

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

Le code JavaScript à l'intérieur de la charge utile a 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 ne voit que des séquences d'échappement et des nombres - rien qui ne corresponde aux signatures d'attaque traditionnelles.

Pourquoi cela est important 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 au protocole - Tous les encodages sont valides selon les spécifications JSON/JavaScript

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

L'en-tête Next-Action identifie les requêtes d'actions serveur. Bien que les noms d'en-tête 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 failles de détection :

Recommandations défensives

Le correctif est la seule atténuation fiable. Les règles WAF ne peuvent pas bloquer de manière exhaustive cette attaque en raison de la flexibilité de l'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+

En cas de report du correctif, envisagez :

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

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

Contournement des limites d'inspection du corps de la requête AWS WAF

Même avec des règles WAF complètes, AWS WAF a 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 n'inspecte qu'une partie du corps de la requête :

Le problème de OversizeHandling

Les règles WAF spécifient comment gérer 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 : Remplissage avant la charge utile

Placez des données de remplissage inoffensives avant la charge utile d'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 morceaux :``` 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 du WAF

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

Recommandations d'atténuation

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

Cela bloque toute requête dépassant la limite d'inspection lorsque les conditions de 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 l'ACL web, mais cela ne prévient pas complètement le contournement.

3. Ajouter une règle de blocage basée sur la taille Bloquez les requêtes POST dont l'en-tête Next-Action dépasse une taille raisonnable (par exemple, 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 de base sans fragmentation
• test-oversize.cjs - Teste les tailles de remplissage de 0 à 128 Ko
• test-chunked-v2.cjs - Encodage de transfert fragmenté avec division par $@
• test-chunked-bypass.cjs - Plusieurs stratégies de fragmentation (5 octets, 10 octets, divisions par motifs)

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

Avec le payload "$1:constructor:constructor":

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

Chemins bloqués que nous avons tentés

Bien que nous ayons obtenu Function, parvenir à une RCE nécessite de l'appeler avec des arguments contrôlés. Ces chemins ont échoué :

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

3. Chemin de l'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