JWT Vulnerabilities

What are JWT Vulnerabilities?#

JSON Web Tokens (JWTs) are the dominant stateless authentication mechanism in modern APIs and single-page applications. Each token is a base64url-encoded header.payload.signature triple that carries identity claims — sub, role, email, exp — and is self-verified by the server without consulting a central session store. The security model depends entirely on the server correctly validating the signature before trusting any claim.

JWT vulnerabilities arise when that validation is absent, incomplete, or manipulable. They fall under CWE-287 (Improper Authentication) at the category level, with sub-classes spanning CWE-347 (Improper Verification of Cryptographic Signature), CWE-89 (SQL Injection via kid), CWE-78 (OS Command Injection via kid), and CWE-345 (Insufficient Verification of Data Authenticity for key-source attacks). OWASP maps the category to A07:2021 (Identification and Authentication Failures) as the primary classification, with A02:2021 (Cryptographic Failures) and A03:2021 (Injection) as secondary.

The attacks documented here are not theoretical. Six CVEs with CVSS scores above 8.0 were disclosed in the 2025-2026 window alone — CVE-2026-22817 (Hono), CVE-2026-34950 (fast-jwt), CVE-2026-27804 (Parse Server), CVE-2026-23552 (Keycloak), CVE-2024-54150 (jose), and CVE-2024-48916 (Ceph) — across Node.js, Java, Python, and Go ecosystems simultaneously. According to the Wallarm API ThreatStats Report Q2 2025, algorithm confusion accounts for 23% of JWT CVEs, kid injection for 18%, and mutable claim drift for 14%.

Mechanism#

A JWT token has three base64url-encoded segments separated by dots. The header declares the algorithm and key identifier. The payload carries the claims. The signature is a cryptographic binding.

The attack surface lives in every step of that flow:

1. Step 1 (header decode): If the server trusts header.alg rather than enforcing an allowlist, the attacker changes alg to none or to HS256 to control the verification algorithm.
2. Kid lookup: If kid is used in a database query or filesystem path without sanitization, the attacker injects SQL or path traversal to make the server use an attacker-controlled key.
3. Remote key fetch: If jku, x5u, or embedded jwk/x5c fields are supported without allowlisting, the attacker provides a URL or key material pointing to their own cryptographic material.
4. Claim trust: Even with a valid signature, mutable claims like email or custom role fields may be tampered to escalate privileges.

The canonical minimal attack — the alg:none bypass — requires just base64url encoding:

import base64, json
 
def b64url(data: bytes) -> str:
    return base64.urlsafe_b64encode(data).rstrip(b'=').decode()
 
# Forge a token claiming admin role, no signature needed
header  = b64url(json.dumps({"alg": "none", "typ": "JWT"}).encode())
payload = b64url(json.dumps({"sub": "attacker", "role": "admin", "exp": 9999999999}).encode())
forged  = f"{header}.{payload}."   # empty signature segment

GET /api/admin/users HTTP/1.1
Host: vulnerable.example.com
Authorization: Bearer eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJzdWIiOiJhdHRhY2tlciIsInJvbGUiOiJhZG1pbiIsImV4cCI6OTk5OTk5OTk5OX0.

Header Attacks — Attack Surface by Parameter#

Every optional field in the JWT header is a potential injection point. The following table maps parameters to their attack class and prevalence:

Attack Variants#

Algorithm Confusion (alg:none + RS256→HS256)#

The alg:none attack bypasses signature verification by telling the library that no signature algorithm was used. The library, trusting the header, skips HMAC/RSA verification and accepts any token with a valid structure. Case variants — None, NONE, nOnE, nonE, none (leading whitespace) — bypass simple lowercase string-match filters. CVE-2026-34950 in fast-jwt re-enabled this class via a regex bypass using leading whitespace.

The RS256→HS256 confusion attack is more sophisticated. RS256 verifies with a public key; HS256 verifies with a shared secret. By downgrading to HS256 and signing with the server's public RSA key (publicly available from JWKS or TLS), the attacker makes the server verify HS256 against its own known public key — and accept the token. See JWT alg:none Attack for full detail.

Weak HMAC Secrets#

HS256, HS384, and HS512 use a symmetric key — the same secret is used to sign and verify. If the secret is a dictionary word, a short string, or a value under 32 bytes, offline brute-force with hashcat -m 16500 cracks it against common wordlists in seconds. Once recovered, the attacker signs any arbitrary token. See JWT Weak Secret.

kid Parameter Injection#

