CVE-2026-85393 : node-forge RSA Forgé, Sans Patch

Une bibliothèque cryptographique téléchargée 48 millions de fois par semaine laisse passer des signatures RSA falsifiées depuis plus de trois mois, sans correctif officiel. La faille, répertoriée CVE-2026-85393, touche node-forge, un paquet JavaScript omniprésent dans l’écosystème Node.js, et révèle un problème structurel plus large : la vérification des signatures RSA PKCS#1 v1.5 continue de mal vieillir, vingt ans après les premières attaques Bleichenbacher. L’avis de sécurité a été publié le 3 septembre 2026 sur GitHub, mis à jour le 1er octobre, et au moment d’écrire ces lignes, le correctif proposé dort toujours dans une pull request non fusionnée.

Pour les équipes qui dépendent de node-forge pour signer ou vérifier des certificats, des jetons ou des paquets applicatifs, la situation est inconfortable : la version la plus récente de la bibliothèque, la 1.4.0, reste vulnérable. Et contrairement à beaucoup d’alertes de sécurité qui se referment en quelques semaines, celle-ci s’étire dans le temps, avec un ticket ouvert depuis le 6 juillet et une proposition de correctif qui attend une revue depuis le 9 septembre.

Que recouvre exactement CVE-2026-85393 ?

CVE-2026-85393, identifiée côté GitHub sous la référence GHSA-86w9-cpqp-85rv, décrit un défaut dans la vérification des signatures RSA PKCS#1 v1.5 de node-forge. Le problème se loge dans la fonction key.verify() du fichier lib/rsa.js : lorsqu’elle décode la structure ASN.1 du bloc DigestInfo, la bibliothèque ne vérifie pas que la séquence imbriquée DigestAlgorithm contient exactement le nombre de champs attendu par la norme. Un attaquant peut donc glisser des octets superflus à l’intérieur de cette séquence sans que la vérification échoue.

Le score CVSS 3.1 retenu est de 7,5 (Élevé), avec le vecteur AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N : la faille s’exploite à distance, sans authentification ni interaction de l’utilisateur, et compromet l’intégrité des données sans toucher à leur confidentialité ou à la disponibilité du service. Sous la grille CVSS 4.0, plus récente, le score grimpe à 8,7. Le CWE associé, CWE-347, correspond à une « vérification incorrecte de signature cryptographique », une catégorie qui recouvre exactement ce type de défaillance.

L’avis GitHub précise que cette faille constitue un correctif incomplet pour une vulnérabilité antérieure, CVE-2026-33894. En clair : node-forge avait déjà corrigé un problème de forgerie de signature RSA en mars 2026, mais la correction n’a pas couvert tous les cas. Des chercheurs ont trouvé une variante qui contourne le correctif initial, en exploitant la même logique de parsing ASN.1 mais via un chemin légèrement différent.

Le mécanisme de la forgerie de signature RSA

Pour comprendre la portée de la faille, il faut revenir sur le fonctionnement de la signature RSA PKCS#1 v1.5. Lors de la vérification, le vérifieur déchiffre la signature avec la clé publique, puis reconstitue un bloc encodé censé suivre un format précis : un octet 0x00, un octet 0x01, une suite d’octets de bourrage (0xFF), un séparateur 0x00, puis une structure ASN.1 nommée DigestInfo qui contient l’algorithme de hachage utilisé et l’empreinte du message.

Le problème survient quand le vérifieur se contente de retrouver ces éléments sans s’assurer qu’il n’y a rien d’autre dans la structure. Avec un exposant public faible, typiquement e=3, un attaquant peut construire mathématiquement un nombre dont le cube correspond à un bloc contenant la bonne empreinte, entouré de données arbitraires que la bibliothèque ignore à tort. La preuve de concept associée au correctif proposé pour node-forge illustre ce calcul : elle génère une paire de clés RSA de 4096 bits avec e=3, construit un intervalle numérique compatible avec le DigestInfo falsifié, puis calcule une racine cubique entière dans cet intervalle pour produire une signature valide aux yeux de node-forge, mais rejetée par le moteur OpenSSL natif de Node.js.

