Après React2Shell : trois frontières de sécurité indispensables à toute revue de composants serveur

L’erreur coûteuse : traiter un correctif comme une évaluation complète

React2Shell, CVE-2025-55182, a été révélée le 3 décembre 2025 comme une exécution de code à distance sans authentification dans React Server Components. React crédite Lachlan Davidson pour la découverte. L’avis officiel classe le problème comme une désérialisation non sûre. [1, 6]

Pour un responsable produit, la question utile est de savoir si le service déployé peut transformer en toute sécurité une requête externe en travail côté serveur. Cet article propose une revue en trois frontières : valeurs autorisées, opérations autorisées et consommation de ressources autorisée. Il s’agit d’une analyse éditoriale des sources publiques citées, vérifiées le 4 octobre 2026, et non de la revendication d’avoir découvert ou reproduit ces vulnérabilités.

Établir l’exposition à partir du déploiement, pas du nom du produit

Recensez l’intégration RSC et les paquets react-server-dom-webpack, react-server-dom-parcel ou react-server-dom-turbopack réellement résolus. Une application React sans exécution côté serveur ni intégration compatible RSC sort du périmètre de l’avis d’origine. L’absence de Server Function écrite explicitement ne prouve pas, à elle seule, qu’un déploiement RSC n’est pas concerné. [1]

Consignez l’image de production ou l’identifiant de déploiement, la résolution des dépendances, la configuration du framework et les gestionnaires de requêtes accessibles. Un checkout de développeur déjà corrigé ne prouve pas ce qu’exécute un ancien déploiement, un environnement de preview ou une image de rollback. Distinguez « le paquet est présent », « la version vulnérable est présente » et « le chemin de code pertinent est atteignable » : ce sont trois affirmations différentes, chacune exigeant sa propre preuve.

Première frontière : les octets ne doivent devenir que des valeurs autorisées

La désérialisation va au-delà de vérifier qu’une requête ressemble à du JSON. Un décodeur peut reconstruire des références, interpréter des types ou résoudre des valeurs différées. La question de revue est de savoir quelles significations un attaquant peut amener le serveur à construire avant que l’application n’ait validé la requête. Suivez cette transformation à travers l’intégration réelle du framework, plutôt que de supposer que le gestionnaire métier reçoit des valeurs primitives inoffensives.

Le modèle ci-dessous est une aide à la revue, ni le graphe d’appels interne de React ni une recette d’exploitation. Identifiez les types de valeurs acceptés, le traitement des références et les chemins d’erreur. Testez des entrées malformées et ambiguës dans un environnement isolé via les points d’entrée documentés. Une petite requête rejetée ne devrait pas laisser un état partiellement reconstruit qu’une autre requête pourrait réutiliser. Cette dernière condition est un invariant à examiner dans votre produit, pas une accusation portée contre ces CVE.

HTTP input
  -> [1] decode into permitted values
  -> [2] authorize the requested operation
  -> [3] execute within an explicit work budget
  -> produce a permitted response

Review invariants:
  malformed input -> bounded rejection
  unauthorized operation -> no state change
  excessive work -> bounded termination
  error response -> no sensitive implementation data

Deuxième frontière : une fonction appelable n’est pas une opération autorisée

La documentation de React sur les Server Functions explique comment les appels côté client deviennent des requêtes réseau qui invoquent du code serveur. Cette capacité de transport ne fournit pas les permissions au niveau des objets de votre produit. [5] Pour une fonction qui modifie une facture, le serveur doit établir qui appelle, à quel tenant appartient la facture, et si ce principal est autorisé à effectuer précisément cette transition d’état.

Utilisez une matrice de permissions avec un visiteur anonyme, un membre du bon tenant, un membre d’un autre tenant et un compte en lecture seule. Vérifiez à la fois la réponse renvoyée et l’état stocké. Rejeter une requête après que la mise à jour a déjà eu lieu constitue une rupture de la frontière d’autorisation, même si le statut HTTP paraît rassurant. Répétez ces contrôles pour les appels indirects, les opérations groupées et les identifiants alternatifs que votre application accepte réellement.

Troisième frontière : une entrée valide peut tout de même exiger un travail inacceptable

