Table of contents
18
Read this in 30 seconds: CVE-2026-5430 is a JWT authentication bypass in WSO2 API Manager and three sibling products. A token signed with an algorithm the server does not support is not rejected, and attackers are already using forged admin tokens.
- Scored 10.0, and exploited. WSO2 rates CVE-2026-5430 at CVSS 10.0 (9.8 for single-tenant setups). CISA added it to its exploited list on September 24, with a federal deadline of September 27.
- The public diff shows a fail-open error path. When the algorithm is not RS256, RS384 or RS512, verification throws an error. The pre-fix code logged it and let the request carry on.
- The fix was public for five months before the first recorded attack. The fix pull request merged on April 12, under the title “Improve exception handling”. watchTowr’s honeypot caught its first forged admin token on September 13.
- Four WSO2 products are affected. API Manager on 4.1.0 to 4.6.0, plus API Control Plane, Traffic Manager and Universal Gateway on 4.5.0 and 4.6.0.
- WSO2 documents no workaround. You patch, or you shrink who can reach the gateway, and you rotate secrets if you suspect a hit.
Most authentication bugs are a missing check. This one is a check that ran, failed, and was waved through.
CVE-2026-5430 sits in the part of WSO2 that decides whether a JSON Web Token (JWT) is genuine. If the token names an algorithm the server cannot verify, the verification errors out. The old code treated that error as a note for the log, not a reason to say no.
Here is what the fix diff shows, what attackers have done with it, and how to check your own deployment today.
WSO2 API Manager is an API gateway and management platform. It sits between applications and the backend services they call, and it issues and checks the tokens that say who is allowed in.
That makes it a store of keys. Registered applications have consumer keys and secrets, and the gateway holds the routes and credentials for the backends behind it. A bypass here is not one locked door. It is the key cabinet.
Here is WSO2’s own description, from advisory WSO2-2026-5328:
“JWT authentication can be bypassed when a token is signed using an unsupported algorithm, allowing unauthorized access.”
NVD’s record adds that the mechanism “accepts tokens signed with algorithms other than those explicitly configured or supported”, which can lead to “potential compromise of administrative accounts and full account takeover.”
The affected versions, from the advisory:
| Product | Affected versions |
|---|---|
| WSO2 API Manager | 4.1.0, 4.2.0, 4.3.0, 4.4.0, 4.5.0, 4.6.0 |
| WSO2 API Control Plane | 4.5.0, 4.6.0 |
| WSO2 Traffic Manager | 4.5.0, 4.6.0 |
| WSO2 Universal Gateway | 4.5.0, 4.6.0 |
A few details that trip people up:
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) and says it drops to 9.8 for single-tenant deployments. The only difference is scope: in a single tenant, the damage stays inside one security boundary.The advisory credits the Hacktron team for reporting it.
WSO2’s fix is public, so the failure is readable. The advisory names two pull requests. The main one is carbon-apimgt #13752, merged April 12, 2026 with the title “Improve exception handling”; the other is product-apim #14167.
Two pieces of code matter.
1. The verifier only knows three algorithms. In JWTUtil.verifyTokenSignature, if the token’s header names RS256, RS384 or RS512, WSO2 verifies the signature. Anything else goes to an else branch that throws an APIManagementException with the message “Public key is not RSA”.
2. The interceptor caught that exception and moved on. Before the fix, the authentication interceptor did this on failure:
} catch (APIManagementException e) {
logger.error("Authentication Failure " + e.getMessage());
return;
}It logged the error and returned without throwing, so the interceptor did not stop the request. The fix replaces that with a thrown OAuthAuthenticationInterceptorException, so the request is refused. The second authentication path in the same file gets the same change.
Two honest limits. This is our reading of the public diff, and we have not reproduced the attack. We also do not publish token contents, because this is a live exploit.
Public reporting lines up with the diff. watchTowr’s Yordan Ganchev, quoted by The Hacker News, says the flaw exists because JWT authentication “accepts tokens signed with algorithms it does not support, then approves them anyway.”
| Date | What happened |
|---|---|
| Apr 12, 2026 | The fix pull request (carbon-apimgt #13752) merges in WSO2’s public repository |
| May 3, 2026 | WSO2 publishes advisory WSO2-2026-5328, version 1.0.0 |
| Aug 6, 2026 | The CVE record appears in NVD |
| Sep 13, 2026 | watchTowr’s honeypot records the first forged admin token |
| Sep 24, 2026 | CISA adds CVE-2026-5430 to its exploited list |
| Sep 27, 2026 | Deadline for federal civilian agencies |
Look at the gap. The CVE-2026-5430 fix, the diff and the advisory were all public for months before the first attack was recorded. We do not know how the attackers learned the bug, but nothing about it was secret.
We do not know who is behind the attacks, and no source we read names an actor or a victim. What is confirmed is a honeypot capture on September 13, and CISA’s listing on evidence of exploitation.
The gateway is where the value is. In the attempts watchTowr observed, Ganchev says the forged token is suspected to be used to reach every API backend endpoint and its credentials, plus the consumer keys and secrets for every registered application.
Consumer keys and secrets are what other systems use to prove they are your applications. Stolen, they let an attacker keep working after you patch.
Three questions decide whether CVE-2026-5430 applies to you:
Update to at least these levels (WSO2 subscription holders, from the advisory):
| Product | Version | Required update level |
|---|---|---|
| API Manager | 4.6.0 | 21 |
| API Manager | 4.5.0 | 57 |
| API Manager | 4.4.0 | 72 |
| API Manager | 4.3.0 | 108 |
| API Manager | 4.2.0 | 197 |
| API Manager | 4.1.0 | 257 |
| API Control Plane | 4.6.0 | 22 |
| API Control Plane | 4.5.0 | 58 |
| Traffic Manager | 4.6.0 | 21 |
| Traffic Manager | 4.5.0 | 56 |
| Universal Gateway | 4.6.0 | 21 |
| Universal Gateway | 4.5.0 | 57 |
Community users can apply the two public fixes or upgrade to the latest unaffected version.
Then, in this order:
Start from the code behind CVE-2026-5430. On an unpatched system, a token with a non-RSA algorithm reaches the else branch above, so it should leave error lines in the server logs: “Public key is not RSA”, and “Authentication Failure Public key is not RSA” from the old interceptor. That is our reading of the code, not a WSO2 indicator.
Search for those lines. Any hit is worth reading, even though a genuine misconfiguration can produce it too. A missing line is not proof of safety, because log settings differ.
Inception Security adds three more places to look:
alg entries in JWT headers, if your gateway or WAF logs them.Also check what changed: new applications, new keys, and any new access to backends.
This is a familiar mistake in a new place. A security check errors, the error is handled as a log line, and the request continues. The result is a system that is secure when everything works and open when anything breaks.
We saw the same shape in CVE-2026-59822 in LiteLLM, where a failed key check fell back to an empty object that counted as authenticated. Our guide to attacking OAuth and SSO covers the wider family of token bugs.
For anyone building on JWTs, the rule is short. Choose the accepted algorithms on the server, never from the token. Treat any verification error as a rejection. And test the negative cases, so you know that a token that cannot be verified is refused.
The useful test for CVE-2026-5430 is the negative one: does your gateway refuse a token it cannot verify? That question is the whole vulnerability.
We would check that on systems you own, with written scope and after confirming the patch level, because the same probe is dangerous on an unpatched gateway. We would also map which WSO2 endpoints are reachable from the internet, review what the gateway can reach, and look at the logs for the lines above. That is the kind of testing our human testers and AI agents do on API infrastructure, and your data stays on your own machine while we do it.
CVE-2026-5430 is a JWT authentication bypass in WSO2 API Manager, API Control Plane, Traffic Manager and Universal Gateway. A token signed with an unsupported algorithm is not rejected, which can give unauthorized access, including to administrator accounts.
Yes. watchTowr’s honeypot recorded a forged JWT with administrator privileges on September 13, 2026, and CISA added CVE-2026-5430 to its Known Exploited Vulnerabilities catalog on September 24.
WSO2 API Manager 4.1.0 through 4.6.0, and API Control Plane, Traffic Manager and Universal Gateway 4.5.0 and 4.6.0. The advisory lists the update level that fixes each one.
Update to the required level for your version, for example API Manager 4.6.0 update 21 or 4.5.0 update 57. WSO2 documents no workaround, and community users can apply the public fixes.
Search server logs for “Public key is not RSA” and “Authentication Failure” lines, check for admin sessions with no matching login, and review consumer key and secret activity. Missing log lines do not prove you were not hit.
CISA’s catalog title says path traversal, but the CWE it lists is CWE-347, improper verification of a cryptographic signature. WSO2’s advisory and NVD describe a JWT signature bypass, so treat it as an authentication bypass.
CVE-2026-5430 is not a clever exploit. It is a verifier that could not verify, and a caller that treated that as fine. The fix has been public since April, and the attacks started five months later.
If you run any of the listed WSO2 products, check the update level today. Then look at your logs and your keys, because patching only stops the next attacker.
Categories
Related articles