L’avis de sécurité original pour node-forge résume la mécanique en quelques mots : « La vérification de signature RSASSA PKCS#1 v1.5 accepte des signatures forgées pour des clés à exposant public faible (e=3). » Les mêmes chercheurs précisent que « les attaquants peuvent forger des signatures en insérant des octets de bourrage dans la structure ASN.1 afin de construire une signature qui passe la vérification, permettant une forgerie de type Bleichenbacher » (avis GHSA-ppp5-5v6c-4jwp, traduit de l’anglais).

Deuxième ingrédient du problème : la norme RFC 2313 impose un bourrage d’au moins 8 octets avant la structure DigestInfo, une exigence de sécurité qui complique la construction mathématique de la forgerie. L’avis technique relève que node-forge ne vérifie jamais cette longueur minimale, ce qui donne à l’attaquant davantage de marge pour ajuster son calcul et faire correspondre les tailles.

node-forge, un pilier discret de l’écosystème JavaScript

Ce qui rend CVE-2026-85393 préoccupante, ce n’est pas seulement sa mécanique mais son rayon d’exposition. node-forge n’est pas un paquet obscur : c’est l’une des bibliothèques cryptographiques pures JavaScript les plus utilisées pour manipuler des certificats X.509, des clés RSA et des structures PKCS dans des environnements où le module natif crypto de Node.js n’est pas disponible ou pas suffisant, notamment côté navigateur.

Indicateur	Valeur
Téléchargements npm (7 derniers jours)	48 130 656
Téléchargements npm (30 derniers jours)	167 580 537
Étoiles GitHub	5 335
Forks GitHub	862
Tickets ouverts sur le dépôt	464
Abonnés au dépôt GitHub	145
Version affectée	Toutes les versions jusqu’à 1.4.0 incluse
Version corrigée disponible sur npm	Aucune au 5 octobre 2026

Avec près de 48 millions de téléchargements hebdomadaires, node-forge dépasse largement la popularité de bibliothèques de signature plus spécialisées comme jsrsasign ou node-rsa. Cette diffusion massive s’explique par son ancienneté (le projet existe depuis plus d’une décennie sous l’égide de Digital Bazaar) et par sa présence en dépendance transitive dans des milliers de paquets qui n’ont souvent pas conscience de l’inclure.

Le dépôt affiche aujourd’hui 464 tickets ouverts, un volume qui traduit une maintenance ralentie par rapport au rythme d’adoption du paquet. Ce déséquilibre entre la taille de la base d’utilisateurs et la capacité de traitement des alertes de sécurité est précisément ce qui transforme une faille technique isolée en risque systémique pour la chaîne d’approvisionnement logicielle.

Pourquoi le correctif reste bloqué depuis l’été

La chronologie du traitement de CVE-2026-85393 illustre bien la lenteur du processus. Le ticket décrivant le problème, intitulé « RSA PKCS#1 v1.5 signature forgery via garbage in DigestAlgorithm (incomplete CVE-2026-33894 fix) », a été ouvert le 6 juillet 2026 sur le dépôt GitHub de digitalbazaar/forge. Il n’a reçu que trois commentaires en trois mois. L’avis de sécurité officiel, lui, n’a été publié que le 3 septembre, soit près de deux mois après le signalement initial. La note technique VU#725167 du CERT/CC, publiée le 15 juillet 2026 à propos des deux failles d’origine (RSA et Ed25519), avait déjà averti que les options de configuration ne suffisaient pas à neutraliser ce type de défaut.

Une proposition de correctif, la pull request numéro 1152 intitulée « Fix RSA PKCS#1 v1.5 forgery via nested DigestAlgorithm garbage », a ensuite été soumise le 9 septembre. Elle ajoute deux vérifications : un contrôle du nombre exact de champs dans la structure DigestInfo, et un rejet des blocs dont le bourrage descend sous les 8 octets requis par la RFC 2313. Au 5 octobre 2026, cette pull request reste ouverte et n’a pas été fusionnée, et aucune version 1.4.1 n’a été publiée sur le registre npm.

Date	Événement
24 mars 2026	Publication de node-forge 1.4.0, censée corriger CVE-2026-33894 et CVE-2026-33895
6 juillet 2026	Ouverture du ticket signalant le contournement du correctif (incomplete fix)
15 juillet 2026	CERT/CC publie la note VU#725167 sur les deux failles de forgerie d’origine
3 septembre 2026	Publication de l’avis GHSA-86w9-cpqp-85rv (CVE-2026-85393)
9 septembre 2026	Soumission de la pull request 1152 proposant un correctif
1er octobre 2026	Mise à jour de l’avis GitHub sans changement de statut du correctif
5 octobre 2026	Aucune version corrigée publiée sur npm, pull request toujours ouverte

