CVE-2026-5430: WSO2 API Manager JWT Bypass Lands on the KEV Catalog
CVE-2026-5430: WSO2 API Manager JWT Bypass Lands on the KEV Catalog
WSO2 is not a household name, but it quietly runs in front of some very large organisations: the vendor reports close to a thousand customers across banking, government, telecommunications and logistics in more than 90 countries, and Australian names like Telstra have appeared in coverage of its products. That makes CVE-2026-5430 worth Australian attention even though most readers will never have installed WSO2 directly — it may be embedded in a vendor platform or managed integration they depend on. An API gateway is also a singularly bad thing to lose: it holds credentials for everything behind it, which is why the detail below deserves more than a skim.
What the vulnerability is
The flaw is an authentication bypass in the JWT (JSON Web Token) handling of WSO2 API Manager, API Control Plane, Traffic Manager and Universal Gateway. A JWT carries a header that names the signing algorithm; a correct implementation rejects any token signed with an algorithm it does not support or recognise. WSO2's advisory WSO2-2026-5328, published on 3 May 2026, describes what happens here instead: "JWT authentication can be bypassed when a token is signed using an unsupported algorithm, allowing unauthorized access." An attacker crafts a token naming an algorithm the gateway will not properly verify, sets whatever claims they like — administrator privileges included — and the gateway accepts it. No signing key required.
The mechanical cause is a fail-open error path. WSO2's token verifier recognises RS256, RS384 and RS512; an algorithm outside that set raises an exception, and the pre-fix authentication interceptor caught that exception, logged it, and let the request proceed. NVD's record for the CVE classifies it as CWE-347, improper verification of a cryptographic signature, and notes the flaw "accepts tokens signed with algorithms other than those explicitly configured or supported", which can lead to full account takeover. The vendor scored it CVSS 10.0 (Critical); single-tenant deployments drop to 9.8 because the scope metric doesn't change. Affected branches run from API Manager 4.1.0 through 4.6.0, with API Control Plane, Traffic Manager and Universal Gateway affected at 4.5.0 and 4.6.0.
Exploitation and the KEV listing
This is where the timeline gets uncomfortable. WSO2 shipped fixed update levels for every supported branch in May 2026 — roughly five months before the first recorded attack. On 13 September 2026, watchTowr's global honeypot network captured forged JWT tokens arriving with administrator privileges already baked in, and the company's principal threat intelligence specialist Yordan Ganchev explained the bug bluntly: the service "accepts tokens signed with algorithms it does not support, then approves them anyway" (The Hacker News). WatchTowr's researchers reproduced the vulnerability from the vendor patch even though public technical details were thin — the CVE record itself was only published in early August. The first observed attacker even aimed the payload at the wrong WSO2 product, and the same payload worked when replayed against the correct one.
CISA added CVE-2026-5430 to the Known Exploited Vulnerabilities catalog on 24 September 2026 with a federal remediation deadline of 27 September — a three-day window, which is what agencies do when a flaw is demonstrably being used. The KEV entry carries the forensic-triage flag, meaning affected US agencies owe evidence collection, not just a patch.
Why does software with a five-month-old fix stay exposed? Two structural reasons. First, WSO2's update levels are delivered through the WSO2 Updates mechanism, which requires an active subscription — community users have to apply upstream pull requests manually or migrate, and embedded deployments are the slowest of all because they sit inside a vendor platform and move on the vendor's schedule, not yours. Second, gateways are load-bearing: teams patch them less often than web servers because a botched gateway upgrade takes the whole API estate down. The correct response to that risk is staging and rollback testing, not deferral — a forgery-prone authentication layer is not something you defer on.
One inconsistency worth flagging for Australian responders reading the catalog: the entry's human-readable description calls this a path traversal with file upload and remote code execution, but the vendor advisory, the NVD record and the CWE field (CWE-347) all describe the JWT bypass. Every research write-up of the in-the-wild activity describes the forged-token mechanism. Treat the vendor advisory as authoritative; the KEV summary text appears to be in error, but the affected products, patch levels and deadline are unaffected by that. The practical consequence matters: if you hunt for webshells based on the catalog blurb, you will find nothing, because the evidence lives in authentication logs, not on disk.
What does a forged admin token actually buy? Ganchev's assessment, reported alongside watchTowr's disclosure, is that it yields access to every API backend endpoint and its credentials, plus the consumer keys and secrets for every registered application. Because a gateway by design intercepts API traffic on its way to internal systems, he described successful exploitation as offering something close to "lateral movement-as-a-service" — the ability to tap data in transit and reach internal services directly. That's the threat model you should carry into triage: not a single compromised endpoint, but the key cabinet for the whole estate.
What Australian organisations should do
- Inventory and verify patch levels. Identify every WSO2 API Manager, Universal Gateway, Traffic Manager and API Control Plane deployment, including ones bundled inside vendor platforms. Compare each against the fixed update levels in the advisory — API Manager 4.6.0 U21, 4.5.0 U57, 4.4.0 U72, 4.3.0 U108, 4.2.0 U197, 4.1.0 U257, and equivalents for the sibling products. Below those levels means vulnerable. Community (non-subscription) users don't receive update levels and need to apply the upstream fixes or migrate.
- Save the logs before you patch. Gateway logs, authentication records and audit history are how you find out whether someone got in. Patching first destroys the evidence.
- Hunt in the right place. Review gateway and key-manager authentication logs for accepted tokens whose algorithm header differs from the configured signing algorithm — unpatched instances also log "Authentication Failure" lines for the very condition that fails open, so those lines are worth reading rather than ignoring. Look for administrative API activity with no corresponding login event, and for consumer keys or secrets read or exported right after an unusual login. This is the signature that matters — not file-system artefacts.
- Assume credential exposure if there is evidence. A forged admin token exposes every API backend endpoint and the consumer keys, secrets and backend credentials the gateway holds. If triage finds signs of access, rotate everything the gateway brokers, including token-signing keys, invalidate active sessions, and rebuild the gateway from a clean image rather than cleaning it in place.
- Restrict exposure while you patch. The advisory documents no workaround. Where feasible, limit the management and gateway ports to trusted source networks — keep the Publisher and Admin interfaces off the public internet entirely. A reverse proxy that rejects tokens with unexpected algorithm headers can block the forged-token shape before the gateway upgrade lands, though that's a compensating control, not a fix.
Australia's notification obligations would run through the OAIC if personal data is confirmed exposed, and the ACSC accepts incident reports around the clock. The five-month gap between patch availability and observed exploitation is the real lesson here: internet-facing gateway software that was "patched in May" is exactly the category attackers re-check in September. For teams building out credential-hygiene programs in the wake of listings like this, our guide to auditing leaked credential exposure is a sensible companion read.
This post is general security guidance, not legal advice.