Connexion Premium

Faille critique dans le paquet NPM de React Native, la mise à jour s’impose

Une importante faille critique a été découverte dans le paquet NPM React Native Community CLI, très populaire chez les développeurs (de 1,5 à 2 millions de téléchargements par semaine). Présentant un score CVSS de 9,8 sur 10, elle présente une dangerosité quasi maximale et peut être exploitée à distance sur toutes les plateformes Windows, macOS et Linux.

La vulnérabilité a été découverte par jFrog et estampillée CVE-2025-11953. « Cette vulnérabilité permet à des attaquants distants non authentifiés de déclencher facilement l’exécution arbitraire d’une commande du système d’exploitation sur la machine exécutant le serveur de développement de react-native-community/cli, ce qui représente un risque important pour les développeurs », explique l’entreprise.

En outre, et contrairement aux vulnérabilités habituelles découvertes dans les serveurs de développement, la faille CVE-2025-11953 peut être exploitée à distance. Elle réside dans le fait que le serveur de développement Metro, utilisé par React Native pour créer du code et des ressources JavaScript, se lie à des interfaces externes par défaut, au lieu de localhost. Il expose un point de terminaison « /open-url » qui devient alors vulnérable aux injections de commandes du système d’exploitation.

Concrètement, un utilisateur non authentifié peut se servir de la faille pour envoyer une requête POST spécialement conçue au serveur pour lui faire exécuter des commandes arbitraires. Dans le billet de jFrog, on peut lire que les chercheurs ont réussi à exploiter la faille sur Windows avec un contrôle total des paramètres. Sur macOS et Linux, ils sont parvenus à l’exécution de code avec un contrôle limité des paramètres. Cependant, avec des tests supplémentaires, ils estiment pouvoir parvenir au contrôle total.

Cette vulnérabilité critique est présente dans un très grand nombre de versions, de la 4.8.0 à la 20.0.0-alpha.2. Elle est corrigée depuis la version 20.0.0, publiée depuis octobre. Comme souvent dans ce genre de cas, les informations sur la faille n’ont été données qu’une fois que l’éditeur – ici Meta – a pu corriger la faille et qu’un nombre suffisant de développeurs ont récupéré la dernière version.

Seules les personnes utilisant donc une version plus ancienne que la 20.0.0 et utilisant le serveur Metro sont vulnérables. Pour jFrog cependant, cette faille « est particulièrement dangereuse en raison de sa facilité d’exploitation, de l’absence d’exigences d’authentification et de sa large surface d’attaque ».

Commentaires (7)

votre avatar
Sérieusement, le fix pour une CVE de cette ampleur n'est apporté que par une upgrade majeure? Pas de backport? D'autant qu'à ma connaissance, react n'est pas des plus simples à garder à jour (enfin je sais pas pour react-native, j'imagine que c'est pareil). Ca ressemble à du foutage de gueule?

Bon sinon y'a ce workaround:
For improved security, or if upgrading is not possible, bind the development server to the localhost interface explicitly, by including the “–host 127.0.0.1” flag, per the examples below:
npx react-native start --host 127.0.0.1
npx @react-native-community/cli start --host 127.0.0.1
votre avatar
je ne sais pas quel est l'usage chez React, mais en Java le backport n'est pas l'usage classique — j'ai en tête l'exemple de log4shell, qui avait imposé de reprendre l'intégralité des applis utilisant log4j pendant la période de Noël il y a quelques années.
votre avatar
Mais log4j si je ne m'abuse c'est une petite équipe bénévole, alors qu'ici on parle de Meta. On peut avoir des niveaux d'exigence différents en fonction de ça amha. Il y avait aussi cet autre projet (libxml peut-être ?) dont le mainteneur bénévole avait poussé une gueulante face à l'injonction de fixer les CVEs. Je comprends tout à fait ça.
votre avatar
Je vois pas trop en quoi c’est la faute du package. Laisser un serveur de dev en open bar sur le net, c’est ça le problème…
votre avatar
Non, ça c'est le facteur aggravant, mais la CVE à la base c'est un "unsanitized user input" qui conduit au RCE.
Le fait d'ouvrir un serveur sur un poste de dev est classique, pas forcément problématique (ce qui l'est un peu plus c'est le comportement par défaut de binder sur toutes les interfaces et pas seulement localhost, via un simple "npm start" ultra commun)
votre avatar
Malheureusement, pas mal de services ont la mauvaise habitude d'écouter par défaut sur tous les ports disponibles et sans aucun moyen de configurer quoi que ce soit.

Il ne reste que le pare-feux pour limiter la casse dans ce cas.

Et en exemple, il y a le célèbre bind :kill:
votre avatar
C'est peut-être culturel ( je suis actuellement occupé à me coltiner les formations Veracode sur la sécurité - cursus imposé par ma boîte ), mais je dirais bien que la cause principale n'est pas tant d'avoir "oublié" de contrôler la validité de l'input, mais plutôt d'avoir considéré que c'est une super idée de proposer une API permettant à un appelant (même restreint à localhost) d'ouvrir une URL (même "sanitisée") sans autre forme d'autorisation...