Vulnérabilités JWT

Que sont les vulnérabilités JWT ?#

Les JSON Web Tokens (JWT) sont le mécanisme d'authentification sans état dominant dans les API modernes et les applications monopage. Chaque token est un triplet en-tête.charge_utile.signature encodé en base64url qui transporte des revendications d'identité — sub, role, email, exp — et est auto-vérifié par le serveur sans consulter un magasin de sessions central. Le modèle de sécurité repose entièrement sur la validation correcte de la signature par le serveur avant de faire confiance à toute revendication.

Les vulnérabilités JWT surviennent quand cette validation est absente, incomplète ou manipulable. Elles relèvent de CWE-287 (Authentification incorrecte) au niveau catégorie, avec des sous-classes couvrant CWE-347 (Vérification incorrecte d'une signature cryptographique), CWE-89 (Injection SQL via kid), CWE-78 (Injection de commande OS via kid) et CWE-345 (Vérification insuffisante de l'authenticité des données pour les attaques de source de clé). L'OWASP classe la catégorie sous A07:2021 (Identification et authentification incorrectes) comme classification principale.

Les attaques documentées ici ne sont pas théoriques. Six CVE avec des scores CVSS supérieurs à 8.0 ont été divulguées dans la fenêtre 2025-2026 — CVE-2026-22817 (Hono), CVE-2026-34950 (fast-jwt), CVE-2026-27804 (Parse Server), CVE-2026-23552 (Keycloak), CVE-2024-54150 (jose) et CVE-2024-48916 (Ceph) — dans les écosystèmes Node.js, Java, Python et Go simultanément.

Mécanisme#

Un token JWT comporte trois segments encodés en base64url séparés par des points. L'en-tête déclare l'algorithme et l'identifiant de clé. La charge utile transporte les revendications. La signature est un lien cryptographique.

La surface d'attaque se situe à chaque étape de ce flux :

1. Étape 1 (décodage en-tête) : Si le serveur fait confiance à header.alg plutôt qu'appliquer une liste d'autorisation, l'attaquant change alg en none ou HS256 pour contrôler l'algorithme de vérification.
2. Recherche kid : Si kid est utilisé dans une requête base de données ou chemin de fichier sans assainissement, l'attaquant injecte SQL ou traversée de chemin pour forcer le serveur à utiliser une clé contrôlée par l'attaquant.
3. Récupération de clé distante : Si jku, x5u ou les champs jwk/x5c intégrés sont supportés sans liste d'autorisation, l'attaquant fournit une URL ou du matériel de clé pointant vers ses propres ressources cryptographiques.
4. Confiance dans les revendications : Même avec une signature valide, des revendications mutables comme email ou des champs role personnalisés peuvent être falsifiés pour escalader les privilèges.

L'attaque minimale canonique — le contournement alg:none — ne nécessite que l'encodage base64url :

import base64, json
 
def b64url(data: bytes) -> str:
    return base64.urlsafe_b64encode(data).rstrip(b'=').decode()
 
# Forger un token réclamant le rôle admin, aucune signature nécessaire
header  = b64url(json.dumps({"alg": "none", "typ": "JWT"}).encode())
payload = b64url(json.dumps({"sub": "attaquant", "role": "admin", "exp": 9999999999}).encode())
forge   = f"{header}.{payload}."   # segment de signature vide

Paramètres d'en-tête — Surface d'attaque#

Variantes d'attaque#

Confusion d'algorithme (alg:none + RS256→HS256)#

L'attaque alg:none contourne la vérification de signature en indiquant à la bibliothèque qu'aucun algorithme de signature n'a été utilisé. Les variantes de casse — None, NONE, nOnE, nonE, none (espace initial) — contournent les filtres de correspondance de chaînes simples. CVE-2026-34950 dans fast-jwt a réactivé cette classe via un contournement de regex utilisant un espace initial.

L'attaque de confusion RS256→HS256 est plus sophistiquée. RS256 vérifie avec une clé publique ; HS256 vérifie avec un secret partagé. En déclassant vers HS256 et en signant avec la clé publique RSA publique du serveur (disponible depuis JWKS ou TLS), l'attaquant fait vérifier HS256 contre sa propre clé publique connue — et accepte le token. Voir Attaque JWT alg:none.

