Problem Framing

JSON Web Tokens (JWTs) have become a ubiquitous mechanism for securely transmitting information between parties, particularly in authentication and authorization contexts within modern web applications and APIs. Their stateless nature, compact representation, and self-contained claims make them attractive for distributed systems and microservices architectures. However, this prevalence also means that misconfigurations and implementation flaws in JWT handling can lead to significant security vulnerabilities, ranging from privilege escalation to complete authentication bypass.

Core Mechanics

A JWT is composed of three parts, separated by dots (.): a Header, a Payload, and a Signature. Each part is typically Base64URL-encoded.

• Header: Contains metadata about the token, primarily the signing algorithm (alg) and token type (typ) ^[1][2]. The alg field specifies the cryptographic algorithm used for signing.
• Payload: Contains the claims, which are statements about an entity (typically the user) and additional data. Claims can be registered (e.g., iss, sub, exp), public, or private ^[1][2]. Sensitive data should never be stored here due to its base64-encoded, readable nature ^[1][3].
• Signature: Created by signing the encoded header and payload using the algorithm specified in the header and a secret or private key ^[1][2]. This signature is crucial for verifying the token's integrity and authenticity, ensuring it hasn't been tampered with.

The common format is HEADER.PAYLOAD.SIGNATURE.

Notable Techniques and Vulnerabilities

Numerous vulnerabilities stem from incorrect implementation or misuse of JWTs. These can be broadly categorized:

Signature Verification Flaws

The most fundamental security guarantee of a JWT is its signature. Weaknesses here allow attackers to tamper with the token's contents.

• Failure to Verify Signature: Some libraries offer separate decode() (no verification) and verify() functions. Developers might mistakenly use decode(), skipping signature validation entirely ^[2][4][5]. This allows any token with a valid format to be accepted, regardless of its origin or integrity.
• The "None" Algorithm: The JWT standard supports an "none" algorithm, indicating an unsigned token ^[2][6]. If a server accepts this algorithm and does not properly reject unsigned tokens, attackers can remove the signature and modify the payload, bypassing verification ^{[7][8][9][4][10][6][11][5][12][13]}. Case insensitivity of the "none" algorithm is also a common bypass vector ^[14].
• Signature Stripping/Null Signature: Even when the alg header specifies a cryptographic algorithm, some implementations may fail to verify the signature if it's absent or invalid, especially if the alg is explicitly set to "none" or similar, or if the library incorrectly handles an empty signature as a valid state ^{[8][6][15][12][13]}.
• Weak HMAC Secrets: For symmetric algorithms like HS256, the security relies entirely on the secrecy and strength of the shared secret key. If the key is short, guessable, hardcoded, or leaked, attackers can perform offline brute-force or dictionary attacks to recover it and forge valid tokens ^{[7][4][16][17][5][18][19][13]}. The RFC mandates keys to be at least as large as the hash output, but weak keys remain a problem ^[16][18].
• Algorithm Confusion (Key Confusion): This is a critical class of vulnerability where the server trusts the alg parameter in the JWT header to dictate the verification algorithm. An attacker can change the alg value (e.g., from RS256 to HS256) and then sign the token using the server's public key as the HMAC secret ^{[20][2][8][21][22][23][24][25][4][26][27][14][28][12][29][13]}. Since the public key is often discoverable (e.g., via JWKS endpoints), the attacker can craft a validly signed token without needing the private key. Libraries that don't explicitly pin the algorithm or validate key type against the algorithm are vulnerable ^{[30][20][31][22][25][32][27][33][28][12][29]}.
• Psychic Signatures (CVE-2022-21449): A vulnerability in Java's cryptographic libraries allowed signature verification bypass for ES256/RS256 algorithms by manipulating the key and signature structure, essentially allowing arbitrary data to be signed ^[5][34][13].

Header Parameter Exploitation

JWT headers contain metadata that can be manipulated if not properly validated.

