Six failles publiées entre juin et septembre 2026 révèlent un même défaut de conception dans la manière dont des dizaines de bibliothèques vérifient les jetons JWT signés en HMAC. De python-jose à Node.js en passant par le pilote cryptographique CAAM du noyau Linux, la cause profonde est presque toujours identique : une clé publique, censée servir à vérifier une signature asymétrique, se retrouve acceptée comme secret HMAC. Résultat, un attaquant qui connaît la clé publique d’un service peut forger un jeton valide et usurper n’importe quel compte, y compris un compte administrateur.
Ce n’est pas un incident isolé. C’est une vague de failles qui rappelle, plus de dix ans après sa description initiale, que la confusion d’algorithme reste l’un des angles morts les plus tenaces de la cryptographie appliquée. Pour les équipes techniques françaises et européennes qui exposent des API avec des jetons signés, le message de septembre 2026 est simple : vérifier une signature HMAC ne suffit pas, il faut vérifier avec quel algorithme elle a été calculée.
Six CVE en trois mois : la chronologie d’une vague HMAC
La série de failles s’étale sur l’été 2026, avec une accélération nette en août et septembre. Elle commence le 5 juin 2026 avec la publication de CVE-2026-46395, une faille critique dans HAXcms, un système de gestion de contenu bâti sur Node.js. Avant la version 26.0.0, la fonction hmacBase64() du backend contenait deux erreurs cryptographiques cumulées qui permettaient à un attaquant non authentifié d’extraire la clé de signature privée du système et de forger, en une seule requête HTTP, un jeton JWT avec des droits d’administrateur complets, selon la fiche technique publiée par Tenable.
Le 8 juin 2026, une deuxième faille touche cette fois le noyau Linux : CVE-2026-46291 concerne le pilote crypto CAAM (Cryptographic Accelerator and Assurance Module), utilisé sur de nombreuses plateformes embarquées et serveurs ARM. La fonction hash_digest_key() affichait des octets de clé HMAC sensibles dans des journaux de débogage hexadécimaux lorsque l’option CONFIG_DYNAMIC_DEBUG était activée. Le correctif, qui remplace ces journaux par la fonction print_hex_dump_devel(), a été repris par Red Hat le 16 août 2026 puis par Ubuntu le 10 septembre 2026, preuve que la propagation d’un correctif noyau vers les distributions grand public prend encore plusieurs mois.
Mi-juillet, Red Hat documente CVE-2026-45363 : un jeton peut être accepté par erreur lorsque le calcul de la signature HMAC est réalisé avec une clé vide, un défaut de configuration qui permet à un attaquant de forger un jeton sans même connaître de secret. Puis, fin août, coup sur coup, trois autres CVE sont mises à jour dans les bases de Red Hat : CVE-2026-43044 (mauvais alignement mémoire lors du traitement de clés HMAC plus longues que la taille de bloc, avec un risque pour les opérations DMA), CVE-2026-34181 (falsification de conteneurs PKCS#12 protégés par le schéma PBMAC1 lorsque la clé HMAC est trop courte) et CVE-2026-48526, qui décrit exactement le même schéma de confusion d’algorithme que celui trouvé dans HAXcms, mais cette fois dans un vérificateur JWT générique mal configuré pour accepter à la fois des algorithmes symétriques et asymétriques.
Le point culminant de la vague arrive le 3 septembre 2026, quand VulnCheck publie CVE-2026-85394 contre python-jose, une bibliothèque JOSE très utilisée dans l’écosystème Python pour la génération et la vérification de jetons JWT. Le texte de la faille, repris par le National Vulnerability Database américain, précise que la bibliothèque, jusqu’à sa version 3.5.0, échoue à valider correctement les clés asymétriques lors de l’initialisation HMAC, acceptant des clés publiques encodées en DER sans en-tête PEM ni préfixe SSH. Un attaquant qui dispose de la clé publique d’un service peut ainsi forger des jetons HS256 valides dès lors que les algorithmes autorisés ne sont pas explicitement restreints côté vérification.
Le site spécialisé Severity Daily, qui a documenté cette faille dès le lendemain, note un détail aggravant : CVE-2026-85394 est en réalité un correctif incomplet d’une faille bien plus ancienne, CVE-2024-33663, corrigée deux ans plus tôt de manière insuffisante. La correction de 2024 vérifiait le format de la clé plutôt que la clé elle-même, laissant la porte ouverte à la variante découverte en 2026. Cette rechute illustre un problème récurrent en sécurité logicielle : un correctif qui traite le symptôme sans éliminer la cause profonde finit presque toujours par être recontourné.
Qui a détecté ces failles et comment elles ont été signalées
Les six CVE de cette vague n’émanent pas d’une seule source. VulnCheck, une plateforme spécialisée dans le renseignement sur les vulnérabilités, est à l’origine de la publication de CVE-2026-85394 contre python-jose. Les failles touchant le noyau Linux et ses pilotes cryptographiques suivent, elles, le circuit classique de la communauté kernel.org, avant d’être reprises et documentées par les équipes de sécurité de Red Hat et d’Ubuntu, qui adaptent chaque avis au contexte de leurs propres distributions. Tenable, de son côté, a documenté la faille HAXcms via son propre programme de recherche de vulnérabilités.
Cette diversité de sources illustre un point souvent sous-estimé par les équipes de sécurité : suivre uniquement le flux CVE du NIST ne suffit pas pour rester informé en temps réel. Un correctif kernel peut être disponible en amont plusieurs semaines avant que l’avis correspondant ne soit formellement indexé, comme le montre l’écart de plus de trois mois entre la résolution initiale de CVE-2026-46291 et sa reprise par Ubuntu le 10 septembre 2026.
Le mécanisme de la confusion d’algorithme, expliqué simplement
Pour comprendre pourquoi cette classe de failles revient aussi régulièrement, il faut revenir sur la manière dont un jeton JWT est structuré. Un jeton contient un en-tête qui déclare l’algorithme de signature utilisé, par exemple HS256 pour HMAC-SHA256 ou RS256 pour RSA avec SHA-256. Le problème, c’est que cet en-tête est fourni par l’émetteur du jeton, donc potentiellement par un attaquant qui fabrique son propre jeton falsifié.
Dans un schéma de vérification bien conçu, le serveur ignore l’algorithme déclaré dans le jeton et applique uniquement celui attendu pour ce contexte précis. Dans un schéma vulnérable, le serveur fait confiance à l’en-tête et sélectionne dynamiquement la fonction de vérification correspondante. Un attaquant qui connaît la clé publique RSA du service, souvent publiée volontairement via un point de terminaison JWKS comme le rappelle l’analyse de Severity Daily, peut alors émettre un jeton déclarant l’algorithme HS256 et utiliser cette clé publique, telle quelle, comme secret HMAC. Le serveur calcule la signature HMAC avec ce qu’il croit être un secret partagé, alors qu’il s’agit d’une donnée publique que n’importe qui peut lire. La vérification réussit, et l’attaquant peut signer n’importe quelle revendication, y compris "role": "admin".
Cette attaque, référencée dans la nomenclature CWE sous le code CWE-347 (vérification incorrecte d’une signature cryptographique), n’est pas nouvelle en soi. Elle avait été popularisée dès 2015 par le chercheur en sécurité Tim McLean. Ce qui frappe en 2026, c’est sa persistance dans des bibliothèques largement déployées et son extension à des couches inattendues, comme le pilote matériel CAAM du noyau Linux ou les conteneurs PKCS#12 utilisés pour stocker des certificats et des clés privées en entreprise.
Ce que dit la spécification JWT sur la vérification des algorithmes
La spécification des jetons JWT, formalisée dans la RFC 7519 et son cadre plus large JOSE (JSON Object Signing and Encryption), n’impose pas d’algorithme unique. Elle laisse volontairement ce choix ouvert pour couvrir des usages variés, du HMAC symétrique rapide pour des échanges internes à la signature asymétrique pour des scénarios impliquant plusieurs parties. Cette flexibilité, pensée pour l’interopérabilité, est précisément ce qui crée la surface d’attaque : rien dans le format lui-même n’empêche un vérificateur mal codé de faire confiance à l’algorithme déclaré par l’émetteur du jeton plutôt qu’à celui attendu par le contexte applicatif.
Les groupes de travail de l’IETF ont publié depuis plusieurs années des recommandations complémentaires, notamment autour du profil JWT Best Current Practices, qui conseillent explicitement de ne jamais dériver dynamiquement l’algorithme de vérification depuis l’en-tête du jeton. Le fait que des bibliothèques largement adoptées en 2026 continuent de s’écarter de cette recommandation montre l’écart persistant entre les bonnes pratiques documentées par les standards et leur application réelle dans le code produit.
Récapitulatif chiffré des six vulnérabilités
| CVE | Composant touché | Publication | Dernière mise à jour | Nature du défaut |
|---|---|---|---|---|
| CVE-2026-46395 | HAXcms (backend Node.js) | 5 juin 2026 | 27 juillet 2026 | Extraction de clé de signature via hmacBase64() |
| CVE-2026-46291 | Linux kernel, pilote CAAM | 8 juin 2026 | 10 septembre 2026 | Fuite de clé HMAC dans les journaux de débogage |
| CVE-2026-21713 | Node.js (vérification HMAC) | 30 mars 2026 | 21 août 2026 | Comparaison non constante dans le temps |
| CVE-2026-45363 | Vérificateur de jetons générique | 14 juillet 2026 | 8 septembre 2026 | Acceptation d’une clé HMAC vide |
| CVE-2026-48526 | Vérificateur JWT mal configuré | 28 mai 2026 | 26 août 2026 | Confusion clé publique / secret HMAC |
| CVE-2026-85394 | python-jose (jusqu’à la v3.5.0) | 3 septembre 2026 | 4 septembre 2026 | Correctif incomplet de CVE-2024-33663 |
Deux failles supplémentaires, moins liées à la confusion d’algorithme mais rattachées à la même famille de bugs d’implémentation HMAC, complètent le tableau : CVE-2026-43044, un défaut d’alignement mémoire lors du traitement de clés HMAC dépassant la taille de bloc, mis à jour le 20 août 2026, et CVE-2026-34181, une falsification possible de fichiers PKCS#12 protégés par PBMAC1 avec des clés HMAC trop courtes, mise à jour le 24 août 2026. Au total, ce sont donc au moins huit avis de sécurité distincts touchant HMAC qui ont été publiés ou mis à jour entre fin mai et le 10 septembre 2026.
Pourquoi cette vague inquiète particulièrement les entreprises européennes
Les jetons JWT signés en HMAC ou en RSA sont devenus le mécanisme d’authentification par défaut de la quasi-totalité des API modernes, des applications bancaires aux plateformes SaaS RH en passant par les portails d’authentification unique déployés dans les grandes entreprises. En France, la directive NIS2 impose désormais aux entités essentielles et importantes de documenter la gestion de leurs vulnérabilités logicielles et de corriger dans des délais resserrés les failles touchant des composants d’authentification, ce qui place mécaniquement les CVE de cette vague sous surveillance renforcée pour les équipes de conformité.
Le risque n’est pas seulement direct. Il est aussi transitif. Une bibliothèque comme python-jose est rarement appelée directement par un développeur final : elle est intégrée en profondeur dans des frameworks d’authentification, des passerelles API, ou des SDK tiers, eux-mêmes réutilisés par des centaines d’applications qui ignorent parfois quelle bibliothèque de vérification JWT tourne réellement sous le capot. C’est exactement ce schéma de dépendance en cascade qui démultiplie l’impact d’une faille touchant une bibliothèque cryptographique largement réutilisée, et qui explique pourquoi une CVE unique publiée début septembre peut concerner, en réalité, un nombre de services bien plus large que celui indiqué dans l’avis initial.
Pour les équipes de sécurité, la difficulté pratique tient à l’inventaire. Beaucoup d’organisations savent lister leurs frameworks web principaux, mais peu savent dire avec certitude quelle bibliothèque de vérification JWT équipe chacun de leurs microservices, ni quelle version. Sans un outil de SCA (Software Composition Analysis) à jour et une politique de mise à jour automatisée des dépendances de sécurité, ce type de faille peut rester non corrigé pendant des mois, voire des années, comme l’a montré la faille RSA CVE-2024-2236 dans Libgcrypt, restée sans correctif dans certaines distributions Ubuntu pendant près de neuf ans.
Comparaison avec les grandes familles de failles d’authentification récentes
Cette vague HMAC s’inscrit dans un contexte plus large de failles touchant les mécanismes d’authentification par jeton, aux côtés de vulnérabilités bien différentes par leur nature mais comparables par leur impact potentiel. Le tableau ci-dessous replace la vague de 2026 face à deux autres épisodes marquants de failles cryptographiques survenus la même année.
| Épisode | Période | Cause racine | Composants touchés | Barrière technique d’exploitation |
|---|---|---|---|---|
| Vague HMAC / confusion d’algorithme JWT | Juin – septembre 2026 | Clé publique acceptée comme secret HMAC | python-jose, HAXcms, Node.js, noyau Linux CAAM | Faible : outils grand public suffisent |
| Vague ECC (Linux, Python cryptography, OP-TEE, CIRCL) | Février – août 2026 | Erreurs d’arithmétique et de validation de sous-groupe ECC | Noyau Linux, Python cryptography, ARM OP-TEE, Go CIRCL (Cloudflare) | Élevée : expertise cryptographique requise |
| Faille RSA Libgcrypt CVE-2024-2236 | Découverte en 2024, corrigée en 2026 | Oracle de padding de type Bleichenbacher | Libgcrypt, dérivés Ubuntu | Moyenne : nécessite de nombreuses requêtes |
Ce qui distingue la vague HMAC des deux autres épisodes, c’est sa nature quasi entièrement logicielle et logique plutôt que mathématique. Les failles ECC de la première moitié de l’année 2026 relevaient d’erreurs d’implémentation dans des calculs de courbes elliptiques, un terrain qui exige une expertise cryptographique pointue pour être exploité. À l’inverse, une confusion d’algorithme JWT peut être exploitée avec des outils grand public et une simple compréhension du format JSON, ce qui abaisse considérablement la barrière technique pour un attaquant opportuniste.
Les limites des scanners de sécurité automatisés face à cette classe de faille
Un scanner de composition logicielle classique repère généralement une bibliothèque vulnérable en comparant son numéro de version à une base de données de CVE connues. Ce modèle fonctionne bien pour des failles liées à une version précise, mais il montre ses limites face à la confusion d’algorithme, car le défaut réside souvent dans la manière dont l’application utilise la bibliothèque plutôt que dans la bibliothèque elle-même. Une application peut ainsi tourner sur une version de python-jose techniquement à jour tout en restant vulnérable si son code applicatif omet de restreindre la liste des algorithmes acceptés.
C’est pour cette raison que les recommandations des éditeurs de sécurité, y compris celles reprises par Severity Daily dans son analyse de CVE-2026-85394, insistent sur la nécessité de compléter l’inventaire de dépendances par une revue de configuration applicative ciblée. Un audit de code statique orienté sur les appels de vérification JWT reste, à ce jour, le moyen le plus fiable de détecter une confusion d’algorithme avant qu’elle ne soit exploitée en production.
Contexte historique : une faiblesse connue depuis 2015
La confusion entre clé publique et secret HMAC dans les jetons JWT n’est pas un concept nouveau. Le problème a été formalisé publiquement en 2015 par le chercheur en sécurité Tim McLean, qui avait démontré que plusieurs bibliothèques JWT populaires de l’époque, notamment en Node.js et en Ruby, ne restreignaient pas correctement l’algorithme accepté lors de la vérification. La recommandation qui en avait découlé, à savoir toujours imposer explicitement une liste blanche d’algorithmes autorisés côté vérificateur, est depuis considérée comme une bonne pratique de base en sécurité applicative.
Onze ans plus tard, le fait qu’une bibliothèque aussi installée que python-jose expose encore une variante de cette même faille montre que la leçon de 2015 ne s’est pas complètement propagée dans l’écosystème. Le problème s’est en partie déplacé : il ne s’agit plus de laisser un attaquant choisir librement l’algorithme, mais de valider insuffisamment le format et l’origine de la clé fournie au moment de l’initialisation de la vérification HMAC, une nuance technique plus difficile à détecter lors d’un audit de code rapide.
Impact sur les fournisseurs cloud et intégrateurs SaaS en Europe
Les fournisseurs de plateformes cloud et les intégrateurs SaaS opérant en France et dans le reste de l’Union européenne se trouvent en première ligne, car ce sont eux qui hébergent le plus souvent les passerelles d’API exposant des jetons JWT à des millions d’utilisateurs finaux. Un correctif retardé côté fournisseur se répercute directement sur l’ensemble de ses clients, sans que ces derniers aient nécessairement connaissance de la bibliothèque de vérification utilisée en coulisses. Cette opacité renforce l’intérêt, pour les entreprises clientes, d’exiger de leurs fournisseurs cloud une communication proactive sur les correctifs de sécurité touchant les mécanismes d’authentification, plutôt que d’attendre une divulgation publique.
Les équipes DevSecOps qui opèrent des architectures de microservices avec passerelle API centralisée (API gateway) disposent d’un avantage structurel : en centralisant la vérification des jetons à un seul endroit plutôt que de la dupliquer dans chaque service, elles réduisent le nombre de points de correction nécessaires en cas de CVE comme celles listées ici. C’est un argument supplémentaire en faveur d’une architecture d’authentification centralisée plutôt que distribuée, en particulier pour les organisations soumises à des obligations de conformité renforcées comme NIS2 ou DORA.
Ce que doivent faire les équipes techniques dès maintenant
La première mesure, la plus immédiate, consiste à mettre à jour python-jose au-delà de la version 3.5.0 dès qu’un correctif officiel est publié, et à vérifier dans l’intervalle si l’application impose déjà une liste explicite d’algorithmes autorisés lors de la vérification des jetons. La plupart des frameworks JWT modernes, dont PyJWT, exposent un paramètre dédié à cet effet, souvent nommé algorithms, qui doit systématiquement être renseigné avec une liste fermée plutôt que laissé vide ou déduit dynamiquement du jeton reçu.
Deuxième mesure : auditer les configurations d’authentification unique et de passerelles API pour repérer tout vérificateur acceptant simultanément des algorithmes symétriques (HS256) et asymétriques (RS256, ES256), un schéma directement exploité par CVE-2026-48526. Séparer strictement les points de terminaison qui utilisent HMAC de ceux qui utilisent une signature asymétrique élimine mécaniquement cette classe d’attaque.
Troisième mesure, plus structurelle : pour les organisations utilisant des systèmes embarqués ou des serveurs équipés d’accélérateurs cryptographiques matériels comme CAAM, vérifier que le débogage dynamique du noyau (CONFIG_DYNAMIC_DEBUG) est désactivé en production, ou à défaut que l’accès à debugfs est strictement réservé aux comptes disposant de la capacité CAP_SYS_ADMIN. Cette configuration, souvent héritée d’environnements de développement, reste activée par défaut sur un nombre significatif de déploiements industriels et embarqués en Europe.
Quatrième mesure, enfin : imposer systématiquement une comparaison en temps constant lors de la vérification d’une signature HMAC, plutôt qu’une comparaison d’égalité classique. C’est précisément l’absence de cette précaution qui est documentée dans CVE-2026-21713 pour Node.js, où une comparaison non constante dans le temps peut permettre à un attaquant de déduire des informations sensibles en mesurant les délais de réponse du serveur.
Prévisions : ce qui va probablement se passer d’ici la fin de l’année
- D’autres bibliothèques JWT réutilisant des schémas de validation similaires à celui de python-jose devraient faire l’objet de nouveaux avis dans les semaines qui suivent, à mesure que les chercheurs en sécurité élargissent leurs tests à des projets adjacents dans l’écosystème Python et JavaScript.
- Les éditeurs de scanners de composants logiciels vont vraisemblablement ajouter des règles de détection spécifiques à la confusion d’algorithme JWT plutôt que de se limiter à un suivi générique de version de bibliothèque, une évolution déjà amorcée par plusieurs plateformes après des vagues de CVE comparables.
- Les correctifs noyau Linux liés à CVE-2026-46291 devraient continuer à se propager progressivement vers les distributions à cycle de support long jusqu’en fin d’année 2026, avec un décalage de plusieurs mois entre la publication amont et la disponibilité effective dans les dépôts stables.
- Les équipes de conformité NIS2 en France devraient intégrer plus systématiquement l’inventaire des bibliothèques de vérification de jetons dans leurs cartographies de dépendances critiques, sous la pression des obligations de gestion des vulnérabilités renforcées par la directive.
- Il est probable qu’au moins une CVE supplémentaire touchant la confusion clé publique / secret HMAC soit publiée avant la fin de l’année, tant le schéma de faille identifié dans HAXcms, dans le vérificateur générique de CVE-2026-48526 et dans python-jose s’est révélé transversal à plusieurs écosystèmes de développement distincts.
Foire aux questions
Qu’est-ce qu’une attaque par confusion d’algorithme sur un jeton JWT ?
C’est une technique où un attaquant fabrique un jeton JWT en déclarant l’algorithme HS256 (HMAC) alors que le service vérifie normalement ses jetons avec une signature asymétrique RS256 ou ES256. Si le vérificateur accepte dynamiquement l’algorithme déclaré dans le jeton et utilise la clé publique RSA ou EC du service comme secret HMAC, l’attaquant peut forger une signature valide puisque cette clé publique est, par définition, accessible à tous.
python-jose est-elle toujours vulnérable en septembre 2026 ?
Selon l’avis publié par VulnCheck et repris par le National Vulnerability Database le 3 septembre 2026, toutes les versions jusqu’à la 3.5.0 incluse sont concernées. Les équipes utilisant cette bibliothèque doivent surveiller la publication d’un correctif officiel et, dans l’intervalle, imposer une liste blanche d’algorithmes autorisés lors de chaque vérification de jeton.
Cette vague de failles concerne-t-elle uniquement Python et Node.js ?
Non. Elle s’étend également au noyau Linux, via le pilote cryptographique CAAM (CVE-2026-46291), ainsi qu’au format de conteneur PKCS#12 utilisé pour stocker des certificats et des clés privées en entreprise (CVE-2026-34181). La vague touche donc à la fois des couches applicatives et des couches système bas niveau.
Comment se protéger sans attendre un correctif officiel ?
La mesure la plus efficace consiste à configurer explicitement la liste des algorithmes de signature acceptés dans le code de vérification des jetons, plutôt que de laisser la bibliothèque déduire l’algorithme depuis l’en-tête du jeton reçu. Cette configuration, disponible dans la quasi-totalité des bibliothèques JWT modernes, neutralise la confusion d’algorithme indépendamment de la version installée.
Quelle est la différence entre CVE-2026-85394 et CVE-2024-33663 ?
CVE-2024-33663 avait été corrigée en 2024 en vérifiant le format de la clé fournie lors de l’initialisation HMAC. Cette correction s’est révélée insuffisante : CVE-2026-85394 exploite des clés publiques encodées en DER sans en-tête PEM ni préfixe SSH, un format qui contourne la détection basée sur le format mise en place deux ans plus tôt.
Les entreprises françaises soumises à NIS2 sont-elles directement concernées ?
Toute entité essentielle ou importante au sens de NIS2 qui expose des API authentifiées par jeton JWT, ou qui dépend de fournisseurs SaaS utilisant ce mécanisme, doit intégrer ces CVE dans sa cartographie de vulnérabilités et documenter le délai de correction, conformément aux obligations de gestion des risques cyber introduites par la directive.
Le pilote CAAM du noyau Linux est-il utilisé en dehors des systèmes embarqués ?
CAAM équipe principalement des processeurs ARM et des cartes réseau dotées d’accélération cryptographique matérielle, très présentes dans les équipements réseau, les passerelles industrielles et certains serveurs spécialisés. Son usage reste donc plus répandu dans l’infrastructure et l’embarqué que sur les postes de travail classiques.
Existe-t-il un outil pour détecter automatiquement ces failles dans son propre code ?
Les scanners de composition logicielle qui suivent les bases NVD et les avis Red Hat signalent en général ces CVE dès leur intégration dans leurs flux, à condition que l’inventaire des dépendances de l’application soit à jour. Une analyse de code statique ciblée sur la configuration des bibliothèques JWT permet en complément de vérifier concrètement si une liste blanche d’algorithmes est bien appliquée.
