Support technique
Documentation
Connexion
Nous contacter
Accédez directement au résumé généré par l'IA de cet article de blog 
Un identifiant CVE s'affiche dans votre terminal, associé à un paquet que vous n'avez jamais installé volontairement, et votre premier réflexe est d'envisager le pire. Nous sommes tous passés par là. Ces codes sont l'équivalent, dans le domaine de la cybersécurité, d'un signal de détresse, et une fois que l'on comprend comment ils sont structurés, ils cessent d'être effrayants et deviennent utiles.
J’ai déjà abordé ce sujet, mais je souhaitais cette fois-ci l’approfondir : ce que les métadonnées vous révèlent réellement, comment une faille peut se manifester via une dépendance que vous n’avez jamais choisie, et comment SecureChain simplifie considérablement la gestion des correctifs. Une véritable vulnérabilité est au cœur de tout cela : la CVE-2026-27606 dans le bundler Rollup.
Qu'est-ce qu'un CVE ?
Autrefois, les vulnérabilités portaient des noms spécifiques au bug lui-même, comme « traversée de chemin IIS », ce qui fonctionnait très bien jusqu’à ce que les failles s’accumulent au fil des décennies et que chaque éditeur et chaque base de données invente son propre nom pour désigner la même chose.
Un identifiant CVE (Common Vulnerabilities and Exposures) est un nom normalisé désignant une faille de cybersécurité connue du grand public. Il offre aux professionnels de la sécurité et aux éditeurs un vocabulaire commun pour désigner une vulnérabilité spécifique. Cela revêt une importance capitale dans les environnements comportant de nombreux composants externes, où l’identification des CVE permet à une équipe de hiérarchiser l’application des correctifs et de corriger les failles avant que quelqu’un ne les exploite.
Considérez un CVE comme un numéro de suivi pour un colis que vous avez commandé en ligne. Ce n'est pas le colis lui-même ; c'est ce qui vous permet (ainsi qu'à tout le monde) de savoir exactement de quel bug il s'agit et quelles versions il affecte.
Deux éléments sont toutefois constamment confondus. L'identifiant CVE n'est qu'une étiquette et ne comporte aucune évaluation de gravité. La fiche CVE qui lui est associée peut indiquer les versions concernées, des références, une catégorie de vulnérabilité et un score de gravité attribué par l'organisme ayant attribué l'identifiant. D'autres organismes y ajoutent leur propre analyse, et leurs conclusions ne coïncident pas toujours.
Structure d'un identifiant CVE
Prenons celui qui apparaît dans l'exemple de terminal ci-dessous : CVE-2026-27606. Il se compose de trois parties :
- CVE: indique qu'il s'agit d'une entrée de la liste CVE
- 2026: l'année d'attribution de l'identifiant, ou l'année où la faille a été rendue publique, si celle-ci est survenue en premier
- 27606: numéro de séquence attribué par une autorité de numérotation CVE
C’est sur ce point que les gens se trompent, et la FAQ du programme CVE est très claire : l’année correspond à la date d’attribution de l’identifiant ou à celle de la divulgation publique de la faille, jamais à celle de sa découverte. Une faille rendue publique en 2015 mais à laquelle un identifiant n’a été attribué qu’en 2016 porte toujours le numéro CVE-2015. L’année indique donc la date à laquelle la faille a été rendue publique, et non depuis combien de temps les pirates en ont connaissance.
Le numéro de séquence n'a d'autre signification que celle d'un identifiant unique. Il ne s'agit ni d'un niveau de gravité, ni d'une position dans la file d'attente, et il n'est pas limité à quatre chiffres : 27606 en compte cinq, et le format autorise quatre chiffres ou plus depuis 2014.
Ces numéros sont attribués par les autorités de numérotation CVE (CNA). MITRE a lancé ce programme en 1999 et continue de le gérer sous l’égide de la CISA, mais l’attribution est répartie entre des centaines de CNA agréées, allant de fournisseurs tels que Microsoft et Red Hat à des fondations open source et des plateformes de prime aux bogues. MITRE n’attribue pas tous les numéros CVE que vous voyez. Le CVE-2026-27606 provient de GitHub, qui fait office de CNA pour les projets qu’il héberge.
Que se passe-t-il après la publication d'une vulnérabilité CVE ?
Une fiche publiée fournit à tous un identifiant commun, une description et des références. À partir de là, d’autres bases de données ajoutent du contexte. La base de données nationale sur les vulnérabilités (NVD) se synchronise avec la liste CVE et enrichit les fiches de métadonnées qui facilitent leur exploitation. Selon le NIST, cela implique d’examiner les références soumises, d’attribuer un code CWE, d’attribuer des métriques CVSS v3.1 ou v4.0, d’associer une déclaration CPE et de procéder à un contrôle qualité par un analyste senior.
Voici le point sur lequel de nombreux outils n’ont pas encore rattrapé leur retard. Depuis le 15 avril 2026, le NIST donne la priorité à l’enrichissement de trois catégories : les enregistrements figurant dans le catalogue KEV de la CISA, les logiciels du gouvernement fédéral et les logiciels critiques tels que définis par le décret présidentiel n° 14028. Tout le reste est toujours enregistré dans la NVD, généralement marqué « Priorité la plus faible » et ne faisant pas l’objet d’un enrichissement immédiat. Il est possible de demander une analyse ; il s’agit donc d’une hiérarchisation plutôt que d’une exclusion définitive. L’arriéré antérieur à mars 2026 a également été reclassé dans la catégorie « Non programmé ».
Ainsi, une fiche peut être publiée sans note CVSS établie par le NVD, sans correspondance CWE ni configuration CPE, tout en conservant la note et la classe de vulnérabilité attribuées par le CNA. Un champ NVD vide ne signifie pas pour autant qu’il s’agit d’un bug inoffensif, ni qu’il n’y a pas de données. Les fiches peuvent également être modifiées après leur publication, et le NIST ne réanalyse désormais une fiche modifiée que lorsque la modification a une incidence significative sur l’enrichissement des données ; il est donc recommandé de relire tout ce que vous aviez mis de côté.
Voici donc trois acronymes que vous rencontrerez sans cesse.
Le CWE (Common Weakness Enumeration) indique la catégorie de la faille : débordement de tampon, cross-site scripting, traversée de chemin. Si le CVE correspond à un cas spécifique, le CWE désigne le type de faille auquel il appartient. Le CVE-2026-27606 correspond au CWE-22, « traversée de chemin ». Connaître cette catégorie permet de repérer la même faille ailleurs, même si cela ne prouve pas l'existence d'un autre cas vulnérable.
Le CVSS (Common Vulnerability Scoring System) évalue la gravité technique d’une vulnérabilité. Il s’agit d’un élément parmi d’autres permettant de déterminer si l’application d’un correctif peut attendre ; ce n’est pas un verdict sur l’urgence d’agir, ni un chiffre imposé d’en haut. Le CVE-2026-27606 en est la parfaite illustration. La page d’avis du Rollup le classe comme « modéré », tandis que sa propre section « impact » le qualifie de « critique » ; la fiche CVE indique un niveau « élevé » (8,8) selon la version 4.0 du CVSS, attribuée par GitHub en tant que CNA ; le NVD lui a attribué un score de 9,8 (« critique ») selon la version 3.1 ; et le Security ADP de Red Hat lui a attribué un score de 9,1 (« critique ») selon la version 3.1. Quatre caractérisations pour une seule faille, et aucune d’entre elles ne précise si le code s’exécute dans un conteneur de compilation ou sur un hôte connecté à Internet. Lisez le vecteur et la version du CVSS, pas seulement l’adjectif. Pour évaluer la probabilité d’exploitation, consultez l’EPSS et le catalogue KEV.
CPE (Common Platform Enumeration) décrit les plateformes et versions concernées de manière standardisée, ce qui vous permet de vérifier la pertinence d'une entrée par rapport à votre propre environnement. Le NVD associe ce CVE à cpe:2.3:a:rollupjs:rollup:*:*:*:*:*:node.js:*:*. Utile, mais il s'agit d'une correspondance avec la base de données plutôt que d'une donnée réelle issue de l'inventaire, et c'est sans doute le champ le plus susceptible de manquer à l'heure actuelle.
À quoi ressemble réellement une vulnérabilité CVE dans votre terminal ?
C'est là que ça devient sérieux. C'est parti ! npm audit, ou simplement en installant un paquet, vous pourriez constater la présence de 7 vulnérabilités de gravité élevée. Le résultat répertorie les paquets et versions concernés plutôt que les numéros CVE. Voici à quoi cela ressemble lors de l’installation d’Angular v18 (le résultat est plus chargé pour les anciennes versions comme Angular 16, où la « dépendance obsolète » a eu un an pour s’accumuler) :
rollup 4.0.0 - 4.58.0
Severity: high
Rollup 4 has Arbitrary File Write via Path Traversal - https://github.com/advisories/GHSA-mw96-cpmx-2vgc
fix available via `npm audit fix --force`
Will install @angular-devkit/[email protected], which is a breaking change
node_modules/rollup
@angular/build 18.1.0-next.0 - 19.2.21 || 20.0.0-next.0 - 20.2.0-rc.1 || 20.3.4 - 20.3.17
Depends on vulnerable versions of rollup
node_modules/@angular/build
@angular-devkit/build-angular *
Depends on vulnerable versions of @angular/build
Depends on vulnerable versions of copy-webpack-plugin
node_modules/@angular-devkit/build-angularNotez qu’il n’y a pas d’identifiant CVE dans ce résultat. npm renvoie vers l’avis GitHub, GHSA-mw96-cpmx-2vgc, qui correspond à CVE-2026-27606. Traduction : rollup est apparu en tant que dépendance transitive ; les versions 4.0.0 à 4.58.0 comportent une faille de gravité élevée appelée « Écriture arbitraire de fichiers via un parcours de chemin », et la version 4.59.0 corrige cette faille dans la branche 4.x.
C'est une erreur courante. Le module de validation des noms de fichiers de Rollup a supprimé une liste de caractères non valides, mais a omis le point et les deux barres obliques, ce qui fait que ../ est passé par là et a été remis à path.resolve. Toute personne capable de contrôler le nom d'un fichier de sortie, que ce soit via une entrée de ligne de commande, un alias de bloc ou un plugin malveillant, peut écrire un fichier à n'importe quel emplacement auquel le processus de compilation a accès. Écraser ~/.ssh/authorized_keys ou un profil de shell, ce qui se traduit par une exécution de code persistante.
C'est un exemple typique de vulnérabilité de la chaîne logistique logicielle : vous avez installé un paquet, et un « rollup » s'est glissé dans l'installation. Il est utile d'apprendre à lire le chemin des dépendances.
@angular-devkit/build-angular
└── @angular/build (vulnerable versions)
└── rollup (4.0.0 - 4.58.0) ← the vulnerable packageRéparer sans aggraver la situation
Commencez par déterminer où le paquet vulnérable est exécuté. npm audit --omit=dev concentre l'audit sur l'arborescence installée sans `devDependencies`, ce qui, dans le cas d'un projet Angular, sépare les dépendances d'exécution d'une grande partie de la chaîne d'outils de compilation. Cela recadre la vulnérabilité sans pour autant rendre inoffensive une faille au niveau de la compilation, puisque les systèmes de compilation stockent les identifiants et génèrent le produit que vous déployez.
Commencez par la solution compatible
Nature npm audit fix applique des correctifs qui s'inscrivent dans les plages de dépendances que npm peut déjà satisfaire. Si le paquet transitif vulnérable peut être remplacé par une version corrigée sans faire sortir vos dépendances de premier niveau de leurs plages déclarées, optez pour cette solution ; les deux options ci-dessous ne s'appliquent que lorsque cela n'est pas possible. Un audit sans anomalie effectué par la suite ne prouve pas que l'application est sécurisée, mais seulement que l'avis de vulnérabilité a disparu de l'arborescence que vous avez résolue.
Considérez la commande « npm audit fix –force » comme un outil puissant
Parfois, npm indique que la correction nécessite --force, comme indiqué ci-dessus. La documentation de npm précise que ce drapeau permet de npm audit fix pour installer des modules ne figurant pas dans la liste des dépendances que vous avez indiquée, y compris les changements majeurs au sens de la norme SemVer. Ici, cela met à jour @angular-devkit/build-angular vers la version 19.2.22, ce qui est signalé comme un changement rompant la compatibilité susceptible d'affecter votre configuration de compilation et vos API. C'est peut-être justifié. Cela pourrait également entraîner une erreur de compilation. Avant de lancer la commande :
- Consultez le journal des modifications de @angular-devkit/build-angular entre votre version et la version cible.
- Utilisation
npm audit fix --dry-runpour voir ce qu'il propose de déplacer - Exécutez-le sur une NOUVELLE branche, JAMAIS sur la branche « main »
N'utilisez une dérogation que lorsque vous avez une bonne raison de le faire
Une redéfinition permet au projet racine de modifier la manière dont npm résout une dépendance, en fixant un paquet transitif vulnérable à une version corrigée sans mettre à jour le paquet parent. Dans package.json:
{
"overrides": {
"rollup": "4.59.0"
}
}Exécuter npm install, puis npm audit encore une fois. Puis exécutez npm ls rollup et de le lire attentivement, car une redéfinition précise la résolution souhaitée tandis que npm ls affiche la version dont vous disposez, en l’indiquant comme « overridden » (remplacée) lorsque l’instruction a été appliquée. En réalité, vous indiquez à npm «Quoi qu'il arrive, pas d'excuses, installez cette version», quelle que soit la demande des parents. Prenez cela avec des pincettes.
Les « overrides » sont justifiés lorsque vous devez livrer une version, qu'une version corrigée existe déjà et que vous avez testé la version compilée et vérifié qu'elle ne présente aucun dysfonctionnement. Ils doivent toutefois rester temporaires. Ils désactivent l'avertissement sans pour autant éliminer la dette technique, car vous utilisez une version qui n'a pas été testée par rapport à ce qu'attend le reste de votre arborescence. S’il existe un correctif non régressif, optez pour cette solution. Une fois que la branche parente prend en charge la version corrigée, supprimez la redéfinition. Les redéfinitions constituent une solution de secours, pas la stratégie à adopter. C’est là qu’il faut prendre les choses avec des pincettes.
Pourquoi cela devient épuisant à grande échelle
Tout cela reste gérable lorsqu’il s’agit d’une seule vulnérabilité dans un seul projet. Mais cela devient ingérable lorsqu’il s’agit de dix-huit services, dont trois reposent sur une version d’un framework dont la fin de vie remonte à deux ans. C’est dans l’écart entre « un correctif existe » et « nous pouvons l’appliquer en toute sécurité » que la gestion des vulnérabilités devient coûteuse.
C’est précisément le problème que SecureChain vise à résoudre. Au lieu de réagir à chaque CVE au cas par cas, SecureChain entoure votre chaîne logistique d’une couche proactive, une sorte de « dôme de protection » si l’on veut : les paquets arrivent sous forme de versions vérifiées et signées, provenant de sources validées via un registre géré par TuxCare, et mises à jour en continu pour corriger les nouvelles vulnérabilités, plutôt que de vous obliger à jouer au « jeu du chat et de la souris » avec les registres publics à chaque fois qu’un avis de sécurité est publié.
Il y a deux aspects à cela :
- Protection avant la fin de vie (EOL): pour les composants faisant l'objet d'une maintenance active, les ingénieurs appliquent des correctifs en amont ou créent directement des correctifs personnalisés, couvrant ainsi les dépendances directes et transitives.
- Protection après la fin de vie (EOL): une fois que le support en amont prend fin, le service « Endless Lifecycle Support » (ELS) assure la poursuite de l'application des correctifs CVE pour les logiciels hérités ; ainsi, le fait qu'un éditeur cesse de prendre en charge une version n'oblige pas à procéder à une mise à niveau d'urgence.
Ce deuxième point a plus d’importance qu’il n’y paraît, car la dépendance transitive qui fait échouer votre audit est généralement celle dont plus personne ne s’occupe en amont. SecureChain publie également des documents VEX lisibles par machine indiquant quelles vulnérabilités CVE connues affectent des versions spécifiques de paquets, ce qui fait toute la différence entre une simple liste d’avis de sécurité et une véritable réponse.
À retenir
Quand vous tombez sur un CVE, pas de panique. Il s’agit d’un numéro de suivi accompagné d’une trace écrite, et cette trace est moins détaillée qu’auparavant, ce qui est d’autant plus une raison de la lire avec davantage d’attention, et non l’inverse.
Décodez l'identifiant. Vérifiez qui l'a attribué et selon quelle version du CVSS, puis identifiez les champs manquants. Utilisez le CWE pour la catégorie de vulnérabilité, le CVSS pour la gravité technique, et le CPE ou les données du fournisseur pour déterminer si vous êtes concerné. Ensuite, remontez la piste de la faille dans votre arborescence et choisissez le correctif le moins perturbateur qui vous permettra de passer à une version corrigée. Le numéro, c'est la partie facile. Ce qui est utile, c'est de transformer ce qui se cache derrière en une décision sereine, vérifiable et défendable.