Secrets HMAC faibles#

HS256, HS384 et HS512 utilisent une clé symétrique — le même secret est utilisé pour signer et vérifier. Si le secret est un mot du dictionnaire, une courte chaîne ou une valeur inférieure à 32 octets, la force brute hors ligne avec hashcat -m 16500 le craque en quelques secondes. Voir Secret JWT faible.

Injection kid#

Le paramètre kid identifie la clé à utiliser pour la vérification. Les implémentations non validées permettent l'injection SQL, la traversée de chemin, l'injection de commande OS, l'injection NoSQL et l'injection LDAP. Voir Injection JWT kid.

Injection d'en-tête jwk (CVE-2018-0114)#

L'attaquant génère une paire de clés RSA, intègre sa clé publique dans l'en-tête JWT sous le champ jwk, signe avec sa clé privée, et le serveur vérifie contre la clé publique intégrée — acceptant le token. Voir Injection JWT jwk.

Injection de certificat x5c / x5u#

x5c intègre une chaîne de certificats DER ; x5u fournit une URL pour récupérer le certificat. x5u est simultanément un vecteur SSRF — la récupération HTTP côté serveur atteint des services internes. Voir Injection JWT x5c / x5u.

Exemples réels#

CVE-2026-22817 — Middleware JWK Hono (CVSS 8,2) Le middleware JWT de Hono n'imposait pas d'exigence d'algorithme lors du traitement des tokens JWK. Un token sans champ alg dans le JWK causait une confusion d'algorithme. Le pattern correspond à la classe JWKSAlgAbsent.

CVE-2026-34950 — Réactivation confusion algorithme fast-jwt (CVSS 9,1) fast-jwt avait patché CVE-2023-48223 via une regex. Le contournement 2026 utilisait un espace initial ( HS256) — la regex échouait et la bibliothèque acceptait l'algorithme de l'en-tête directement.

CVE-2026-27804 — Confusion d'algorithme OAuth2 Parse Server (CVSS 9,8) L'intégration OAuth2 de Parse Server avec Google et Apple n'imposait pas le champ alg dans le JWKS, permettant le contournement d'authentification.

CVE-2026-23552 — Relais de token cross-realm Keycloak (CVSS 9,1) Keycloak acceptait un token émis pour le realm A par le realm B quand la revendication iss n'était pas strictement validée par realm.

CVE-2024-54150 — jose (Cisco) Confusion RS256→HS256 (CVSS 9,1) La bibliothèque jose utilisée dans les produits Cisco acceptait des tokens signés HS256 alors que configurée pour RS256.

CVE-2022-21449 — Psychic Signatures Java (CVSS 7,5) Java SE 15-18 acceptait une signature ECDSA avec r=0 et s=0 comme valide pour n'importe quel message. Découvert par Neil Madden (ForgeRock).

CVE-2018-0114 — Injection jwk node-jose (CVSS 9,3) node-jose faisait confiance sans condition à la clé publique intégrée dans l'en-tête JWT jwk. La classe d'attaque a été redécouverte dans des dizaines de bibliothèques depuis.

Dérive de revendication mutable Allianz/Salesforce (2025) ShinyHunters a exploité des applications identifiant les utilisateurs par la revendication email JWT plutôt que par le sub immuable. Un attaquant changeait son email inscrit chez l'IdP pour correspondre à celui d'une victime — prise de contrôle de compte complète sans toucher au matériel cryptographique.

Détection#

Tests manuels#

