Why Your JWT Implementation Is Likely Vulnerable to Confusion Attacks

TLDR: Researchers have identified three critical attack vectors against JSON Web Token (JWT) libraries: sign/encrypt confusion, polyglot tokens, and resource exhaustion via PBES2 iteration counts. These vulnerabilities stem from design flaws in the JOSE specification and poor library configuration rather than protocol-level weaknesses. Pentesters should audit JWT implementations for these patterns, while developers must enforce strict algorithm validation and avoid over-engineered token features.

JSON Web Tokens are everywhere. They are the industry standard for stateless authentication, yet the underlying specifications—specifically the JSON Object Signing and Encryption (JOSE) suite—are a minefield of implementation pitfalls. While JWTs are a massive improvement over legacy session identifiers, they introduce a level of complexity that most developers are not equipped to handle. The core issue is that the specification tries to be everything to everyone, leading to libraries that prioritize feature-completeness over security.

The Sign/Encrypt Confusion Attack

The most dangerous vulnerability discussed in recent research is the sign/encrypt confusion attack. This occurs when a library supports both asymmetric signing (JWS) and asymmetric encryption (JWE) using the same underlying key material. Because RSA keys can technically be used for both signing and encryption, a library that fails to enforce strict algorithm separation becomes a target.

If an application uses a library that accepts both JWS and JWE, an attacker can submit an encrypted token where a signed one is expected. If the library is configured to trust the alg header in an untrusted token, it may attempt to "decrypt" the token using the public key. Since the public key is known, the attacker can craft a payload that the library interprets as a valid, decrypted token. This effectively bypasses authentication.

To test for this, you need to identify if the target application uses the same key for signing and encryption. If you can determine the public key—often exposed via an OIDC jwks.json endpoint—you can use tools like Burp Suite's JWT Editor to swap the algorithm and attempt to forge tokens. This vulnerability has been documented in several libraries, including CVE-2022-38174 and CVE-2022-3102.

Polyglot Tokens and Library Mismatch

Polyglot tokens exploit the discrepancy in how different libraries parse the same JWT string. The JOSE specification allows for multiple serialization formats, such as the compact serialization and the flattened JSON serialization. A vulnerability arises when a validation library (Library A) parses a token using one format, while the downstream application logic (Library B) parses the same token using another.

If Library A validates the signature of a compact token but ignores extra fields, and Library B processes the same token as a JSON object, an attacker can inject malicious claims into the JSON structure that Library A never inspected. This is a classic Broken Access Control scenario. During an engagement, look for applications that pass tokens through multiple middleware layers. If those layers use different libraries or different parsing configurations, you have a high probability of finding a bypass.

Denial of Service via PBES2 Iteration Counts

The third attack targets the PBES2 (Password-Based Encryption Scheme 2) algorithm. PBES2 uses a key derivation function that relies on an iteration count to make brute-force attacks computationally expensive. The p2c header parameter defines this count.

The vulnerability is simple: an attacker can set the p2c value to the maximum integer allowed by the library, forcing the server to perform billions of hash iterations before it can even determine if the token is valid. Because this validation happens before the server checks if the token is actually signed by a trusted party, the attack is unauthenticated. Sending a small burst of these tokens can effectively pin the CPU of a backend service, leading to a complete denial of service. This was a primary concern in CVE-2022-38083.

Defensive Recommendations

Defending against these attacks requires moving away from the "everything-supported" approach. First, enforce strict algorithm whitelisting. If your application only uses RS256, your library should be configured to reject any token that does not explicitly use that algorithm. Never trust the alg header provided by the client.

Second, minimize the attack surface by disabling unused features. If you do not need JWE, disable it. If you do not need PBES2, ensure your library is configured to ignore it. Most of these vulnerabilities exist because libraries try to be helpful by supporting every obscure feature in the JOSE specification.

Finally, if you are building a new system, consider whether you actually need the complexity of JWTs. If you do not require the scalability of stateless tokens, a traditional, stateful session database is significantly easier to secure and audit. Complexity is the enemy of security, and in the world of authentication, simplicity is the best defense.