Vulnérabilité d'exécution de code à distance (RCE) dans React et Next.js

 (github.com/vercel)
8 points par GN⁺ 2025-12-04 | 1 commentaires | Partager sur WhatsApp
  • Une vulnérabilité de sécurité permettant une exécution de code à distance (RCE) a été signalée dans React et Next.js
  • Le problème provient du package Next.js ; un attaquant peut provoquer l’exécution de code arbitraire en envoyant une entrée malveillante
  • Vercel a rendu publique la vulnérabilité via l’avis de sécurité GitHub (GHSA-9qr9-h5gf-34mp) et a publié une version mise à jour
  • Les utilisateurs doivent effectuer une mise à niveau vers la dernière version pour réduire ce risque
  • Ce cas rappelle l'importance d'une gestion de la sécurité au niveau du framework

Vue d'ensemble de la vulnérabilité RCE

  • Une vulnérabilité permettant l’exécution de code à distance a été découverte dans les environnements Next.js et React
    • Il existe un risque qu’un attaquant puisse exécuter du code JavaScript arbitraire côté serveur
  • Cette vulnérabilité survient dans le flux de traitement du code interne du package Next.js
    • Les détails sur les fonctions ou modules spécifiques touchés n’ont pas été rendus publics

Impact et réponse

  • Vercel a officiellement annoncé le problème via l’avis de sécurité GitHub (GHSA-9qr9-h5gf-34mp)
    • Cet avis a été publié dans la section des avis de sécurité du dépôt Next.js
  • Les versions touchées n’ont pas été précisées, mais une version corrigée a été déployée
    • Il est recommandé aux utilisateurs d’effectuer une mise à niveau vers la dernière version stable

Recommandations de sécurité et actions

  • Tous les projets utilisant le package Next.js doivent vérifier immédiatement leur version
    • La version de Next.js dans package.json doit être maintenue à jour
  • En dehors de la publication de la version corrigée, Vercel n’a pas mentionné de mesures d'atténuation supplémentaires
  • Les détails techniques de la vulnérabilité restent non divulgués, seules des informations limitées ont été fournies pour des raisons de sécurité

Importance

  • Cette vulnérabilité illustre le risque d'exécution de code dans un environnement de rendu côté serveur
  • Les opérateurs de services basés sur React et Next.js doivent appliquer régulièrement les mises à jour de sécurité
  • Une vulnérabilité au niveau du framework peut avoir un impact direct sur la sécurité globale de l’application

À lire aussi