• kid Header Injection: The kid (Key ID) parameter specifies which key to use for verification. If not properly validated, attackers can use path traversal (../) to point to sensitive files on the server's filesystem as keys ^{[35][36][15][37][34]}, or use it in SQL injection attacks if keys are fetched from a database ^[38][15]. This can lead to reading arbitrary files or executing commands.
• jku/x5u Header Injection: The jku (JWK Set URL) and x5u (X.509 URL) parameters specify URLs from which to fetch public keys. If these are not validated against a strict allowlist, an attacker can host their own JWK Set containing their public key at a controlled URL, and inject this URL into the jku or x5u header. The server then fetches and uses the attacker's public key to verify a forged token ^{[39][40][41][42][43][44][34][13]}.
• jwk Header Injection: Attackers can embed the public key directly within the jwk header parameter of the JWT itself. If the library trusts this embedded key for signature verification, the attacker can sign the token with their private key and embed the corresponding public key, bypassing verification ^[45][43][34].

Claim Validation Flaws

JWTs contain claims that represent statements about the entity. Incorrect validation of these claims can lead to vulnerabilities.

• exp (Expiration) and nbf (Not Before) Claims: JWTs should have expiration times set. Failure to validate these claims can lead to expired tokens remaining valid, allowing replay attacks ^{[46][47][48][5]}.
• iss (Issuer) and aud (Audience) Claims: Tokens should be validated to ensure they were issued by a trusted party (iss) and are intended for the correct recipient (aud) ^{[46][49][48][3][40][50][51]}. Loose validation, such as partial string matching on the issuer ^[52] or ambiguities in audience claim interpretation ^[53], can lead to accepting tokens from unintended sources or cross-service relay attacks ^[8][53][14].
• Sensitive Data Exposure: Storing sensitive information (PII, credentials, etc.) directly in the payload is a significant risk, as JWTs are typically only signed, not encrypted ^{[1][49][3][14][54]}. Anyone with access to the token can read this data.

Cryptographic Key Management Issues

The security of JWTs hinges on the proper management of cryptographic keys.

• Weak Key Generation/Storage: Hardcoding secrets, using predictable secrets (e.g., "password123"), or storing keys insecurely makes them vulnerable to compromise ^[1][48][53].
• Key Confusion: As mentioned under Algorithm Confusion, using the same key for different algorithms or mistakenly treating an RSA public key as an HMAC secret is a critical flaw ^{[45][31][8][21][22][25][32][27][14][28][12][29][13]}.
• Key Leakage: Public keys, if exposed, are intended to be public. However, if private keys or symmetric secrets are leaked (e.g., via code repositories, insecure storage), attackers can forge tokens ^{[7][48][53][4][55][56][17][43][13]}.

Library Vulnerabilities

Many popular JWT libraries have historically contained vulnerabilities that, if not patched, expose applications.

• PyJWT: Vulnerabilities include improper validation of the crit (Critical) header parameter ^[57], weak encryption key length enforcement ^[58], and incorrect issuer (iss) validation allowing partial string matches ^[52].
• jsonwebtoken (Node.js): Notable vulnerabilities include an algorithm confusion flaw ^{[1][59][28][29]} and historically issues related to RCE if secrets are controlled ^[60].
• Authlib (Python): CVE-2026-27962 details a critical JWK Header Injection vulnerability allowing JWT forgery ^[45].
• fast-jwt: An incomplete fix for CVE-2023-48223 allowed algorithm confusion attacks via whitespace bypasses in the public key matcher ^[30]. Another vulnerability, CVE-2025-30144, involved issuer validation flaws ^[53].
• pac4j-jwt: CVE-2026-29000 is a critical authentication bypass in handling encrypted JWTs where an unsigned inner JWT can be wrapped in a valid JWE, bypassing signature verification ^[61][62][63].
• HarbourJwt: CVE-2026-23993 allowed bypasses via unrecognized algorithm values due to returning empty signatures ^[64][22].
• python-jose: CVE-2024-33663 involves algorithm confusion when handling OpenSSH ECDSA keys ^[65][32].
• golang-jwt: A vulnerability existed in VerifyAudience where an empty string could lead to successful validation ^[66].
• PAN-OS (GlobalProtect): CVE-2026-0265 is a JWT signature bypass in PAN-OS when Cloud Authentication Service (CAS) is attached to an authentication profile ^[67].

