Mise à jour pour la vulnérabilité RCE des composants du serveur React (CVE-2025-55182 / CVE-2025-66478) – Sécurité des API

Le paysage des attaques a été dynamique suite à la divulgation de la vulnérabilité RCE de React Server Components. De nouvelles informations sont apparues concernant l'exploit de validation de concept initial, ainsi que les méthodes de détection améliorées, les mécanismes d'exploitation observés dans la nature et l'activité d'attaque en croissance rapide. Cette mise à jour résume les changements et les observations que nous avons effectués auprès des clients Wallarm.

Le premier exploit PoC n’était pas réel

Peu de temps après la révélation de la vulnérabilité, l’un des premiers PoC a commencé à circuler sur GitHub. Il a été confirmé par la suite que ce PoC n’était pas un véritable exploit pour CVE-2025-55182. Au lieu de cela, il s'agissait d'une tentative de recherche inexacte simulant par inadvertance un serveur vulnérable en enregistrant manuellement des modules dangereux tels que fs, child_processet vmquelque chose que les applications RSE du monde réel ne feraient jamais.

Même après qu'il ait été publiquement clarifié que le PoC n'était pas valide, les tentatives d'exploitation utilisant ce format PoC ont continué à se multiplier et Wallarm a observé des attaques automatisées généralisées basées sur ce modèle jusqu'aux 3 et 4 décembre.

Étant donné que de nombreux attaquants se contentent de réutiliser ou d'automatiser tout ce qui est étiqueté « PoC », des référentiels incorrects ou trop simplifiés peuvent toujours générer d'importantes vagues de trafic malveillant.

Des utilitaires émergent pour analyser les déploiements vulnérables

Le 4 décembre, les chercheurs d'Assetnote Security ont publié une analyse technique détaillée de la vulnérabilité et ont introduit un utilitaire Python pour détecter les implémentations vulnérables de RSC et Next.js.

Cette version de l'utilitaire a considérablement amélioré la capacité d'identifier les packages vulnérables et les configurations de serveur, tant pour la communauté professionnelle que pour les attaquants.

Semblable à l’article précédent sur PoC, la sortie de ces utilitaires d’analyse a provoqué une augmentation de l’activité d’attaque. Au cours des premières heures, Wallarm a enregistré plus de 5 500 nouvelles tentatives d’exploitation, dont beaucoup reflétaient directement la structure de l’outil d’analyse.

La méthode de numérisation a été rapidement adaptée pour :

• scanners communautaires indépendants
• Modèles de base
• scripts personnalisés issus du code Assetnote

Ces variantes se sont rapidement répandues et ont été largement utilisées les 4 et 5 décembre, dépassant dans de nombreux cas le volume de tentatives d'exploitation réelles, comme le montre le graphique plus loin dans cet article de blog.

Premiers véritables exploits RCE pour CVE-2025-55182

Même si le PoC initial n’était pas valide, la véritable chaîne d’exploitation RCE pour CVE-2025-55182 est devenue disponible par la suite. Elle repose sur l’abus d’une résolution d’exportation non sécurisée au sein du processus de désérialisation des actions RSE.

La charge utile exploite la façon dont les composants de React Server désérialisent et résolvent les champs de métadonnées, permettant à un attaquant de traverser la chaîne de prototypes JavaScript et finalement d'exécuter du code arbitraire sur le serveur. Chaque champ de la charge utile contribue à façonner l'objet afin qu'il soit accepté par le runtime RSC et capable d'activer l'évaluateur. Les principaux composants sont :

• then: "$1:__proto__:then" — Établit une auto-référence alors faisable structure qui force le désérialiseur à parcourir le __proto__ chaîne, exposant les propriétés héritées au lieu de limiter la résolution aux références d’actions sûres.
• status: "resolved_model" — Marque l'objet comme un fragment de modèle de composant React Server valide à traiter sans être rejeté par la validation structurelle.
• reason: -1 — Manipule la gestion des références internes en provoquant la résolution de la référence racine de manière à éviter les conflits lors de la désérialisation.
• value: "{\"then\":\"$B1337\"}" — Contient une charge utile imbriquée conçue pour invoquer le $B contrôleur, qui influence la façon dont les données du modèle sont interprétées et permet un meilleur contrôle sur le flux de désérialisation.
• _response._prefix — Contient le fragment d'exécution de code à distance réel. Dans cet exemple, le code injecté utilise process.mainModule.require('https') pour émettre une requête sortante vers un domaine contrôlé par un attaquant, qui sert de confirmation hors bande de l'exécution réussie du code.
• _response._chunks: "$Q2" — Fournit une carte de fragments vide, qui évite les erreurs de désérialisation et garantit que la charge utile est traitée comme structurellement valide.
• _response._formData.get: "$1:constructor:constructor" — Rediriger le get l'accès à la Function constructeur traversant la chaîne de prototypes (constructor → constructor). Il s'agit de l'étape critique qui convertit la chaîne fournie par l'attaquant en _prefix en JavaScript exécutable.

