Une faille critique vient de frapper l’un des piliers silencieux de l’authentification web moderne : le jeton JWT. Le 3 septembre 2026, à 19h17 UTC, le service de veille VulnCheck a publié CVE-2026-85394, une vulnérabilité notée 9,1 sur l’échelle CVSS qui touche python-jose, une bibliothèque Python très utilisée pour signer et vérifier des jetons JOSE (JSON Object Signing and Encryption). Le défaut permet à un attaquant de forger des jetons HS256 valides à partir d’une simple clé publique, un scénario qui rend caduque une partie du modèle de confiance sur lequel reposent des milliers d’API. Trois semaines plus tard, aucun correctif officiel n’a encore été publié.
Ce n’est pas un cas isolé. Depuis janvier 2026, au moins huit vulnérabilités distinctes touchant des mécanismes HMAC ou des bibliothèques JWT ont été recensées dans des composants très utilisés en production, de Ruby à .NET en passant par OpenSSL et wolfSSL. CVE-2026-85394 arrive comme le symptôme le plus récent, et le plus sévère, d’un problème structurel que les chercheurs en sécurité qualifient de confusion d’algorithme, un défaut connu depuis une décennie mais qui continue de resurgir à chaque nouvelle bibliothèque.
Ce que dit exactement CVE-2026-85394
La description officielle du registre CVE.org tient en une phrase technique mais lourde de conséquences : python-jose, jusqu’à la version 3.5.0 incluse, échoue à valider correctement les clés asymétriques lors de l’initialisation HMAC, acceptant des clés publiques encodées en DER dépourvues d’en-tête PEM ou de préfixe SSH. En clair, une donnée censée être une clé publique RSA ou EC peut être avalée par la bibliothèque comme si elle était un secret HMAC classique.
Le site spécialisé TheHackerWire classe la faille comme un contournement critique de validation de clé. Le CWE associé, le CWE-347, vérification incorrecte de signature cryptographique, décrit précisément ce type d’erreur : un système accepte une signature qu’il aurait dû rejeter. Ici, la conséquence directe est la forgerie de jetons.
Le scénario d’exploitation ne demande ni accès physique, ni identifiants volés. Il suffit que l’attaquant possède la clé publique du service visé, une information qui, par construction, circule ouvertement dans les schémas RS256 ou ES256 via un point de terminaison JWKS, une documentation d’API ou un certificat public. Si l’application accepte à la fois des algorithmes asymétriques et HS256 sans restriction explicite, l’attaquant réutilise cette clé publique comme secret HMAC et génère des jetons qui passent la vérification.
Comment fonctionne l’attaque par confusion d’algorithme
La confusion d’algorithme n’est pas un concept nouveau, mais elle reste redoutablement efficace. Le standard RFC 7519, qui définit le format JWT, laisse le champ alg de l’en-tête du jeton sous le contrôle de l’émetteur du jeton, y compris potentiellement d’un attaquant qui fabrique son propre jeton. Si le code de vérification côté serveur ne fixe pas explicitement l’algorithme attendu, et se contente de lire celui indiqué dans le jeton reçu, il devient manipulable.
Dans une architecture saine, un service qui signe ses jetons en RS256 avec une clé privée RSA ne devrait jamais accepter un jeton signé en HS256. Le problème apparaît lorsque le code de vérification appelle une fonction générique qui accepte une liste d’algorithmes mixte, symétriques et asymétriques confondus. C’est exactement la faille identifiée dans python-jose : la fonction d’initialisation HMAC ne vérifie pas que la clé fournie est bien un secret partagé, et non une clé publique détournée de son usage prévu.
Le résultat pratique est une usurpation d’identité complète. Un attaquant qui forge un jeton HS256 valide peut se faire passer pour n’importe quel utilisateur, y compris un compte administrateur, si le jeton contient les bonnes revendications. Les équipes de sécurité parlent alors de contournement d’authentification et d’escalade de privilèges, deux impacts que SeverityDaily associe explicitement à cette CVE dans son suivi quotidien des vulnérabilités liées à HMAC.
python-jose, une bibliothèque répandue mais sans correctif
python-jose, hébergée sous le dépôt mpdavis/python-jose, sert depuis des années à implémenter les spécifications JOSE, signature, chiffrement et jetons, dans des applications Python, souvent des API Django, Flask ou FastAPI. Sa popularité en fait une dépendance transitive fréquente : de nombreuses équipes ne savent même pas qu’elle tourne dans leur pile, tirée par un framework d’authentification tiers.
Trois semaines après la divulgation publique, aucune version corrigée n’a été référencée par les traqueurs de vulnérabilités consultés, ni par le dépôt GitHub du projet. Les avis publiés se limitent à recommander de surveiller le suivi des tickets du projet et à appliquer des contournements côté application, notamment restreindre explicitement la liste des algorithmes acceptés. Aucune déclaration officielle des mainteneurs, ni de la CISA américaine, n’a été retrouvée à ce sujet à la date du 21 septembre 2026.
Ce silence pèse d’autant plus que CVE-2026-85394 n’est pas la première alerte sur ce composant. Les chercheurs la décrivent comme un correctif incomplet d’une faille antérieure, CVE-2024-33663, déjà liée à une mauvaise gestion des clés dans la même bibliothèque. Deux ans après un premier signalement, le problème racine n’a donc toujours pas été traité en profondeur, ce qui interroge sur la vitalité réelle du projet.
Une vague de failles HMAC et JWT qui dure depuis janvier 2026
CVE-2026-85394 s’inscrit dans une série. Au moins huit vulnérabilités touchant des mécanismes HMAC ou des bibliothèques JOSE ont été publiées depuis le début de l’année dans des composants très différents : bibliothèques Python et Ruby, pile cryptographique .NET, moteur OpenSSL, module noyau Linux et implémentation embarquée wolfSSL. Le tableau ci-dessous récapitule les cas documentés cette année.
| CVE | Composant | Nature du défaut | Date de divulgation |
|---|---|---|---|
| CVE-2026-43044 | Noyau Linux (crypto caam) | Corruption mémoire sur clés HMAC longues | 1 mai 2026 |
| CVE-2026-48526 | PyJWT | Clé publique JWK acceptée comme secret HMAC | 28 mai 2026 |
| CVE-2026-46291 | Noyau Linux (crypto caam) | Fuite de clé HMAC via journalisation de débogage | 8 juin 2026 |
| CVE-2026-34181 | OpenSSL (PKCS#12 / PBMAC1) | Forgerie de fichiers via clé HMAC courte | 9 juin 2026 |
| CVE-2026-8720 | wolfSSL (HMAC-BLAKE2) | Message ignoré si clé plus longue que le bloc | 25 juin 2026 |
| CVE-2026-6331 | OpenSSL (EVP_DigestVerifyFinal) | Tag de longueur nulle accepté comme valide | 27 juin 2026 |
| CVE-2026-45363 | ruby-jwt | Clé vide acceptée pour HS256/384/512 | 14 juillet 2026 |
| CVE-2026-47304 | .NET (System.Security.Cryptography.Xml) | Signature XML tronquée acceptée | 3 août 2026 |
| CVE-2026-84483 | WWBN AVideo | Jeton HMAC forgé via l’URL publique du site | 1 septembre 2026 |
| CVE-2026-85394 | python-jose | Clé publique acceptée en initialisation HMAC | 3 septembre 2026 |
Dix incidents documentés en huit mois, sur des piles technologiques qui n’ont rien en commun sinon leur usage de HMAC. Cette répétition suggère moins une malchance ponctuelle qu’un défaut de conception récurrent dans la façon dont les développeurs implémentent la vérification de signature depuis des années.
Comparaison des bibliothèques touchées et de leur réactivité
Toutes les équipes n’ont pas réagi à la même vitesse. PyJWT, la bibliothèque concurrente la plus utilisée pour gérer les jetons JWT en Python, a publié un correctif en quelques jours après la découverte de sa propre faille de confusion d’algorithme. ruby-jwt a fait de même, avec deux versions corrigées simultanément pour couvrir ses différentes branches de compatibilité. python-jose, en comparaison, reste sans réponse trois semaines après la divulgation.
| Bibliothèque | CVE | CVSS v3.1 | Version corrigée | Délai jusqu’au correctif |
|---|---|---|---|---|
| PyJWT | CVE-2026-48526 | 7,4 | 2.13.0 (21 mai 2026) | Correctif publié avant la divulgation publique |
| ruby-jwt | CVE-2026-45363 | Non attribué publiquement | 2.10.3 et 3.2.0 | Corrigé sur les deux branches actives |
| PyJWT | CVE-2026-48523 | Non attribué publiquement | Corrigé dans la série 2.13.x | Corrigé avec la même série de versions |
| python-jose | CVE-2026-85394 | 9,1 (certains agrégateurs indiquent 9,3) | Aucune à ce jour | Plus de trois semaines sans correctif |
L’écart est frappant. Une faille notée 7,4 a été corrigée avant même sa divulgation publique dans un cas, tandis qu’une faille notée 9,1, donc plus dangereuse sur le papier, reste ouverte. Ce différentiel de réactivité illustre un problème plus large de gouvernance des dépendances open source : la gravité technique d’une vulnérabilité ne garantit en rien la rapidité de sa correction, qui dépend surtout de la disponibilité et de l’implication des mainteneurs bénévoles.
Contexte historique : dix ans de confusions d’algorithme JWT
La confusion d’algorithme HS256/RS256 a été popularisée en 2015 par les chercheurs Tim McLean et Antonio Sanso, qui avaient montré que plusieurs bibliothèques JWT majeures de l’époque validaient un jeton HS256 avec la clé publique RSA du serveur comme secret. Onze ans plus tard, la même classe de bug refait surface, dans une bibliothèque différente mais avec un mécanisme quasi identique.
Entre-temps, la spécification elle-même n’a pas fondamentalement changé, malgré des recommandations répétées de l’OWASP pour épingler explicitement l’algorithme attendu côté vérificateur plutôt que de faire confiance au champ alg du jeton entrant. Le Top 10 OWASP classe ce type de défaut dans la catégorie des ruptures de contrôle d’accès, l’une des catégories de risque les plus fréquentes recensées dans les audits d’applications web.
Ce qui change en 2026, c’est la vitesse à laquelle ces failles sont désormais détectées et médiatisées. Des plateformes comme VulnCheck ou GCVE publient des analyses détaillées en quelques heures, ce qui accélère la diffusion de l’information, mais expose aussi plus rapidement les équipes qui n’ont pas encore corrigé leur configuration.
Impact potentiel pour les entreprises françaises et européennes
python-jose figure dans la chaîne de dépendances de nombreux frameworks d’authentification open source utilisés en Europe, notamment dans des projets qui intègrent OpenID Connect ou OAuth 2.0 côté Python. Une entreprise française qui a construit son API de paiement, sa passerelle bancaire ou son portail client sur ce socle sans le savoir hérite directement du risque, même si elle n’a jamais entendu parler de python-jose.
Le calendrier réglementaire européen aggrave la pression. Depuis le 11 septembre 2026, l’article 14 du Cyber Resilience Act impose aux fabricants de produits numériques de signaler une vulnérabilité activement exploitée dans un délai de 24 heures, avec un rapport complet à fournir sous 72 heures puis un bilan final après correction. Une entreprise qui découvre une dépendance vulnérable à CVE-2026-85394 dans son produit doit désormais documenter sa réponse dans ces délais très serrés, sans même disposer d’un correctif officiel à appliquer.
Pour les secteurs sous supervision renforcée, comme la finance, le règlement DORA impose déjà une cartographie des risques liés aux prestataires de technologie de l’information et de la communication. Une dépendance non maintenue et sans correctif comme python-jose devient, dans ce cadre, un point de non-conformité potentiel qu’un auditeur peut relever lors d’un contrôle.
Comment détecter si votre application est exposée
La première étape consiste à établir un inventaire précis des dépendances. python-jose apparaît souvent de façon transitive dans un fichier requirements.txt ou dans un lockfile Poetry, sans qu’aucune ligne de code de l’application ne mentionne explicitement son nom. Un audit de dépendances avec un outil comme pip-audit ou un scanner de composition logicielle permet de repérer sa présence.
pip install pip-audit
pip-audit --requirement requirements.txt
# Repérer un appel vulnérable dans le code
grep -rn "python_jose\|jose.jwt.decode" --include="*.py" .
# Vérifier si la liste d'algorithmes mélange symétrique et asymétrique
grep -rn "algorithms=\[.*HS256.*RS256\|algorithms=\[.*RS256.*HS256" --include="*.py" .Une fois la dépendance identifiée, la deuxième étape consiste à vérifier la configuration de l’appel de décodage. Si l’application autorise à la fois des algorithmes symétriques HS256 et asymétriques RS256 ou ES256 dans le même paramètre, elle est potentiellement exposée, indépendamment de la version exacte de python-jose installée.
Les mesures de mitigation recommandées en l’absence de correctif
Faute de version corrigée disponible, la réponse repose entièrement sur des mesures de configuration côté application. Ces mesures ne sont pas de simples pansements temporaires : elles correspondent aux bonnes pratiques que l’OWASP recommande depuis des années pour toute implémentation JWT, correctif ou non.
| Mesure | Effet concret | Priorité |
|---|---|---|
| Restreindre explicitement l’algorithme attendu au décodage | Empêche l’acceptation implicite de HS256 sur un service RS256/ES256 | Critique |
| Séparer strictement les types de clés dans le code | Empêche la réutilisation d’une clé publique comme secret partagé | Critique |
| Auditer toutes les dépendances transitives Python | Révèle une présence cachée de python-jose dans la chaîne d’appel | Élevée |
| Migrer vers une bibliothèque activement maintenue (PyJWT, authlib) | Réduit l’exposition à un projet sans réponse depuis plus de trois semaines | Élevée |
| Mettre en place la rotation régulière des clés de signature | Limite la fenêtre d’exploitation en cas de compromission | Moyenne |
| Journaliser et alerter sur les échecs de vérification de signature | Permet de détecter une tentative de forgerie en cours | Moyenne |
La recommandation la plus citée par les analystes reste la première : fixer l’algorithme attendu côté vérificateur, sans jamais faire confiance à l’en-tête du jeton entrant pour déterminer comment le vérifier. Cette règle simple aurait suffi, seule, à neutraliser la quasi-totalité des dix incidents recensés plus haut.
Pourquoi les mainteneurs open source restent silencieux
Le silence des mainteneurs de python-jose face à une faille notée 9,1 pose une question plus large sur la fragilité des bibliothèques cryptographiques open source. Contrairement à OpenSSL ou à PyJWT, qui bénéficient d’équipes actives et parfois d’un financement dédié à la sécurité, de nombreuses bibliothèques d’authentification reposent sur un nombre réduit de contributeurs bénévoles.
Aucune fondation, aucun sponsor commercial ni aucune déclaration publique n’a été identifié en lien avec python-jose depuis la divulgation de CVE-2026-85394. Les avis de sécurité se limitent à renvoyer vers le suivi des tickets GitHub du projet, sans engagement de calendrier. Ce vide contraste avec le traitement réservé à des CVE de gravité comparable dans des projets mieux financés, où un correctif sort généralement en quelques jours.
Marché : le coût réel d’une faille d’authentification
Une forgerie de jeton réussie ne se limite pas à un accès non autorisé isolé. Elle donne potentiellement à l’attaquant les mêmes droits qu’un compte légitime, ce qui peut déclencher une chaîne d’incidents : exfiltration de données, mouvement latéral vers d’autres systèmes, ou fraude financière si l’API concernée gère des paiements. Les équipes de réponse à incident classent systématiquement ce type de compromission dans la catégorie la plus coûteuse à traiter, car elle nécessite de révoquer et de réémettre l’ensemble des jetons actifs, pas seulement de corriger le code.
Sur le plan commercial, cet épisode renforce l’argument des fournisseurs d’identité gérée comme Auth0, Okta ou Keycloak, qui vendent précisément la promesse de ne pas avoir à maintenir soi-même une pile de vérification de jetons. À l’inverse, les équipes qui ont construit leur propre couche d’authentification sur une bibliothèque tierce peu maintenue se retrouvent en première ligne, sans filet de sécurité commercial vers qui se tourner.
Ce que prévoient les analystes pour les prochains mois
Plusieurs évolutions semblent probables dans les mois qui suivent cette divulgation, sur la base du rythme observé depuis janvier 2026 et du calendrier réglementaire déjà fixé.
- D’autres bibliothèques JOSE plus anciennes ou moins actives devraient révéler des défauts similaires dans les prochains mois, le motif CWE-347 s’étant déjà répété dix fois en 2026 sur des piles technologiques totalement différentes.
- Sans réaction des mainteneurs, python-jose risque d’être progressivement marqué comme déconseillé par les scanners de dépendances automatiques, poussant les équipes à migrer vers PyJWT ou authlib.
- Les obligations de signalement sous 24 heures issues du Cyber Resilience Act devraient accélérer la publication d’avis de sécurité, y compris pour des composants sans correctif disponible.
- Les fournisseurs cloud devraient renforcer leurs outils de scan de configuration pour repérer automatiquement les appels de décodage JWT qui mélangent algorithmes symétriques et asymétriques.
- La demande pour des services d’identité gérée devrait continuer à progresser en Europe, notamment dans les secteurs soumis à DORA et NIS2, au détriment des implémentations JWT maison.
Ce que cela change pour les développeurs au quotidien
Au-delà du cas précis de python-jose, cet épisode rappelle une règle simple trop souvent négligée dans les revues de code : ne jamais laisser un jeton entrant décider lui-même de la méthode utilisée pour le vérifier. Cette règle coûte quelques lignes de configuration, mais elle referme une classe entière de vulnérabilités qui continue, dix ans après sa première documentation publique, à réapparaître dans des bibliothèques toujours différentes.
Pour les équipes françaises et européennes soumises à des obligations de signalement de plus en plus strictes, la leçon pratique est double. D’abord, un audit régulier des dépendances transitives reste indispensable, car une bibliothèque comme python-jose peut se cacher plusieurs niveaux sous un framework d’authentification tiers. Ensuite, la vitesse de correction d’un projet open source ne peut plus être présumée : elle doit être vérifiée avant de baser une brique d’authentification critique sur un composant dont la vitalité n’est pas garantie.
Foire aux questions
Qu’est-ce que CVE-2026-85394 exactement ?
C’est une vulnérabilité critique, notée 9,1 sur l’échelle CVSS, qui touche la bibliothèque Python python-jose jusqu’à la version 3.5.0. Elle permet à un attaquant possédant la clé publique d’un service de forger des jetons JWT signés en HS256 qui passent la vérification, à cause d’une mauvaise validation des clés lors de l’initialisation HMAC.
Existe-t-il un correctif disponible ?
Non. À la date du 21 septembre 2026, aucune version corrigée de python-jose n’a été publiée, ni référencée par les traqueurs de vulnérabilités consultés. Les avis de sécurité recommandent uniquement des contournements de configuration côté application en attendant.
Comment savoir si mon application utilise python-jose ?
Un audit de dépendances avec pip-audit ou un scanner de composition logicielle permet de détecter sa présence, y compris lorsqu’elle est installée de façon transitive par un autre framework d’authentification, sans être mentionnée directement dans le code de l’application.
Quelle est la différence entre cette faille et celle de PyJWT ?
Les deux failles, CVE-2026-85394 pour python-jose et CVE-2026-48526 pour PyJWT, exploitent le même principe de confusion d’algorithme, une clé publique réutilisée comme secret HMAC. La différence tient à la réponse apportée : PyJWT a publié un correctif, la version 2.13.0, avant même la divulgation publique de sa faille, alors que python-jose reste sans réponse plusieurs semaines après.
Cette faille est-elle activement exploitée ?
Aucune preuve d’exploitation active dans la nature n’a été documentée par les sources consultées à la date de publication de cet article. La CVE ne figure pas non plus dans un catalogue public de vulnérabilités activement exploitées à ce jour.
Que doivent faire les entreprises soumises au Cyber Resilience Act ?
Depuis le 11 septembre 2026, l’article 14 du Cyber Resilience Act impose un signalement sous 24 heures pour toute vulnérabilité activement exploitée dans un produit numérique. Une entreprise qui identifie python-jose dans sa chaîne de dépendances doit documenter son exposition et ses mesures de mitigation, même en l’absence de correctif officiel disponible.
Faut-il migrer vers une autre bibliothèque JWT ?
C’est la recommandation la plus fréquente chez les analystes cités dans cet article, notamment vers PyJWT ou authlib, deux bibliothèques activement maintenues qui ont déjà démontré leur capacité à corriger rapidement une faille similaire.
Pourquoi ce type de faille revient-il aussi souvent ?
La confusion d’algorithme dans les jetons JWT est documentée depuis 2015. Elle continue de réapparaître parce que la spécification laisse l’algorithme de vérification au choix de l’émetteur du jeton, et que de nombreux développeurs, encore aujourd’hui, ne fixent pas explicitement cet algorithme côté vérificateur.