1. Décoder le token avec jwt.io et inspecter les champs alg, kid, jku, x5u, jwk et x5c.
2. Test alg:none : modifier l'en-tête en {"alg":"none","typ":"JWT"}, supprimer la signature (garder le point final), renvoyer. Tester les variantes de casse : None, NONE, nOnE, nonE, none.
3. Test RS256→HS256 : récupérer la clé publique du serveur depuis /.well-known/jwks.json ou via openssl s_client. Utiliser jwt_tool : python3 jwt_tool.py "$TOKEN" -X k -pk pubkey.pem -I -pc role -pv admin.
4. Test injection kid : avec Burp JWT Editor, définir kid à ../../dev/null puis à des charges SQL (x' UNION SELECT 'AAAAAAAAA' -- -). Signer avec un secret HMAC vide.
5. Test jku/jwk/x5u : utiliser les attaques "JWK intégré" ou "Injection JKU" de Burp JWT Editor. Surveiller Burp Collaborator pour les rappels DNS/HTTP.
6. Test secret faible : exécuter hashcat -m 16500 token.txt /usr/share/wordlists/rockyou.txt.

Détection automatisée#

jwt_tool (v2.2.6+) en mode playbook couvrant 20+ attaques :

python3 /opt/jwt_tool/jwt_tool.py "$TOKEN" -M pb -np

Burp Suite JWT Editor détecte automatiquement les points d'injection jku, x5c, x5u, jwk et kid.

hashcat pour la récupération du secret HMAC :

hashcat -m 16500 -a 0 token_capture.txt /usr/share/wordlists/rockyou.txt

BreachVex détecte les vulnérabilités JWT via une séquence d'attaque multi-étapes : il découvre les endpoints JWKS sur les chemins standards, établit un oracle d'authentification vérifié (triple-baseline : valide→200, sans token→401, corrompu→401), teste toutes les variantes de confusion d'algorithme dont les 8 permutations de casse alg:none, sonde l'injection de source de clé avec des rappels hors-bande pour le SSRF jku/x5u, fuzze kid avec des charges de traversée de chemin et SQLi/CMDi, et exécute le craquage HMAC sur les tokens symétriques. Chaque vulnérabilité exige une validation différentielle du corps de réponse avant signalement.

Prévention#

Liste d'autorisation d'algorithme explicite#

La défense la plus importante — refuser de faire confiance au champ alg de l'en-tête JWT :

# MAUVAIS — fait confiance à l'algorithme de l'en-tête
import jwt
decoded = jwt.decode(token, key, algorithms=jwt.get_unverified_header(token)["alg"])
 
# BON — liste d'autorisation explicite côté serveur
ALGORITHMES_AUTORISES = ["RS256"]
decoded = jwt.decode(token, cle_publique, algorithms=ALGORITHMES_AUTORISES)

// MAUVAIS — jsonwebtoken fait confiance à l'algorithme de l'en-tête
const payload = jwt.verify(token, secret)
 
// BON — liste d'autorisation explicite
const payload = jwt.verify(token, cle_publique, { algorithms: ['RS256'] })

Sub immuable pour l'identité#

# MAUVAIS — revendication mutable, vulnérable à la prise de contrôle de compte
utilisateur = db.users.find_one({"email": decoded["email"]})
 
# BON — sub immuable selon RFC 7519 §4.1.2
utilisateur = db.users.find_one({"oidc_sub": decoded["sub"]})

Validation de kid#

import re
 
# MAUVAIS — traversée de chemin et vecteur SQLi
cle = open(f"/keys/{header['kid']}").read()
 
# BON — regex stricte + requête paramétrée
KID_PATTERN = re.compile(r'^[a-zA-Z0-9_-]{1,64}$')
if not KID_PATTERN.fullmatch(header.get("kid", "")):
    raise ValueError("Format kid invalide")
ligne = db.execute("SELECT k FROM keys WHERE id = $1", (header["kid"],)).fetchone()

Désactiver les paramètres d'en-tête dangereux#

ENTETES_INTERDITS = {"jku", "x5u", "jwk", "x5c"}
 
def verifier_jwt(token: str, alg_attendu: str, cle_publique) -> dict:
    entete = jwt.get_unverified_header(token)
    trouves = ENTETES_INTERDITS & entete.keys()
    if trouves:
        raise SecurityError(f"Paramètres d'en-tête JWT interdits : {trouves}")
    if entete.get("alg") != alg_attendu:
        raise SecurityError("Algorithme inattendu")
    return jwt.decode(token, cle_publique, algorithms=[alg_attendu])

Ressources#

• PortSwigger Web Security Academy — Attaques JWT
• Aide-mémoire OWASP JWT
• RFC 7519 — JSON Web Token
• RFC 9700 — Meilleures pratiques de sécurité OAuth 2.0