The Attack That Won’t Die

I found three apps last month with this exact vulnerability. All built with AI coding tools. All in production with real users.

JWTs are everywhere in 2026. Every auth tutorial uses them. Every AI coding assistant generates them. And that’s exactly the problem.

That’s how many AI-generated applications we’ve scanned that have JWT vulnerabilities. The ’none’ algorithm attack is the most common.

How JWT Signatures Work

A typical JWT looks like this:

1
2
3

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJ1c2VySWQiOjEyMywicm9sZSI6InVzZXIifQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Three parts separated by dots:

1. Header: {"alg":"HS256","typ":"JWT"} - declares the algorithm
2. Payload: {"userId":123,"role":"user"} - your actual data
3. Signature: HMAC-SHA256 of header + payload using a secret key

The server verifies the signature before trusting the payload. If the signature doesn’t match, the token is rejected. Simple and secure.

Until someone changes the algorithm.

The ’none’ Algorithm Attack

The JWT spec includes a special algorithm value: none. It means “no signature required.” This exists for debugging and specific trust scenarios where tokens are transmitted over already-secure channels.

Here’s how the attack works:

1. Attacker intercepts a valid JWT
2. Decodes the header and changes "alg":"HS256" to "alg":"none"
3. Modifies the payload (changes "role":"user" to "role":"admin")
4. Removes the signature entirely
5. Server reads the algorithm from the header, sees none, skips verification
6. Attacker is now admin

The forged token:

1
2

eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.
eyJ1c2VySWQiOjEyMywicm9sZSI6ImFkbWluIn0.

No signature. Full access.

Why This Still Happens

Most JWT libraries support ’none’ by default. The library reads the algorithm from the token header and uses it for verification. If the token says “don’t verify me,” the library complies.

Here’s vulnerable Node.js code I see constantly:

1
2

// VULNERABLE - trusts the algorithm in the token
const decoded = jwt.verify(token, secret);

The jwt.verify function reads the alg header from the token itself. If an attacker sends a token with alg: "none", some libraries skip verification entirely.

AI coding assistants love generating this pattern because it’s simple and it works in happy-path testing.

Related JWT Attacks

The ’none’ algorithm is just one attack in a family of algorithm confusion vulnerabilities.

Algorithm Confusion (RS256 to HS256)

RS256 uses asymmetric cryptography: sign with private key, verify with public key. HS256 uses symmetric: same secret for both.

Attack: Server is configured for RS256. Attacker changes the token header to HS256, signs with the public key (which is often publicly available), and the server accepts it because it treats the public key as the HMAC secret.

1
2
3
4

// Server expects RS256 (asymmetric)
// Attacker sends token with alg: HS256
// Server verifies with public key as HMAC secret
// Signature matches because attacker signed with same public key

JKU/JWK Injection

Some JWT implementations fetch the verification key from a URL specified in the token header (jku claim). Attacker points this to their own server hosting a malicious key.

kid Path Traversal

The kid (key ID) header tells the server which key to use. If the server uses this value in a file path without validation:

1
2

// VULNERABLE
const key = fs.readFileSync(`/keys/${token.header.kid}`);

Attacker sets kid to ../../../dev/null and the signature check passes against an empty file.

Detecting JWT Vulnerabilities

1
2
3
4
5
6
7

# Original token
echo "eyJhbGciOiJIUzI1NiJ9.eyJ1c2VySWQiOjF9.signature" | cut -d. -f1 | base64 -d
# {"alg":"HS256"}

# Forge token with none
echo -n '{"alg":"none","typ":"JWT"}' | base64 | tr -d '='
# eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0

1

jwt_tool <token> -X a -pk public_key.pem

Fixing JWT Vulnerabilities

The fix is straightforward: never trust the algorithm specified in the token.

Secure Implementation

1
2
3
4

// SECURE - explicitly specify allowed algorithms
const decoded = jwt.verify(token, secret, {
  algorithms: ['HS256']  // Whitelist only what you use
});

For asymmetric algorithms:

1
2
3
4

// SECURE - RS256 with algorithm whitelist
const decoded = jwt.verify(token, publicKey, {
  algorithms: ['RS256']
});

Key Principles

1. Whitelist algorithms explicitly - Never accept whatever the token claims
2. Disable ’none’ - Most libraries have options to reject ’none’ algorithm
3. Use established libraries - Don’t roll your own JWT verification
4. Store secrets properly - Use environment variables, not code
5. Don’t store JWTs in localStorage - That’s an XSS attack waiting to happen

Framework-Specific Fixes

Node.js (jsonwebtoken):

1

jwt.verify(token, secret, { algorithms: ['HS256'] });

Python (PyJWT):

1

jwt.decode(token, secret, algorithms=['HS256'])

Java (jjwt):

1
2
3
4

Jwts.parserBuilder()
    .setSigningKey(key)
    .build()
    .parseClaimsJws(token);  // Rejects none by default

How Vibe-Eval Catches This

Our scanner analyzes your application for JWT handling patterns:

• Detects tokens in responses and decodes them
• Tests algorithm manipulation attacks automatically
• Flags localStorage JWT storage (XSS vector)
• Checks for missing expiration claims
• Identifies hardcoded secrets in JavaScript bundles

When we find JWT vulnerabilities, the report includes the specific attack vector and exact code location to fix.

FAQ

Key Takeaways