Ce délai interroge sur la soutenabilité du modèle de maintenance bénévole pour des bibliothèques devenues critiques. Un projet comme node-forge, massivement intégré mais maintenu par une petite équipe, concentre un risque disproportionné par rapport aux ressources disponibles pour le traiter rapidement. C’est le même constat qui ressort régulièrement des incidents affectant d’autres briques open source largement dépendues, comme nous l’avions documenté avec la faille JWT de python-jose, également restée sans correctif malgré un score CVSS de 9,1.

Qui est réellement exposé par cette faille ?

L’exploitation de CVE-2026-85393 suppose des conditions précises. L’application visée doit utiliser node-forge pour vérifier des signatures RSA PKCS#1 v1.5, et la clé RSA concernée doit avoir été générée avec un exposant public faible, le plus souvent e=3. Ce choix d’exposant, plus rapide à calculer que le standard e=65537, reste utilisé dans certains environnements embarqués, certains systèmes de certificats historiques ou des générateurs de clés personnalisés qui privilégient la performance à la prudence cryptographique.

Les scénarios concrets concernés incluent la vérification de jetons signés, la validation de certificats clients ou de paquets logiciels signés, et tout mécanisme d’authentification s’appuyant sur une signature RSA contrôlée par node-forge plutôt que par le module crypto natif de Node.js, lequel s’appuie sur OpenSSL et n’est pas concerné par cette faille. Les applications qui utilisent node-forge uniquement pour du chiffrement symétrique, de la génération de certificats auto-signés en local, ou qui vérifient exclusivement des signatures avec un exposant standard, réduisent sensiblement leur exposition sans l’éliminer totalement, puisque la variante reste théoriquement praticable sur d’autres configurations selon la taille de la clé.

Le score EPSS (Exploit Prediction Scoring System) associé à CVE-2026-85393 reste bas, autour de 0,33 % de probabilité d’exploitation active dans les 30 jours suivant la publication. Ce chiffre traduit surtout la complexité technique de la mise en œuvre, pas l’absence de risque réel : une attaque ciblée contre une application spécifique reste à la portée d’un attaquant disposant de compétences en cryptographie appliquée, sans nécessiter d’infrastructure particulière.

Un air de déjà-vu : vingt ans d’attaques Bleichenbacher

La filiation entre CVE-2026-85393 et les travaux de Daniel Bleichenbacher sur la forgerie de signature RSA n’est pas une coïncidence stylistique : c’est la même famille de défaut qui ressurgit régulièrement depuis deux décennies. Les premières attaques documentées contre des vérificateurs PKCS#1 v1.5 trop permissifs remontent au milieu des années 2000, avec des failles trouvées dans des piles cryptographiques comme OpenSSL et NSS. En 2014, la vulnérabilité surnommée BERserk avait touché Firefox et d’autres logiciels Mozilla sur le même principe : accepter des structures ASN.1 mal formées lors de la vérification RSA.

Un article présenté à la conférence Black Hat USA en 2019 avait déjà tiré la sonnette d’alarme sur la persistance du problème, plus d’une décennie après la découverte initiale de Bleichenbacher. Ses auteurs y notaient que « de nombreuses implémentations de la vérification de signature RSA PKCS#1 v1.5 se révèlent incorrectement permissives face à des entrées malformées » et que « il est possible de forger des signatures lorsque l’exposant e est faible (par exemple e = 3) » (article Black Hat USA 2019, traduit de l’anglais). Sept ans plus tard, node-forge démontre que l’avertissement reste d’actualité.

node-forge lui-même n’est pas étranger à ce type de défaut : en 2022, deux vulnérabilités distinctes, CVE-2022-24771 et CVE-2022-24773, avaient déjà sanctionné une vérification trop laxiste des structures digestAlgorithm et DigestInfo, corrigées en version 1.3.0. Quatre ans plus tard, une variante du même problème refait surface, cette fois dans le code censé avoir fermé la porte une fois pour toutes avec la version 1.4.0. Le schéma se répète ailleurs : un rapport déposé sur le gestionnaire de tickets de Red Hat avait signalé un défaut comparable dans l’implémentation RSA PKCS#1 v1.5 du système OP-TEE (Open Portable Trusted Execution Environment), confirmant que cette classe de vulnérabilité traverse les écosystèmes plutôt que de se limiter à un seul projet (rapport Red Hat Bugzilla).