1 commentaires

 
GN⁺ 2025-12-04
Avis Hacker News

  • Cette vulnérabilité est un cas où le pire scénario redouté depuis l’introduction de RSC/server actions est devenu réalité
    Le serveur désérialisait tel quel une entrée non fiable du client pour retrouver et exécuter un module ainsi qu’un nom d’export
    On peut la bloquer avec un correctif sur hasOwnProperty, mais le problème de fond est qu’on n’avait pas clairement pris conscience que React construisait en réalité une couche RPC
    Les frameworks RPC traditionnels comme gRPC ou SOAP définissent clairement les frontières via des schémas explicites et des définitions de service, alors que React est plus risqué parce qu’il expose toutes les API visibles par le bundler
    Il est probable que des problèmes de sécurité liés à cette conception se reproduisent à l’avenir

    • Cela ressemble simplement à un problème de négligence
      Même avec un schéma explicite, cela ne sert à rien si, à la dernière étape, une entrée non fiable peut référencer n’importe quel objet dans l’espace de noms du serveur
    • En pratique, tous les endpoints demandés par le client ne sont pas exposés
      Seules les fonctions marquées avec "use server" sont exposées, et l’équipe React est consciente qu’elle conçoit un système RPC
      Ce type de bug peut tout à fait survenir dans d’autres systèmes RPC également (je contribue à React)
    • Le fait que cela soit arrivé malgré les avertissements ne peut finalement être vu que comme une implémentation négligente
    • Du point de vue d’un utilisateur ordinaire, on peut se demander si l’on est en sécurité tant qu’on n’utilise pas cette approche
      Mais conserver un vieux dépôt privé n’est pas non plus une bonne option

  • Next n’a pour seul avantage que son build statique
    Si cette prise en charge disparaît, il n’y a plus vraiment de raison de l’utiliser

  • Selon l’avis de sécurité de Facebook/Meta, les versions 19.0.0 à 19.2.0 de React Server Components présentent une vulnérabilité de remote code execution (RCE) pré-authentification
    L’annonce du blog officiel de React explique aussi que, du fait de l’architecture permettant au client d’appeler des fonctions serveur, un attaquant peut forger une requête HTTP malveillante et exécuter du code arbitraire sur le serveur

    • Si la correction consiste à ajouter un contrôle hasOwnProperty, l’attaque passait probablement par une référence à des propriétés de la chaîne de prototypes (__proto__, etc.)
    • Si la phrase « le client peut appeler des fonctions serveur » décrit bien le fonctionnement prévu, cela donne l’impression d’une conception assez effrayante

  • Le correctif semble être ce commit
    Il semble avoir été squashé avec plusieurs autres changements, ce qui masque les détails
    On voit à quatre endroits dans le code un modèle qui limite la liste des fonctions exposées selon une liste blanche

    • Ou alors la cause pourrait être ce commit (« correction d’une vulnérabilité de sécurité critique » explicitement mentionnée)

  • Vercel bloque déjà les modèles de requêtes malveillantes via une protection au niveau de la plateforme
    Voir l’annonce
    Cloudflare a également réagi de manière préventive avec des règles WAF

    • Des mesures d’atténuation préventives ont été déployées en coopération avec plusieurs partenaires
      Malgré cela, il est fortement recommandé de mettre immédiatement à jour les dépendances Next, React et les autres méta-frameworks
    • L’annonce de réponse de Netlify ainsi que le billet de blog sur Deno Deploy/Subhosting méritent aussi le détour
    • J’ai appliqué le correctif moi-même et recompilé, et j’ai aussi ajouté des règles WAF Crowdsec pour couvrir un éventuel oubli

  • J’ai essayé de reproduire la vulnérabilité à partir du dépôt PoC

    • La RCE s’exécute encore même avec react-server-dom-webpack corrigé, donc le mécanisme ne semble pas complètement exact
      Ce serait bien d’avoir une démo sur un vrai projet Next.js
    • Cela dit, l’article qui résume tout cela était vraiment impressionnant

  • Au point qu’on en vient à dire « pas de Vercel, pas de RCE » : cet incident met en lumière la corrélation entre environnement d’hébergement et sécurité

  • Un score CVE de 10.0 est une valeur sidérante pour un projet aussi largement utilisé

    • Le paquet affecté react-server-dom-webpack indique qu’il est « expérimental » et qu’il faut l’utiliser à ses risques et périls
      Malgré cela, il dépasse les 310 000 téléchargements hebdomadaires
    • Dans ce genre d’incident, il faut afficher clairement le CVSS 10.0 pour éviter qu’il soit noyé sous des déclarations de relations publiques
    • React est très répandu, mais React Server Components ne l’est pas encore autant

  • Il est difficile de comprendre pourquoi l’équipe React consacre du temps à des fonctionnalités aussi confuses
    On peut se demander ce que cela apporte de mieux que le SSR, et dans quelle mesure les performances s’améliorent réellement
    L’expérience développeur s’est dégradée depuis l’introduction des hooks, et au lieu de l’améliorer, on ajoute encore de la complexité
    J’aimerais plutôt qu’on permette d’utiliser plus naturellement le flux de contrôle natif de JS dans la logique des composants

    • Les Server Components n’ont pas de lien direct avec le SSR
      Je vois cela comme une couche BFF (Backend for Frontend) composantisée
      Chaque fragment d’interface est directement relié à la logique backend correspondante et peut récupérer des données sans appel à fetch
      Cela facilite l’évolution conjointe du front et du backend, tout en permettant de charger finement uniquement les données nécessaires
      Au final, cela permet d’intégrer naturellement une logique serveur dédiée à l’UI dans la structure des composants
    • Il est regrettable que React soit devenu le « framework par défaut »
      Le modèle basé sur compilateur de Svelte ou de React est bien plus simple à manier
    • Fondamentalement, je pense que le problème vient des limites du langage JS et de l’absence de concurrence
      Vue, Svelte, Angular, etc. exigent tous un compilateur séparé et une extension de fichier dédiée
      En revanche, React/JSX bénéficie déjà d’un traitement de faveur au stade du préprocesseur
      Rust a résolu ce genre de problème avec son système de macros — par exemple, Leptos ou Yew prennent en charge JSX ou des templates HTML dans des fichiers .rs standard
      Si JS n’acquiert pas ce type d’extensibilité, le web risque de rester encore longtemps un environnement complexe et inefficace
    • Moi, j’aime les hooks :)
    • RSC est une tentative de remplacement née de l’incapacité à rendre le SSR rapide
      L’objectif était de réduire la charge côté client, mais on a l’impression que cela aussi a échoué

  • L’explication détaillée du blog React vaut également le coup d’œil