Notifications
Clear all
Topic starter
06/06/2026 11:05 am
TL;DR: JWT algorithm confusion lets attackers forge valid tokens by abusing token-supplied metadata, including RS256 to HS256 swaps, unsafe none handling, and key URL injection, according to WorkOS. The core lesson is that verification logic must own the algorithm choice, not the token, or authentication collapses.
NHIMG editorial — based on content published by WorkOS: JWT algorithm confusion attacks: how they work and how to prevent them
By the numbers:
- The Node.js jsonwebtoken library was vulnerable prior to version 4.2.2, making the RS256 to HS256 attack trivial.
- The article notes that algorithm confusion vulnerabilities have been documented since 2015.
Questions worth separating out
Q: How should security teams prevent JWT algorithm confusion in verification code?
A: Security teams should hardcode the accepted algorithm in the verifier, reject any token that claims a different one, and ensure the key type matches the algorithm family.
Q: Why do JWT algorithm confusion attacks bypass normal authentication controls?
A: They work because the verifier trusts attacker-controlled header metadata to select the signature check.
Q: What do security teams get wrong about JWT header fields like jku and x5u?
A: Teams often treat them as harmless hints, but they can become a remote trust injection path if the verifier fetches keys from attacker-controlled URLs.
Practitioner guidance
- Pin the accepted JWT algorithm in code Configure each verifier to accept only the one algorithm it is supposed to process, and reject tokens that present any other value in the alg header.
- Reject token-supplied key locations Ignore jku, x5u, and jwk unless your application validates them against a strict allowlist and a locally controlled trust boundary.
- Enforce key type and algorithm agreement Check that symmetric algorithms use raw secret material and asymmetric algorithms use the correct public key object before verification begins.
What's in the full article
WorkOS's full article covers the operational detail this post intentionally leaves for the source:
- Step-by-step code examples for pinning algorithms in Node.js and Python JWT libraries.
- Defensive patterns for rejecting jku, x5u, jwk, and crit header fields in production.
- Library-specific notes on older jsonwebtoken and PyJWT versions that still appear in dependency trees.
- Guidance on choosing between RSA, EC, and HMAC verification paths without creating confusion risk.
👉 Read WorkOS's breakdown of JWT algorithm confusion attacks and fixes →
JWT algorithm confusion attacks: are your verification controls safe?
Explore further
06/06/2026 11:40 am
Header-driven verification is an identity trust failure, not just a cryptography bug. The problem begins when a verifier lets token metadata decide the signature path. That breaks the core IAM assumption that the application, not the claimant, controls proof validation. In NHI terms, the token becomes both the identity assertion and the policy input, which collapses the separation between presentation and verification. Practitioners should treat algorithm trust as part of authentication governance, not as an implementation detail.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, the protocol's first year of widespread adoption, according to the State of Secrets Sprawl 2026.
- 28.65 million new hardcoded secrets were detected in public GitHub commits in 2025 alone, a 34% year-over-year increase and the largest single-year jump ever recorded.
A question worth separating out:
Q: Which controls matter most when validating JWTs in SSO and API systems?
A: The most important controls are explicit algorithm pinning, strict header allowlisting, trusted key resolution, and version management for JWT libraries. Those controls stop both algorithm confusion and key redirection, which are the two main ways forged tokens become believable identities.
👉 Read our full editorial: JWT algorithm confusion attacks expose authentication bypass risk