node-forge face aux alternatives : comparaison des approches de vérification

Face à ce type de faille récurrente, la question se pose logiquement : pourquoi continuer à utiliser une implémentation JavaScript pure de RSA plutôt que de s’appuyer sur les bibliothèques natives adossées à OpenSSL ? La réponse tient à des contraintes de portabilité, mais le compromis en matière de robustesse est désormais documenté noir sur blanc.

Bibliothèque	Moteur sous-jacent	Vulnérable à CVE-2026-85393	Usage typique
node-forge	Implémentation JavaScript pure	Oui, toutes versions jusqu’à 1.4.0	Navigateur, environnements sans module natif
crypto natif de Node.js	OpenSSL (lié au binaire Node.js)	Non	Applications serveur Node.js
jsrsasign	Implémentation JavaScript pure	Non documenté dans cet avis	Signature et vérification X.509 côté client
node-rsa	Implémentation JavaScript pure avec repli optionnel	Non documenté dans cet avis	Chiffrement et signature RSA applicatifs

Le module crypto natif de Node.js, qui délègue la vérification à OpenSSL, n’est pas affecté par CVE-2026-85393 : c’est justement ce moteur qui rejette la signature forgée dans la démonstration technique associée au correctif proposé pour node-forge, là où la bibliothèque JavaScript l’accepte à tort. Cette divergence de comportement entre deux vérifications censées implémenter la même norme RFC 8017 constitue en soi un signal d’alerte : chaque fois qu’une application mélange plusieurs bibliothèques cryptographiques pour des raisons de compatibilité, elle hérite du comportement le plus permissif de l’ensemble, pas du plus strict.

Cette dynamique rejoint un constat plus large déjà observé avec d’autres vulnérabilités de confusion ou de forgerie de signature touchant l’écosystème npm, comme la faille ECDSA ayant touché Mirage Crypto, corrigée en seulement 24 heures à titre de comparaison, ou encore le cas de signatures RSA-1024 forgées sans disposer de la clé privée. Le contraste de réactivité entre ces incidents et le dossier node-forge est frappant.

L’impact sur la chaîne d’approvisionnement logicielle

Au-delà du cas technique, CVE-2026-85393 illustre un problème économique familier aux équipes de sécurité : le coût de maintenance d’une dépendance critique n’est presque jamais proportionnel à son usage réel. Un paquet téléchargé 167,6 millions de fois par mois devrait, en théorie, bénéficier de ressources de revue de sécurité à la hauteur de son exposition. Dans les faits, la vitesse de traitement observée, environ deux mois entre le signalement initial et la publication de l’avis, puis plus d’un mois supplémentaire sans fusion du correctif proposé, reste comparable à celle de projets bien plus modestes.

Pour les entreprises européennes, cette situation entre directement en tension avec les obligations introduites par le règlement européen sur la cyber-résilience (Cyber Resilience Act), qui impose aux fabricants de produits numériques des délais stricts de signalement des vulnérabilités activement exploitées. Si node-forge reste un projet open source sans fabricant identifiable au sens strict du règlement, les entreprises qui l’intègrent dans des produits commerciaux, elles, restent pleinement soumises à ces obligations, et doivent désormais surveiller une dépendance dont le correctif échappe à leur contrôle direct.

Les équipes de sécurité applicative font donc face à un dilemme classique de la chaîne d’approvisionnement logicielle : signaler la vulnérabilité dans leur propre inventaire de composants (SBOM) sans disposer d’un correctif à appliquer, ou migrer en urgence vers une alternative dont le comportement n’a pas encore été audité avec la même profondeur. Les deux options ont un coût, et aucune n’élimine totalement le risque à court terme.

Comment limiter l’exposition en attendant un correctif officiel

En l’absence de version corrigée publiée sur npm, plusieurs mesures concrètes permettent de réduire le risque immédiat. La CERT/CC recommande, dans sa note technique sur les failles d’origine, de ne pas se fier aux options de configuration comme _parseAllDigestBytes: true, qui ne neutralisent pas le problème malgré une apparence de renforcement.