JWE Specific Vulnerabilities

JSON Web Encryption (JWE) adds another layer of complexity and potential vulnerabilities.

• Improper Verification of Inner Signature: When a JWE wraps a signed JWT (JWS), some implementations might decrypt the JWE but fail to verify the signature of the inner JWS, allowing an unsigned inner token with manipulated claims ^[61][62][63].

Detection and Prevention

Securing JWT implementations requires a multi-faceted approach focusing on robust validation, secure key management, and adherence to best practices.

Key Validation and Management

• Algorithm Pinning: Always explicitly specify the expected signing algorithm (e.g., RS256) in your JWT verification function. Never allow the token's alg header to dictate the verification algorithm ^{[49][31][22][25][14][68][28][29]}. Reject tokens with unknown or disallowed algorithms, especially "none".
• Key Type Enforcement: Validate that the key type matches the expected algorithm. For example, an RSA public key should not be used as an HMAC secret ^{[31][25][32][14][29]}.
• Strong Key Generation: Use cryptographically secure random values for secrets, with sufficient entropy and length (e.g., 256 bits for HMAC, 2048 bits for RSA) ^[58][48][16].
• Key Rotation: Implement a strategy for regular key rotation to limit the impact of a compromised key ^[48].
• Secure Key Storage: Never hardcode secrets. Use secure environment variables or dedicated key management systems. Keep private keys strictly separate from public keys ^{[1][48][53][56]}.
• JWKS Endpoint Validation: If fetching keys from JWKS endpoints specified via jku or x5u headers, strictly validate the URLs against an allowlist. Disabling redirects is also recommended ^{[39][41][42][43][44][34][13]}. The most secure approach is often to ignore these headers and use locally configured JWKS endpoints.
• kid Parameter Validation: Treat the kid parameter cautiously. Use it to map to keys in a secure, controlled manner (e.g., an allowlist lookup), not as a direct input for file paths or database queries that could be vulnerable to injection ^{[36][38][43][15][44][34]}.

Token Validation

• Comprehensive Verification: Always validate the token's signature, issuer (iss), audience (aud), expiration (exp), and not-before (nbf) claims ^{[46][47][48][14][5]}.
• Issuer and Audience Validation: Ensure iss and aud claims are validated precisely against expected values to prevent cross-service relay attacks or tokens being accepted by unintended recipients ^{[52][53][40][68][50]}.
• Expiration and Lifetime: Set short expiration times for access tokens (e.g., 15-60 minutes) and consider refresh tokens for session continuity ^{[46][47][48][56]}. Ensure the application properly enforces expiration claims.
• Token Revocation: For scenarios requiring immediate revocation, short-lived tokens or a token blocklist/revocation list mechanism is necessary, as JWTs are inherently stateless and cannot be invalidated before expiry ^[47][48][54].
• Input Validation: Sanitize and validate JWTs for basic structural integrity and size before processing to prevent denial-of-service attacks ^[53].

Secure Transmission and Storage

• HTTPS Enforcement: Always transmit JWTs over HTTPS to protect them in transit ^[46][3][56].
• Secure Storage: Store JWTs securely on the client side. HTTP-Only and Secure cookies are recommended for web applications to mitigate XSS risks ^{[46][48][3][69][50][54][70]}. Avoid localStorage or sessionStorage if possible, as they are vulnerable to XSS ^[46][54][70].
• CSRF Protection: When using cookies, implement CSRF protection (e.g., SameSite=Strict) ^{[46][48][3][69][50][54]}.
• Avoid Token in URLs: Never include JWTs in URL parameters, as they can be logged by servers, proxies, or leaked via referrer headers ^[3]. Use the Authorization: Bearer header or secure POST bodies.

Secure Coding Practices

• Use Up-to-Date Libraries: Keep JWT libraries updated to the latest patched versions to benefit from fixes for known vulnerabilities ^{[46][1][57][45][30][61][52][65][48][63][25][32][60][66][28][71][34]}.
• Avoid Sensitive Data in Payload: Never include sensitive information (passwords, PII, confidential data) in the JWT payload ^{[1][49][3][14][54]}.
• Logging and Monitoring: Implement comprehensive logging for JWT validation events (successes and failures) to detect anomalies and potential attacks ^[1][58][48].

