JWT Security Implementation Bugs: What Penetration Testers Find and How Developers Can Fix Them Before the Assessment

This is the most sophisticated JWT attack and the one with the highest impact. It exploits the trust relationship between the JWT header's alg field and how the server selects the verification algorithm.

When an application uses RS256 (asymmetric signing), it signs tokens with a private RSA key and verifies them with the corresponding public key. The public key is often published (JWKS endpoint, documentation, or embedded in the application). An attacker who observes the public key can:

1. Change the JWT header's alg field from RS256 to HS256
2. Re-sign the token using HMAC-SHA256 with the RSA public key as the HMAC secret
3. Submit the modified token

If the server selects the verification algorithm based on what the JWT header claims (rather than what the server expects), it will verify the token's HMAC signature using the RSA public key as the HMAC secret. The signature is valid because the attacker signed it with the same key the server is now using for verification. Authentication is bypassed.

The fix is simple but must be applied at every verification site:

# WRONG - trusts the alg from the token header
decoded = jwt.decode(token, public_key, algorithms=jwt.get_unverified_header(token)['alg'])

# CORRECT - specifies the expected algorithm explicitly
decoded = jwt.decode(token, public_key, algorithms=['RS256'])

Never pass the algorithm from the token header to the decode/verify function. Always hardcode the algorithm your application expects.

The JWT specification includes none as a valid alg value, indicating an unsigned token. Early JWT library implementations accepted none algorithm tokens as valid if the application did not explicitly disable unsigned tokens. The vulnerability:

1. Decode an existing valid JWT (base64 decode without verification)
2. Modify the payload (e.g., change sub to another user's ID or role to admin)
3. Change the header alg to none (or None, NONE, nOnE for case-insensitive matching)
4. Re-encode without a signature (trailing dot only: header.payload.)
5. Submit the token

Most modern libraries have patched this by default, but legacy code or custom JWT parsers may still be vulnerable.

The fix:

# PyJWT - reject none algorithm explicitly
decoded = jwt.decode(token, secret_key, algorithms=['HS256'])  # only HS256 accepted

# Node.js jsonwebtoken - same pattern
jwt.verify(token, secret, { algorithms: ['HS256'] });

# Java (jjwt) - specify allowed algorithms
Jwts.parserBuilder()
    .setSigningKey(key)
    .build()
    .parseClaimsJws(token);  # parseClaimsJws rejects unsigned tokens; parseClaims would accept them

The distinction in Java's JJWT library between parseClaimsJws() (requires signature) and parseClaimsJwt() (accepts unsigned) is a common source of vulnerabilities when developers pick the wrong method.

HS256 JWTs are only as secure as the secret used to sign them. If the application uses a short, guessable, or default secret, an attacker who captures a valid JWT can crack the secret offline and forge tokens for any identity.

The attack:

# Extract the JWT and attempt to crack it with a wordlist
hashcat -a 0 -m 16500 "eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyMSJ9.signature" /usr/share/wordlists/rockyou.txt

# Or try a brute-force of short secrets (6 chars, letters+digits)
hashcat -a 3 -m 16500 "eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyMSJ9.signature" ?a?a?a?a?a?a

Common weak secrets found in penetration tests:

• secret (the default in dozens of JWT tutorials)
• password, 1234, changeme
• Application name, company name, or environment name
• A short UUID or MD5 hash of a predictable value

For HS256, use a cryptographically random secret of at least 256 bits (32 bytes). Never use a secret derived from application configuration without appropriate entropy.

Generating a secure secret:

import secrets
secret = secrets.token_hex(32)  # 256-bit hex string, 64 characters
print(secret)  # Store this in a secrets manager, never in source code

For production systems, prefer RS256 over HS256. RS256 has no equivalent weak-key attack because the verification key (public key) cannot be used to forge tokens. The private key never leaves the signing service.

JWT libraries validate the signature by default, but claim validation is often optional or must be configured explicitly. Penetration testers regularly find applications that accept expired tokens, tokens issued for different audiences, or tokens with future nbf (not before) claims.

Claims that must always be validated:

exp (expiration time): If the application does not check exp, an attacker who steals a JWT can use it indefinitely. Most libraries validate exp by default but have options to disable it for testing that are sometimes left in production code.

aud (audience): Identifies the intended recipient. If your API issues tokens with aud: api.service.com but also accepts tokens issued for aud: internal.service.com, an attacker can use a token from a lower-privilege service to access your API.

iss (issuer): Identifies the token issuer. If not validated, an attacker can create tokens signed with a different key from a different identity provider.

Explicit claim validation in Python (PyJWT):

decoded = jwt.decode(
    token,
    public_key,
    algorithms=['RS256'],
    options={
        'require': ['exp', 'iss', 'aud', 'sub'],  # require these claims to be present
        'verify_exp': True,
        'verify_iss': True,
        'verify_aud': True,
    },
    audience='api.yourdomain.com',
    issuer='https://auth.yourdomain.com'
)

In Node.js (jsonwebtoken):

jwt.verify(token, publicKey, {
  algorithms: ['RS256'],
  audience: 'api.yourdomain.com',
  issuer: 'https://auth.yourdomain.com',
  // exp is checked by default unless clockTolerance is set too high
});

Do not set clockTolerance above 60 seconds. A tolerance of 300+ seconds effectively extends token expiry by 5 minutes and is exploitable if tokens are stolen.

Two less common but high-impact JWT attack vectors that pen testers find in more sophisticated implementations:

JWK Header Injection (CVE class): The OIDC spec allows JWTs to embed the verification key directly in the token header via the jwk parameter. An attacker generates a key pair, embeds the public key in the token header, signs the token with the corresponding private key, and if the application trusts the embedded key, verifies successfully. Fix: Never trust keys embedded in the token header. Always fetch verification keys from a trusted JWKS endpoint (configured at startup) or use a hardcoded key material.

Kid (Key ID) SSRF and SQL Injection: Some applications use the kid header parameter to look up the correct signing key in a database or from a file path. If the kid value is used in a SQL query or filesystem path without sanitization:

• SQL injection: kid = "' UNION SELECT 'attacker-controlled-secret' --"
• Path traversal: kid = "../../dev/null" (empty file used as secret for unsigned verification)

Fix: Validate the kid value against a whitelist of known key IDs before using it to look up a key. Never construct a database query or file path directly from the JWT header value.

# WRONG - kid value used directly
with open(f"/keys/{header['kid']}.pem") as f:
    key = f.read()

# CORRECT - whitelist check before key lookup
ALLOWED_KEY_IDS = {'2026-01', '2026-06', 'legacy-2025-07'}
if header.get('kid') not in ALLOWED_KEY_IDS:
    raise ValueError("Unknown key ID")
key = KEY_STORE[header['kid']]