Recenser tous les points du code applicatif qui appellent key.verify() via node-forge pour une vérification de signature RSA.
Basculer, lorsque c’est possible, vers le module crypto natif de Node.js et sa méthode crypto.verify() adossée à OpenSSL pour les chemins de vérification critiques.
Ajouter une vérification croisée : valider la signature avec deux implémentations distinctes et rejeter toute divergence de résultat entre les deux.
Auditer les clés RSA utilisées en interne pour identifier celles générées avec un exposant public faible (e=3) et les faire migrer vers l’exposant standard 65537.
Surveiller activement la pull request 1152 et le dépôt digitalbazaar/forge pour appliquer le correctif dès sa fusion et sa publication sur npm.
Documenter cette exposition dans l’inventaire SBOM de l’organisation, avec une date de réévaluation à 30 jours.

Ces mesures ne remplacent pas un correctif officiel, mais elles réduisent la fenêtre de risque pour les applications dont le modèle de menace inclut la vérification de signatures RSA provenant de sources non totalement maîtrisées.

Exemple simplifié du défaut de validation

Le schéma ci-dessous illustre, de façon simplifiée, la différence entre la structure attendue par la norme RFC 8017 et celle que node-forge accepte à tort. Il ne s’agit pas d’un code d’exploitation fonctionnel, mais d’une représentation pédagogique de l’écart de validation déjà documenté publiquement dans l’avis de sécurité.

Structure DigestInfo attendue (RFC 8017) :
  SEQUENCE {
    SEQUENCE { OID algorithme_hachage, NULL },
    OCTET STRING empreinte_du_message
  }
  -> exactement 2 champs, aucun octet superflu

Structure acceptée à tort par node-forge <= 1.4.0 :
  SEQUENCE {
    SEQUENCE { OID algorithme_hachage, NULL },
    OCTET STRING empreinte_du_message,
    OCTET STRING octets_arbitraires_de_l_attaquant
  }
  -> 3 champs ou plus : la vérification devrait échouer, elle réussit

Ce que révèle cet incident sur la gouvernance open source

CVE-2026-85393 a été découverte dans le cadre d’un projet de recherche en sécurité mené à l’université de Californie à Berkeley, par Austin Chu, Sohee Kim et Corban Villa, selon les crédits mentionnés dans le rapport de vulnérabilité original déposé sur le dépôt digitalbazaar/forge. Ce détail compte : la faille n’a pas été trouvée par un attaquant malveillant ni par un chasseur de primes professionnel, mais par un travail universitaire de rétro-ingénierie méthodique sur un correctif existant, en partant du principe qu’une correction précédente pouvait elle-même être incomplète.

Cette méthode, consistant à revérifier systématiquement les correctifs de sécurité publiés plutôt qu’à les considérer comme acquis, mériterait d’être généralisée à plus grande échelle sur les dépendances critiques de l’écosystème npm. Elle rappelle aussi que la présence d’un numéro de version supérieur et d’un avis de sécurité fermé ne garantit en rien l’absence de variante résiduelle, surtout sur un code de parsing ASN.1 réputé notoirement difficile à sécuriser complètement.

Prédictions : ce qui devrait se passer dans les prochains mois

Une version 1.4.1 de node-forge devrait finir par être publiée d’ici la fin de l’année 2026, probablement après une pression accrue des mainteneurs de projets dépendants constatant l’absence de correctif sur un ticket vieux de plusieurs mois.
D’autres bibliothèques cryptographiques JavaScript pures feront probablement l’objet d’audits similaires dans les mois qui viennent, à mesure que la méthode de « revérification des correctifs antérieurs » utilisée par les chercheurs de Berkeley gagnera en popularité dans la communauté de recherche en sécurité.
Les grands intégrateurs de SBOM et les plateformes de scan de dépendances (GitHub Dependabot, Snyk, et équivalents) devraient afficher CVE-2026-85393 comme « sans correctif disponible » pendant encore plusieurs semaines, obligeant les équipes de sécurité à documenter un risque accepté plutôt qu’à le corriger.
Le débat sur la responsabilité des entreprises qui dépendent massivement d’un projet open source sans contribuer à son financement devrait se renforcer, porté notamment par les obligations du Cyber Resilience Act européen entrant en application plus largement en 2026 et 2027.
Il est probable que d’autres variantes de forgerie de signature RSA PKCS#1 v1.5 soient découvertes dans des bibliothèques moins exposées médiatiquement, simplement parce que la classe de vulnérabilité reste structurellement difficile à éliminer complètement du parsing ASN.1 historique.