The kid (key ID) parameter identifies which key to use for verification. Most implementations look it up in a database or resolve it as a file path. Unvalidated kid values enable SQL injection (x' UNION SELECT 'AAAAAAAAA' --), path traversal (../../dev/null), OS command injection, NoSQL injection, and LDAP injection. See JWT kid Injection.

jwk Header Injection (CVE-2018-0114)#

The jwk header parameter optionally embeds the verification key directly in the token header. CVE-2018-0114 in node-jose demonstrated that libraries accepting embedded JWK headers trusted the attacker-supplied public key unconditionally. The attacker generates an RSA keypair, embeds their public key in the header, signs with their private key, and the server verifies against the embedded public key — accepting the token. See JWT jwk Header Injection.

x5c / x5u Certificate Injection#

x5c embeds a DER-encoded certificate chain in the header; x5u provides a URL from which to fetch the certificate. Both allow an attacker to substitute attacker-controlled X.509 material for the server's trusted certificate. x5u is simultaneously an SSRF vector — the server-side HTTP fetch reaches internal services. See JWT x5c / x5u Injection.

Real-World Examples#

CVE-2026-22817 — Hono JWK Middleware (CVSS 8.2) Hono's JWT middleware before the fix did not enforce an algorithm requirement when processing JWK tokens. A token with no alg field in the JWK caused the library to fall back to an unintended default, enabling algorithm confusion. The pattern matches the JWKSAlgAbsent class: JWKS endpoints returning keys without specifying the allowed algorithm create an implicit trust surface for alg confusion. Fixed by requiring explicit alg in middleware configuration.

CVE-2026-34950 — fast-jwt Algorithm Confusion Re-enable (CVSS 9.1) fast-jwt originally patched CVE-2023-48223 using a regex /^[A-Z]+\d+$/ to block none. A 2026 bypass was found: adding a leading whitespace character ( HS256) caused the regex to not match, and the library fell back to accepting the header's algorithm field directly — re-enabling the original CVE for users on patched versions.

CVE-2026-27804 — Parse Server OAuth2 Algorithm Confusion (CVSS 9.8) Parse Server's OAuth2 integration with Google and Apple accepted JWTs signed with a weak algorithm because the server fetched the public key from the provider's JWKS without enforcing the alg field. An attacker controlling a Google/Apple-format JWKS response could bypass authentication entirely.

CVE-2026-23552 — Keycloak Cross-Realm Token Relay (CVSS 9.1) Keycloak allowed a token issued for realm A to be accepted by realm B when the application did not strictly validate the iss (issuer) claim. Organizations running multi-tenant Keycloak were exposed to cross-tenant account takeover by any user with an account on any realm.

CVE-2024-54150 — jose (Cisco) RS256→HS256 Confusion (CVSS 9.1) The jose library used in Cisco products accepted HS256-signed tokens when configured for RS256, using the RS256 public key as the HS256 secret. PentesterLab published a detailed writeup: "Another JWT Algorithm Confusion CVE-2024-54150".

CVE-2022-21449 — Java Psychic Signatures (CVSS 7.5) Java SE 15-18 accepted an ECDSA signature with r=0 and s=0 as valid for any message. Every JWT library built on Java's JCA (java-jwt, nimbus-jose-jwt, jose4j) on affected JVMs was completely bypassed. Discovered by Neil Madden (ForgeRock), fixed in the April 2022 CPU update.

CVE-2018-0114 — node-jose jwk Injection (CVSS 9.3) The original and most replicated jwk injection CVE. node-jose trusted the public key embedded in the jwk JWT header unconditionally. Attacker generates RSA keypair, embeds public key in header, signs with private key — server accepts the token. The attack class has been rediscovered in dozens of libraries since.

Allianz/Salesforce Mutable Claim Drift (2025) ShinyHunters exploited applications that identified users by the email JWT claim rather than the immutable sub claim. An attacker changed their registered email at the identity provider to match a victim's address. The IdP issued a new token with the victim's email. The vulnerable application executed SELECT * FROM users WHERE email = $1 using the JWT's email claim, granting full account takeover without touching cryptographic material.

Detection#

Manual Testing#

1. Decode the token with jwt.io or via Python — inspect alg, kid, jku, x5u, jwk, and x5c fields.
2. alg:none test: Modify the header to {"alg":"none","typ":"JWT"}, strip the signature (keep the trailing dot), resend. Test case variants: None, NONE, nOnE, nonE, none (leading space).
3. RS256→HS256 test: Retrieve the server's public key from /.well-known/jwks.json or via openssl s_client. Use jwt_tool: python3 jwt_tool.py "$TOKEN" -X k -pk pubkey.pem -I -pc role -pv admin. A 200 response confirms confusion.
4. kid injection test: With Burp JWT Editor, set kid to ../../dev/null, then to x' UNION SELECT 'AAAAAAAAA' -- -. Sign with an empty secret. A successful response confirms injection.
5. jku/jwk/x5u test: Use Burp JWT Editor's "Embedded JWK" or "Inject JKU" attacks. Point to an attacker-controlled JWKS URL. Monitor Burp Collaborator for DNS/HTTP callbacks.
6. Weak secret test: Run hashcat -m 16500 token.txt /usr/share/wordlists/rockyou.txt. If cracked, forge arbitrary tokens with the recovered secret.

Automated Detection#

jwt_tool (v2.2.6+) runs playbook mode covering 20+ attacks:

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

Burp Suite JWT Editor extension automatically detects jku, x5c, x5u, jwk, and kid injection points and provides one-click attack execution.

hashcat for HMAC secret recovery:

hashcat -m 16500 -a 0 captured_token.txt /usr/share/wordlists/rockyou.txt
hashcat -m 16500 -a 3 captured_token.txt ?a?a?a?a?a?a?a?a  # 8-char bruteforce

BreachVex detects JWT vulnerabilities through a multi-stage attack sequence: it discovers JWKS endpoints across standard paths, establishes a verified authentication oracle (triple-baseline: valid→200, no-token→401, garbage→401), tests all algorithm confusion variants including the 8 alg:none case permutations, probes key-source injection with out-of-band callbacks for jku/x5u SSRF, fuzzes kid with path-traversal and SQLi/CMDi payloads, and runs HMAC cracking on symmetric tokens. Every finding requires differential body validation before reporting.

Prevention#

Explicit Algorithm Allowlist#

The single most important defense is refusing to trust the JWT header's alg field:

# BAD — trusts the header's algorithm claim
import jwt
decoded = jwt.decode(token, key, algorithms=jwt.get_unverified_header(token)["alg"])
 
# GOOD — explicit server-side allowlist
ALLOWED_ALGORITHMS = ["RS256"]
decoded = jwt.decode(token, public_key, algorithms=ALLOWED_ALGORITHMS)

// BAD — jsonwebtoken trusts header algorithm
const payload = jwt.verify(token, secret)
 
// GOOD — explicit algorithm allowlist
const payload = jwt.verify(token, secret, { algorithms: ['RS256'] })
 
// BAD — Hono CVE-2026-22817 pattern
import { jwt } from 'hono/jwt'
app.use('/api/*', jwt({ secret: process.env.JWT_SECRET }))
 
// GOOD — explicit algorithm
app.use('/api/*', jwt({ secret: process.env.JWT_SECRET, alg: 'HS256' }))

Immutable Sub for Identity#

# BAD — mutable claim, vulnerable to IdP email change ATO
user = db.users.find_one({"email": decoded["email"]})
 
# GOOD — immutable sub per RFC 7519 §4.1.2
user = db.users.find_one({"oidc_sub": decoded["sub"]})

Kid Input Validation#

import re
 
# BAD — path traversal and SQLi vector
key_data = open(f"/keys/{header['kid']}").read()
 
# GOOD — strict allowlist regex + parameterized query
KID_PATTERN = re.compile(r'^[a-zA-Z0-9_-]{1,64}$')
if not KID_PATTERN.fullmatch(header.get("kid", "")):
    raise ValueError("Invalid kid claim")
row = db.execute("SELECT k FROM keys WHERE id = $1", (header["kid"],)).fetchone()

Disable Unsafe Header Parameters#

UNSAFE_HEADERS = {"jku", "x5u", "jwk", "x5c"}
 
def verify_jwt(token: str, expected_alg: str, public_key) -> dict:
    unverified_header = jwt.get_unverified_header(token)
    if UNSAFE_HEADERS & unverified_header.keys():
        raise SecurityError("Unsafe JWT header parameters present")
    if unverified_header.get("alg") != expected_alg:
        raise SecurityError("Algorithm mismatch")
    return jwt.decode(token, public_key, algorithms=[expected_alg])

Strong HMAC Secrets#

import secrets
 
# GOOD — cryptographically random 32-byte secret
JWT_SECRET = secrets.token_bytes(32)
# Node.js: crypto.randomBytes(32).toString('hex')
 
# BAD — all crackable with hashcat -m 16500 in under 60 seconds:
# "secret", "password", "jwt-secret", "12345678901234567890"

Resources#

• PortSwigger Web Security Academy — JWT Attacks
• OWASP JWT Security Cheat Sheet
• RFC 7519 — JSON Web Token
• RFC 9700 — OAuth 2.0 Security Best Current Practice