Ensemble, ces éléments exploitent les lacunes du processus de résolution du modèle RSC, permettant à un attaquant de transformer des métadonnées inoffensives en une charge utile JavaScript entièrement exécutée au sein du runtime Node.js. Le résultat est une primitive RCE fiable en mémoire qui ne nécessite pas d'écriture de fichiers sur le disque et ne persiste que jusqu'au redémarrage du processus.

Techniques de violation de données

À mesure que les techniques d’exploitation ont évolué, les charges utiles ont évolué pour renvoyer les résultats des commandes sur plusieurs canaux. Les trois méthodes principales sont détaillées ci-dessous, ainsi que les mécanismes techniques qui les sous-tendent.

Sortie du corps de réponse

La charge utile intègre le résultat de la commande directement dans le champ récapitulatif RSC sérialisé, par exemple :

{ digest: `${res}` }

Une fois désérialisé, le serveur renvoie le résultat de la commande dans le corps de la réponse HTTP. Cela fournit une sortie directe et interactive avec une complexité de charge utile minimale.

Certaines variantes injectent le résultat de la commande dans un objet d'erreur utilisé par les redirections internes Next.js :

Object.assign(new Error("NEXT_REDIRECT"), { digest: `NEXT_REDIRECT;push;/login?a=${res}` })

Étant donné que le framework reflète la valeur du résumé dans des en-têtes HTTP spécifiques, cela permet l'exfiltration même lorsque le corps est écrasé ou nettoyé.

Rappel OAST/DNSLog

Pour une exfiltration complètement hors bande, la charge utile utilise les éléments internes du nœud pour lire et transmettre des données :

• process.mainModule.require('fs') → lire des fichiers ou une sortie de commande
• process.mainModule.require('https') → envoie les données à un point de terminaison OAST/DNSLog contrôlé par l'attaquant

Shell de mémoire d'exécution

Une autre technique intéressante a été publiée, démontrant comment les attaquants peuvent exploiter les failles de désérialisation RSC pour créer un webshell en mémoire en abusant du comportement du prototype JavaScript. La méthode permet l’exécution de code arbitraire sans rien écrire sur le disque, ce qui la rend furtive et efficace.

Comment fonctionne la technique :

• Utilise les métadonnées RSC conçues pour obtenir des propriétés de chaîne de prototype telles que __proto__ et constructor.constructor.
• Cela intensifie l'accès à de puissants constructeurs JavaScript capables d'exécuter du code arbitraire.
• Le script injecté importe les modules principaux de Node.js (http, url, child_process) pour un contrôle plus approfondi.
• Annulations http.Server.prototype.emit pour intercepter toutes les requêtes HTTP entrantes.
• Ajoutez un point de terminaison masqué comme /exec?cmd= qui exécute des commandes en utilisant child_process.execSync.
• Il en résulte un webshell en mémoire qui persiste jusqu'au redémarrage du processus serveur et ne laisse aucune trace sur le disque.

Observations de Wallarm et statistiques d'exploitation

Wallarm continue de surveiller les activités d'exploitation dans les environnements clients. Les principales observations comprennent :

• Trafic PoC invalide : Bien qu'elle ait été démystifiée, l'utilisation du format PoC incorrect a doublé le 4 décembre par rapport au 3 décembre et s'est poursuivie jusqu'au 5 décembre.
• Attaques de scanner : Après qu'Assetnote ait publié son utilitaire d'analyse, la communauté l'a rapidement adapté, ce qui a entraîné environ 5 500 attaques au cours des premières heures, le trafic d'analyse des 4 et 5 décembre dépassant les tentatives d'exploitation réelles.
• Charges utiles RCE réelles : Une fois que les détails techniques précis sont devenus publics, de véritables exploits RCE ont commencé à apparaître, y compris des hybrides combinant la logique du scanner avec des modèles d'exploit (que Wallarm détecte et bloque avec succès à l'aide des protections spécifiques RSC existantes et mises à jour).