CVE-2026-23864, révélée le 26 janvier 2026, couvre des cas supplémentaires de déni de service dans RSC. Les mainteneurs décrivent des conséquences telles qu’une utilisation excessive du CPU, un épuisement de la mémoire et des plantages de processus. [3] React précise que ces problèmes ultérieurs n’ont pas rouvert la vulnérabilité d’exécution de code à distance de React2Shell. Distinguez les propriétés que couvre chaque correctif. [2]

Une limite de taille de requête mesure les octets entrants ; elle ne borne pas directement le travail que ces octets déclenchent. Examinez l’expansion des références, la résolution répétée, les appels avals et le comportement d’annulation là où ces mécanismes existent. Choisissez des limites réalistes de CPU, de mémoire, de concurrence et de délai d’achèvement pour le produit. Un timeout n’est utile que si le travail sous-jacent s’arrête réellement. Utilisez un environnement de test et des seuils d’interruption prédéfinis ; épuiser délibérément un processus de production n’est pas un test de recette utile.

Examinez la réponse de production, y compris le contenu du bundle

CVE-2025-55183 concerne l’exposition du code source dans certaines configurations de Server Functions. L’avis décrit comme à risque les secrets codés en dur dans le code exposé ; il n’établit pas une fuite générale des valeurs de variables d’environnement d’exécution via cette faille précise. L’inlining du bundler peut influer sur le code source visible dans l’artefact de production. [4, 2]

Examinez les valeurs renvoyées, les conversions implicites en chaîne de caractères, les erreurs et le corps compilé de la fonction. Utilisez un marqueur inerte dans un build de test dédié pour vérifier si des détails d’implémentation franchissent la frontière de la réponse. Un résultat négatif pour un marqueur constitue une preuve limitée, pas la démonstration que tous les chemins de réponse sont sûrs. Séparez ce contrôle de l’investigation d’un incident de RCE, où un processus compromis peut avoir un accès bien plus large aux secrets.

Construisez un registre des frontières que vos développeurs pourront reproduire

Le registre ci-dessous relie une route et le build déployé à un principal, une classe d’entrée, un résultat attendu et des preuves observées. C’est un modèle de rapport proposé. Remplissez-le avec des mesures réelles, plutôt que de présenter une attaque théorique comme une vulnérabilité confirmée. Pour chaque opération rejetée, indiquez l’absence de changement d’état ; pour chaque test de ressources, indiquez quand le travail a cessé et quelles limites ont été appliquées.

L’avis de janvier 2026 cite 19.0.4, 19.1.5 et 19.2.4 comme correctifs pour les paquets RSC concernés. Ce sont des seuils historiques de correctif, pas une recommandation de figer un déploiement sur ces versions, ni l’affirmation qu’aucun avis ultérieur n’existe. [3] Choisissez une version du framework actuellement maintenue et corrigée, reconstruisez et redéployez, puis vérifiez les paquets résolus et le comportement pertinent dans cet artefact précis.

route_id | deployed_build | package_versions
principal | tenant | object | requested_operation
input_class | expected_result | observed_result
cpu_time | peak_memory | downstream_calls
state_before | state_after | reviewer | evidence_ref

Ce qu’une évaluation utile doit apporter au responsable produit

Demandez une décision claire sur l’exposition, les preuves de dépendances et de déploiement qui l’étayent, ainsi que des conclusions distinctes sur le décodage, les permissions, l’usage des ressources et les fuites dans les réponses. Chaque vulnérabilité devrait indiquer ses préconditions, le flux concerné, sa reproduction dans l’environnement convenu, son impact pratique et des critères de vérification. Une liste impressionnante de noms de CVE ne remplace pas ce lien avec votre application.

Pour une mission ciblée, choisissez un flux à forte valeur, comme la facturation, l’administration des comptes ou l’accès aux données d’un tenant. Combinez la revue de code source avec des contrôles comportementaux convenus, conservez le registre des frontières et retestez le déploiement corrigé. La même séparation entre signification, autorité et budget de travail est utile pour examiner la désérialisation Java ou les parseurs natifs, même si leurs mécanismes et vulnérabilités doivent être étudiés indépendamment.