How to Fix the JWT None Algorithm Attack

How the none algorithm attack works

A JWT has three base64url-encoded parts: header.payload.signature. The header declares which algorithm was used to sign the token:

{"alg": "HS256", "typ": "JWT"}

The alg: "none" variant tells the library "this token is unsecured - no signature required." The spec allows it for tokens transmitted over a secure channel where both parties already trust each other. In practice, a vulnerable jwt.decode() call will honor alg: "none" even when that was never the application's intent.

An attacker crafts a token by hand: take any valid payload (e.g. {"sub": "admin", "role": "superuser"}), base64url-encode it, change the header's alg to "none", and omit the signature (or append an empty string after the final dot). The server accepts it as legitimate:

import jwt, base64, json

# Forge a token with alg=none
header = base64.urlsafe_b64encode(json.dumps({"alg": "none", "typ": "JWT"}).encode()).rstrip(b"=")
payload = base64.urlsafe_b64encode(json.dumps({"sub": "admin", "role": "superuser"}).encode()).rstrip(b"=")
forged = header.decode() + "." + payload.decode() + "."  # no signature

# On a vulnerable server this verifies successfully:
# decoded = jwt.decode(forged, "secret", algorithms=["HS256", "none"])

The vulnerable decode call

The root cause is calling jwt.decode() without an explicit algorithms parameter, or by including "none" in the list:

# VULNERABLE - accepts any algorithm the token claims, including "none"
data = jwt.decode(token, SECRET_KEY, algorithms=["HS256", "none"])

Without restriction, whatever algorithm the token header declares is trusted.

The fix: lock to an explicit allowlist

Pass only the algorithm your application actually uses:

# FIXED - rejects any token whose header declares a different alg
data = jwt.decode(token, SECRET_KEY, algorithms=["HS256"])

With algorithms=["HS256"], PyJWT raises jwt.exceptions.InvalidAlgorithmError for any token that declares "none", "RS256", or anything else outside the list. Existing valid HS256 tokens continue to work unchanged.

PyJWT version notes

PyJWT 2.0+ made the algorithms argument required - omitting it raises a DecodeError at startup rather than silently accepting any algorithm. If you are on an older version, you must pass the argument explicitly. Either way, never include "none" in the allowlist outside of a deliberate, sandboxed use case.

Defense-in-depth

• Audit every jwt.decode() call - a semgrep rule for jwt.decode without an algorithms argument catches this pattern across a codebase in seconds.
• Rotate secrets if tokens were accepted without verification - any forged token the server honored grants attacker-chosen claims; treat existing sessions as compromised.
• Prefer RS256 with a private signing key - even if a server exposes the public key, it cannot be used to forge a signature. "none" attacks still apply, so the allowlist fix is still required.