Tentatives d’exploitation utilisant les techniques de contournement WAF/WAAP

Alors que la plupart des tentatives d’exploitation reflétaient simplement le format PoC d’origine, Wallarm a également observé un certain nombre de tentatives plus avancées visant à contourner les contrôles de sécurité. Les exemples incluent :

• Remplissez les charges utiles avec du Big Data non pertinent pour contourner les produits WAF/WAAP qui inspectent uniquement la première partie d'une requête ou qui ont du mal à gérer des charges utiles volumineuses.
• Petites mutations structurellescomment changer ["$1:a:a"] à ["$1:aa:aa"]ce qui peut éviter les WAF qui reposent sur des signatures statiques.
• Ajoutez des données binaires à la requête en plusieurs parties. Dans la demande d'exploitation suivante, l'attaquant a inséré des données binaires à haute entropie dans le premier segment du corps en plusieurs parties. Cette technique tire parti du fait que de nombreuses solutions WAF/WAAP réduisent ou omettent l'inspection des charges utiles binaires pour éviter les faux positifs, permettant ainsi au contenu malveillant qui suit d'éviter une analyse plus approfondie.

Ces variations soulignent que les attaquants expérimentent déjà des stratégies d'évasion, renforçant la nécessité d'une détection basée sur le comportement plutôt que d'une simple correspondance de signatures.

Résistance de Wallarm aux techniques d'obscurcissement

Le WAAP de Wallarm résiste à toutes ces méthodes d’évasion. Sa détection des attaques basée sur les tampons surpasse la correspondance de signatures statiques et évite les problèmes de performances des approches basées sur les expressions régulières, permettant une inspection rapide des charges utiles volumineuses ou obscurcies avec une faible latence.

La détection brevetée basée sur les tampons de Wallarm est plus flexible que la simple correspondance de chaînes statique, permettant au système de reconnaître les modèles d'exploitation même lorsque les attaquants modifient ou réorganisent les charges utiles. Les tampons s'exécutent également beaucoup plus rapidement que les expressions régulières traditionnelles, en particulier lorsque plusieurs règles doivent être évaluées en même temps. Alors que de nombreux WAF ont du mal (ou échouent tout simplement) à inspecter les requêtes volumineuses, et que certains ne peuvent pas traiter des charges utiles dépassant 64 Ko, voire 8 Ko, Wallarm est conçu pour gérer efficacement des entrées volumineuses et très obscurcies, tout en maintenant une latence minimale sous de lourdes charges.

De plus, Wallarm effectue une analyse approfondie et récursive de toutes les demandes entrantes, garantissant que chaque composant est analysé, quelle que soit sa structure ou son codage. La précision de la détection reste élevée car une logique basée sur des tampons est appliquée à chaque paramètre et élément imbriqué.

Wallarm est également très résistant aux techniques courantes de contournement du WAF. Plusieurs couches d'encodage et d'obscurcissement sont automatiquement normalisées et décodées avant inspection, empêchant les attaquants de cacher des charges utiles malveillantes à l'aide d'astuces de transformation.

Enfin, Wallarm offre une couverture complète sur plusieurs protocoles API (y compris REST, GraphQL, SOAP, gRPC et WebSockets) et inspecte tous les paramètres de requête tels que les URI, les en-têtes, le corps, les segments en plusieurs parties et même JWT, garantissant une protection cohérente quel que soit l'endroit où une charge utile est introduite.

Capacités de détection d'alarme

Malgré la détection et le blocage des tentatives d'exploitation au niveau du trafic, Wallarm utilise également des approches supplémentaires pour révéler à la fois les instances vulnérables et les preuves d'exploitation :

• Gestion de la surface d'attaque (AASM) : Il utilise une approche d'analyse active pour identifier les technologies vulnérables sur les hôtes connectés à Internet, y compris celles non protégées par le filtrage Wallarm.
• Système de détection passif : Analyse passivement le trafic des applications à la recherche d'indicateurs de tentatives d'exploitation réussies, aidant ainsi à découvrir des incidents qui autrement passeraient inaperçus.