JWT Vulnerabilities: alg=none & Key Confusion

JWTs are cryptographically signed but many libraries had severe vulnerabilities. The most exploited: the alg=none attack, the RS256→HS256 confusion attack, and weak secret brute-forcing. All stem from trusting attacker-controlled header fields.

The JWT spec allows alg:"none" for unsecured tokens. Buggy libraries accepted this and skipped signature verification entirely. An attacker modifies the payload (e.g., "role":"admin"), sets alg:"none", strips the signature, and the server accepts it.

Original: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyIn0.SIG Attack: eyJhbGciOiJub25lIn0.eyJzdWIiOiJhZG1pbiJ9. (empty signature, trailing dot). A vulnerable server verifies successfully and grants admin access.

Never accept alg:"none" in production. Explicitly whitelist allowed algorithms: jwt.decode(token, key, algorithms=["HS256"]). Most modern libraries (PyJWT 2+, jsonwebtoken 9+) reject alg=none by default.

If a server uses RS256 and a client changes alg to HS256, the server might verify using its RSA public key as the HMAC secret. Since the public key is... public, the attacker signs arbitrary payloads with it and the server verifies them.

Steps: 1) Fetch public key from JWKS endpoint. 2) Build malicious payload. 3) Sign with HMAC-SHA256 using the raw public key PEM bytes as the HMAC secret. 4) Set alg:"HS256" in header. 5) Server's HS256 path verifies successfully.

Always specify the expected algorithm explicitly in the verify call. Never derive the algorithm from the token header. Use separate code paths for RS256 and HS256 that cannot be switched by the caller.

HS256 with weak secrets (less than 256 bits of entropy) can be brute-forced offline. Tools like hashcat support JWT cracking: hashcat -a 0 -m 16500 token.txt wordlist.txt. Use cryptographically random secrets of at least 32 bytes.

The kid (key ID) header selects which key to use. If the server uses kid as a SQL query parameter or filesystem path without sanitization: kid="../../dev/null" → HMAC with empty key → forged token accepted. Always sanitize kid.

The jwk header embeds a public key for verification. A vulnerable server might use the embedded key directly, letting the attacker supply their own key pair, sign the token with the private key, and embed the public key. Verify only against registered keys.

Some implementations forgot to check the exp claim, or used server time inconsistently. Always explicitly validate exp, nbf, and iat. Use a library that checks these by default and never disable claim validation in production.

In the RS256→HS256 key confusion attack, what does the attacker use as the HMAC secret?

JWT vulnerabilities arise from trusting the alg header, accepting alg=none, and weak secrets. Fix: pin algorithms at the verifier, use strong secrets, and sanitize kid. Next: secure JWT implementation practices.