How JWT Algorithm Confusion Lets a Forged Token Pass Signature Checks

A JSON Web Token is only as trustworthy as the code that checks its signature, and that code has one job that is easy to get subtly wrong: deciding which algorithm to verify with. When the verifier lets the token itself answer that question, or fails to reject an answer it does not understand, an attacker can hand it a token they wrote themselves and have it accepted as genuine. That is the class of bug behind CVE-2026-5430, the WSO2 API Manager authentication bypassAuthentication Bypass📖A security vulnerability that allows an attacker to circumvent the login verification process and gain unauthorized access to a system without providing valid credentials. that CISA added to its Known Exploited Vulnerabilities catalog in September 2026 after watchTowr caught forged administrator tokens landing on its honeypots. This explainer covers how signature verification is supposed to work, the ways the algorithm decision breaks, and what a correct verifier looks like.

What a JWT Signature Actually Proves

A JWT has three parts: a header, a payload of claims, and a signature. The header states the algorithm used to sign, conventionally in a field named alg. The payload carries identity and authorization claims such as the subject, the issuer, the expiry, and often roles or scopes. The signature is computed over the encoded header and payload using either a shared secret (the HMAC family) or a private key (the RSA and elliptic-curve families).

The relying party, in this case an API gatewayAPI Gateway🛡️A reverse proxy that sits in front of backend services, authenticating clients, enforcing rate limits and policy, and routing requests. Because it registers every client and stores every backend definition, an administrator on the gateway can reach credentials for everything it fronts., verifies the signature using the corresponding secret or public key. If the check passes, it trusts every claim in the payload. That is the whole security model. The claims are not encrypted and are not secret; anyone can decode them. The only thing standing between an attacker and an administrator identity is the verifier's insistence that the signature over those claims was produced by a party holding the right key.

So the verifier's correctness reduces to two questions. Which key should be used, and which algorithm should be used with it? Both answers must come from the verifier's own configuration, never from the token.

Where the Algorithm Decision Goes Wrong

The header's alg field is there for interoperability, and it is a trap when the verifier treats it as an instruction rather than a claim to be checked. There are three well-documented failure shapes.

**The null algorithm.** The JWT specification defines an algorithm value meaning "unsecured," with an empty signature. Libraries that honor it as a valid choice will accept any token whose header names it, because there is nothing to verify. Modern libraries reject it by default, but wrappers and older code paths still surface it.

**Key confusion between families.** If a verifier holds an RSA public key and the attacker submits a token whose header names an HMAC algorithm, a verifier that dispatches on the header may compute an HMAC using the public key bytes as the shared secret. Public keys are public. The attacker can compute the same HMAC and produce a token that passes.

**Unsupported or unrecognized algorithms.** This is the shape WSO2 described. The vendor advisory says the bypass occurs when a token is signed using an unsupported algorithm. The merged fix in the carbon-apimgt library adds an explicit invalid-token error when the verifier meets an unsupported RSA algorithm and changes the surrounding OAuthOAuth🛡️An open standard authorization protocol that allows applications to access user resources without exposing passwords, using tokens instead of credentials. interceptor so that error propagates instead of being swallowed. Read together, those two changes describe a verifier that did not fail closed. When it hit an algorithm it could not process, the path did not end in a hard rejection, and the caller upstream did not learn that verification had not really happened. The result is functionally the same as the null-algorithm case: a token the attacker signed with nothing meaningful is treated as verified.

That last shape is the most insidious because it is often not a library bug at all. The library may raise an exception correctly, and application code around it catches broadly, logs, and continues. Exception handling that is too generous converts "verification failed" into "verification did not occur," and the difference is invisible to the code that reads the claims afterward.

Why Admin Is One Field Away

Once the signature check is neutralized, the attacker controls the payload. In an API management platform, the claims typically carry the username or subject, the tenant, and the roles or scopes the token grants. The forged tokens watchTowr observed carried administrator privileges. That makes sense: there is no reason to forge a low-privilege token when the same effort yields the highest one.

The impact follows from what an administrator on an API gateway can reach. WSO2's advisory frames it as unauthorized access up to and including compromise of administrative accounts. watchTowr's read of the attacker's intent is more concrete: every backend endpoint the gateway fronts, plus the consumer keys and secrets of every registered application. The gateway is a chokepoint by design, and a forged admin token turns the chokepoint into a vantage point. The strategic consequences are the subject of Why an API Management PlaneManagement Plane🌐The interfaces and services used to configure and administer a device, as distinct from the data plane that carries user traffic. On a remote-access appliance the management plane is the admin console; exposing it to the internet or to the user-facing portal is a common root cause of privileged compromise. Is a Credential Vault for Every Backend It Fronts.

What a Correct Verifier Looks Like

The defensive pattern is short and unforgiving.

• **Pin the algorithm in configuration.** The verifier should be told, at deployment time, exactly which algorithm and which key to use. The header's alg field is compared against that expectation and the token is rejected on mismatch. It is never used to select a code path.
• **Fail closed on anything unexpected.** Unsupported, unrecognized, missing, or malformed algorithm values all produce the same outcome: rejection, with a log line. There is no fallthrough branch.
• **Separate verification from parsing.** Decode nothing you have not verified. If the code reads claims before the signature check completes, a bug in the check ordering becomes an authentication bypass.
• **Make exception handling narrow.** Catch only the exceptions you can meaningfully handle, and never let a failure inside the verifier resolve to a success return value. The WSO2 fix is largely this change.
• **Validate the rest of the token too.** Issuer, audience, expiry, and not-before claims should be enforced. They do not stop a signature bypass, but they narrow what a forged token can do if one slips through.
• **Prefer asymmetric keys with a key identifier.** Rotating a public key set through a key ID field lets you retire a key without redeploying, and it removes any chance of a shared secret being confused with a public key.

Testing Your Own Verifiers

If you run anything that accepts JWTs, three cheap tests catch most of this class. Submit a token with the unsecured algorithm and an empty signature. Submit a token whose header names an algorithm your deployment never uses, signed with garbage. Submit a token whose header names an HMAC algorithm, signed with your own RSA public key as the secret. All three must be rejected, and the rejection should be logged in a way your detection team can see. How to Hunt for Forged Admin Tokens in API Gateway Logs describes what those logs should contain and how to query them after the fact.

The WSO2 case is a reminder that the vulnerabilityVulnerability🛡️A weakness in software, hardware, or processes that can be exploited by attackers to gain unauthorized access or cause harm. is rarely in the cryptography. HMAC and RSA are fine. The bug lives in the glue: the dispatch on an untrusted header, the missing rejection branch, the catch block that turned a failure into silence. Those are code review findings, and they are worth a dedicated pass on every service that terminates authentication for something important.