JWT Confusion Attack

The core of the attack lies in manipulating the alg header claim. An attacker changes this value from an asymmetric algorithm like RS256 (RSA signature) to a symmetric one like HS256 (HMAC). The server, if misconfigured, then uses its own RSA public key as the HMAC secret to verify the signature. Since the attacker possesses the public key, they can forge a valid HMAC signature, creating a token the server trusts implicitly.

A more direct variant involves setting the alg header to none. The JWT specification includes this option to represent an unsecured token. Vulnerable libraries that do not explicitly reject the none algorithm will skip signature verification entirely, accepting any arbitrary payload as valid. This is a configuration flaw, not a cryptographic break, and remains a common finding in penetration tests.

Attackers can embed a malicious JSON Web Key (JWK) directly in the token's jwk header parameter. If the server is configured to dynamically fetch keys from the token itself rather than a trusted key store, it will use the attacker-supplied public key to verify the signature. The attacker signs the token with the corresponding private key they control, achieving complete authentication bypass.

This advanced attack targets systems with multiple distinct JWT verifiers. An attacker obtains a validly signed JWT from a low-security context (e.g., a logging service) and replays it against a high-security context (e.g., an admin API). If the high-security verifier trusts the same issuer and key but fails to validate the aud (audience) claim, it accepts the token, granting unauthorized privilege escalation.

A sophisticated technique where a single token is crafted to be validly interpreted by two different parsers in conflicting ways. For example, a token might be parsed as a valid JWT by an API gateway but as a different structure by the backend service. This exploits parser differentials to bypass security controls at the boundary layer while delivering a malicious payload to the core application.

While often conflated, these represent distinct attack surfaces. Algorithm confusion targets the alg header to switch between asymmetric and symmetric schemes. Key confusion exploits cross-service key reuse where a token valid for one service is accepted by another due to shared secrets.

• Algorithm Confusion: RS256 → HS256 downgrade using the public key
• Key Confusion: Token issued by Service A accepted by Service B because both share the same HMAC secret
• Hybrid Attack: Combining both vectors by confusing the algorithm and redirecting the token to a different audience
• Mitigation: Enforce explicit aud claim validation and per-service key isolation

A related attack where an adversary embeds a malicious JSON Web Key (JWK) directly in the JWT header's jwk parameter. If the server naively trusts the embedded key for signature verification without cross-referencing against a trusted key store, the attacker can sign tokens with their own private key.

• Attack Flow: Attacker generates a key pair → embeds the public key in the jwk header → signs the token with the corresponding private key → server uses the embedded key for verification
• Vulnerable Pattern: jose.verify(token) without specifying an allowed key set
• Defense: Always pass an explicit jwksUri or key whitelist to the verification function; never trust header-embedded keys

A trivial bypass where the attacker sets the alg header to none, indicating an unsecured JWT. Vulnerable libraries that fail to reject the none algorithm will skip signature verification entirely, accepting any payload as valid.

• Exploit: { "alg": "none", "typ": "JWT" } with any arbitrary payload
• Historical Impact: Affected numerous early JWT libraries including older versions of jsonwebtoken (Node.js) and pyjwt (Python)
• Modern Mitigation: Most libraries now explicitly reject none by default, but custom verification logic may still be vulnerable
• Testing: Use jwt_tool with the -X n flag to test for none algorithm acceptance

A specific vulnerability in the PHP JOSE library where the HMAC verification function accepted asymmetric keys. When verifying HS256 tokens, the library used openssl_verify() instead of hash_hmac(), allowing an attacker to sign with a private key and have it verified as an HMAC signature.

• CVE-2016-5431: PHP JOSE library used RSA verification for HMAC-signed tokens
• Impact: Complete authentication bypass for any service using the affected library
• Lesson: Cryptographic API misuse is the most common source of JWT vulnerabilities
• Prevention: Use well-maintained libraries that strictly separate algorithm implementations

Beyond algorithm attacks, token replay and audience confusion represent operational threats. A JWT captured via MITM can be replayed if no nonce or expiration is enforced. Audience confusion occurs when a token issued for Service A is accepted by Service B due to missing aud claim validation.

• Replay Defense: Implement jti (JWT ID) claims with server-side nonce tracking or short-lived tokens with exp claims
• Audience Validation: Always verify the aud claim matches the expected service identifier
• Cross-Service Risk: In microservice architectures, a compromised downstream service can leak tokens that are valid for upstream services
• Best Practice: Combine short expiration (exp), unique identifiers (jti), and strict audience (aud) validation