Detection and Prevention Tools

Several tools can assist in identifying JWT vulnerabilities:

• Snyk: Scans dependencies for vulnerable JWT libraries and insecure implementation patterns ^{[46][1][56][72]}.
• jwt_tool: A Python toolkit for validating, forging, scanning, and tampering with JWTs, supporting numerous attacks ^{[73][74][19][71]}.
• jwt-hack: A high-performance toolkit for testing, analyzing, and attacking JWTs ^[75].
• jwt-pwn: A tool for cracking JWT secrets and exploiting vulnerabilities ^[76].
• c-jwt-cracker: A C-based JWT brute-force cracker ^[18].
• JWTAuditor: A client-side JWT security testing platform for analysis, bruteforcing, editing, and exploitation ^[77].
• jwt-editor (Burp Extension): A Burp Suite extension for editing, signing, verifying, and exploiting JWTs ^{[78][79][37][34]}.
• JOSEPH (Burp Extension): A Burp Suite extension for testing JOSE implementations, including JWTs ^[79][34].
• jwt-scanner (Burp Extension): Another Burp Suite extension for scanning JWTs ^[37].
• CookieMonster: A Go-based tool for detecting issues in stateless authentication cookies, including JWTs ^[80].
• OWASP JWT Cheat Sheet: Provides guidance on best practices and common vulnerabilities ^[5][50].
• PortSwigger Web Security Academy: Offers labs and detailed explanations for various JWT attacks ^[29][13][5].

Recent Developments

The JWT landscape is continuously evolving, with new vulnerabilities and best practices emerging. Recent focus areas include:

• Increased Scrutiny on Libraries: The discovery of numerous CVEs in popular JWT libraries (e.g., PyJWT, jsonwebtoken, pac4j-jwt) highlights the ongoing need for vigilance and prompt patching ^{[57][45][30][61][52][65][62][63][32][60][66][28]}.
• Algorithm Confusion Variants: New instances of algorithm confusion attacks continue to be discovered, emphasizing the critical need for explicit algorithm pinning and key type validation ^{[30][20][31][22][25][27][33][28][29]}.
• JWK/JKU/X5U Header Exploitation: Vulnerabilities related to improperly validated header parameters for key retrieval remain a significant concern ^{[39][41][36][38][42][43][15][44][34][13]}.
• JWE and Nested JWT Issues: The complexity of encrypted JWTs (JWEs) and handling of nested tokens present unique attack vectors, particularly concerning inner signature verification ^{[61][62][63][81]}.
• Refined BCPs: Standards bodies like the IETF continue to update Best Current Practices (BCPs) for JWTs to address newly discovered threats and improve secure implementation guidance ^[49][82][68].
• AI in Security Testing: AI is increasingly being used for static analysis and vulnerability detection in JWT libraries and implementations ^[64][77].

Where to Go Deeper

• RFC 7519: JSON Web Token (JWT): The foundational specification for JWTs.
• RFC 7515: JSON Web Signature (JWS): Defines the signature mechanisms.
• RFC 7516: JSON Web Encryption (JWE): Defines the encryption mechanisms.
• RFC 7518: JSON Web Algorithms (JWA): Specifies the algorithms used with JWS and JWE.
• RFC 8725: JSON Web Token Best Current Practices: Provides comprehensive security recommendations and threat analysis ^[49][82][68].
• OWASP JWT Cheat Sheet: A practical guide to JWT vulnerabilities and secure implementation ^[5][50].
• PortSwigger Web Security Academy: Offers hands-on labs for various JWT attacks ^[29][13].
• jwt_tool: An essential toolkit for testing JWT security ^{[73][74][19][71]}.
• jwt.io: A popular online JWT encoder/decoder and validator.
• PentesterLab: Provides numerous labs focusing on JWT vulnerabilities and exploitation techniques ^{[64][35][21][26][83][42][33][29][13]}.