CVE et dépendances vulnérables : comment savoir si votre application est exposée

Chaque jour, de nouvelles failles de sécurité sont publiées dans des logiciels que vous utilisez probablement : votre framework web, votre serveur web, une bibliothèque npm transitive dont vous ignorez l'existence. Plus de 40 000 vulnérabilités ont reçu un identifiant CVE au cours de la seule année 2024.

La question n'est pas de savoir si une de vos dépendances aura une faille, mais quand, et si vous le saurez à temps.

Qu'est-ce qu'une CVE ?

Une CVE (Common Vulnerabilities and Exposures) est un identifiant unique attribué à une faille publique, par exemple CVE-2025-55182. Elle est accompagnée :

• d'une description de la faille ;
• des versions affectées du logiciel ;
• de la version corrigée ;
• d'un score de gravité (CVSS), de faible à critique.

Dès qu'une CVE est publiée, elle est lisible par tout le monde, y compris par les attaquants, qui automatisent la recherche de serveurs vulnérables.

Un exemple récent : React2Shell

En décembre 2025, la faille CVE-2025-55182, surnommée React2Shell, a été publiée dans les React Server Components, utilisés notamment par Next.js. Elle permettait d'exécuter du code à distance sur le serveur avec une simple requête.

Les applications corrigées rapidement n'ont rien risqué. Celles restées sur une version vulnérable ont été scannées puis attaquées dans les jours suivants. La différence entre les deux n'était pas la compétence de l'équipe : c'était le fait de savoir que la version installée était vulnérable.

Les trois niveaux à vérifier

1. Les paquets du système

Sur Debian ou Ubuntu, listez les mises à jour de sécurité en attente :

sudo apt-get update && apt list --upgradable 2>/dev/null | grep -i security

Les mises à jour automatiques couvrent ce niveau, à condition qu'elles soient activées et qu'elles fonctionnent.

2. Les logiciels installés manuellement

Un runtime installé hors du gestionnaire de paquets (Node.js via un gestionnaire de versions, un binaire téléchargé) n'est pas mis à jour automatiquement. Vérifiez sa version et comparez-la aux bulletins de sécurité de l'éditeur.

3. Les dépendances applicatives

C'est le niveau le plus oublié. Vos fichiers de verrouillage (package-lock.json, requirements.txt, composer.lock, Gemfile.lock) décrivent exactement ce qui tourne en production.

Les gestionnaires de paquets proposent un audit :

npm audit --omit=dev
pip-audit -r requirements.txt
composer audit

Le problème : ces commandes s'exécutent sur le poste du développeur, au moment où il y pense. La production, elle, peut tourner des mois avec une version qui est devenue vulnérable après le déploiement.

Prioriser : toutes les failles ne se valent pas

Une liste de 80 vulnérabilités n'aide personne. Pour prioriser :

1. Gravité critique ou élevée d'abord.
2. Exposition : une faille dans le framework web exposé sur Internet passe avant une faille dans un outil de développement.
3. Correctif disponible : si la version corrigée existe, la mise à jour est souvent rapide.
4. Exploitation active : une faille déjà exploitée dans la nature est une urgence.

Automatiser la veille

La bonne pratique est de comparer chaque jour les versions réellement installées sur le serveur avec une base publique comme OSV ou la NVD, puis d'être prévenu uniquement quand une faille concerne votre serveur, avec la version corrigée à installer.

Questions fréquentes

Mon hébergeur gère-t-il les mises à jour de mes dépendances ?

Non. L'hébergeur gère au mieux le système d'exploitation dans une offre infogérée. Les dépendances de votre application restent de votre responsabilité.

Une dépendance de développement est-elle un risque ?

Beaucoup moins, si elle n'est pas déployée en production. Concentrez-vous sur ce qui tourne réellement sur le serveur.

Faut-il mettre à jour dès qu'une CVE sort ?

Pour une gravité critique sur un composant exposé, oui, dans les heures ou les jours qui suivent. Pour le reste, regroupez les mises à jour dans un cycle régulier.

FondateurMode compare chaque jour les versions de vos paquets système et de vos dépendances npm, Python, PHP et Ruby aux bases publiques de vulnérabilités, et vous indique la version corrigée. Voir comment ça marche.