Le contexte français et européen

En France, les équipes de développement qui intègrent node-forge dans des applications soumises à la directive NIS2 ou au Cyber Resilience Act doivent désormais considérer cette dépendance comme un point de vigilance documenté dans leur analyse de risque fournisseur. L’Agence nationale de la sécurité des systèmes d’information recommande de façon constante, dans ses publications sur la gestion des vulnérabilités tierces, de ne jamais traiter un correctif incomplet comme une clôture de dossier, une recommandation que l’historique de node-forge valide une fois de plus avec CVE-2026-33894 puis CVE-2026-85393.

Pour les éditeurs de logiciels basés en France et dans l’Union européenne, l’enjeu dépasse la simple application d’un correctif : il touche à la capacité de démontrer, en cas de contrôle réglementaire, qu’une dépendance vulnérable connue a bien été identifiée, évaluée et suivie, même en l’absence de solution immédiate. Cette traçabilité documentaire devient, de fait, aussi importante que le correctif lui-même dans un cadre de conformité. Comme nous l’avions souligné à propos de la mise en conformité Node.js en production, corriger une série de CVE touchant l’écosystème Node.js demande une discipline de suivi qui dépasse largement le simple exécution d’une commande de mise à jour.

Pour resituer cette affaire dans l’ensemble des sujets cryptographiques suivis par la rédaction, retrouvez notre couverture complète sur notre page thématique consacrée à la cryptographie.

Foire aux questions

Qu’est-ce que CVE-2026-85393 exactement ?

C’est une vulnérabilité de la bibliothèque node-forge qui permet de forger une signature RSA PKCS#1 v1.5 valide pour un message arbitraire, sans connaître la clé privée, à condition que la clé RSA ciblée utilise un exposant public faible comme e=3. Elle a été publiée le 3 septembre 2026 sous la référence GHSA-86w9-cpqp-85rv.

Quel est le score de gravité de cette faille ?

Le score CVSS 3.1 est de 7,5, classé Élevé. Sous la grille CVSS 4.0, le score atteint 8,7. Le score EPSS de probabilité d’exploitation active reste bas, autour de 0,33 %.

Quelles versions de node-forge sont concernées ?

Toutes les versions jusqu’à la 1.4.0 incluse, c’est-à-dire la version la plus récente disponible sur le registre npm au 5 octobre 2026.

Existe-t-il un correctif officiel disponible ?

Non, au 5 octobre 2026. Une proposition de correctif, la pull request numéro 1152, a été soumise le 9 septembre 2026 mais reste ouverte et non fusionnée sur le dépôt GitHub digitalbazaar/forge.

Comment se protéger en attendant un correctif ?

En basculant les vérifications de signature critiques vers le module natif crypto de Node.js, en auditant les clés RSA utilisant un exposant public faible, et en ajoutant une vérification croisée entre deux implémentations distinctes pour détecter toute divergence de résultat.

Cette faille est-elle liée aux attaques Bleichenbacher historiques ?

Oui. Il s’agit de la même famille de défaut : une vérification trop permissive de la structure encodée lors de la validation d’une signature RSA PKCS#1 v1.5, une classe de vulnérabilité documentée depuis les travaux de Daniel Bleichenbacher au milieu des années 2000 et toujours active aujourd’hui, comme le confirmait déjà un article présenté à Black Hat USA en 2019.

Qui a découvert CVE-2026-85393 ?

La vulnérabilité a été identifiée dans le cadre d’un projet de recherche en sécurité à l’université de Californie à Berkeley, mené par Austin Chu, Sohee Kim et Corban Villa.

node-forge est-il encore sûr à utiliser aujourd’hui ?

Pour des usages ne reposant pas sur la vérification de signatures RSA avec un exposant public faible, le risque immédiat reste limité. Mais toute application vérifiant des signatures RSA provenant de sources externes via node-forge devrait considérer cette dépendance comme non fiable sur ce point précis jusqu’à la publication d’un correctif officiel.

CVE-2026-85393 : node-forge Forgé, 3 Mois Sans Patch [2026]