WSO2 CVE-2026-5430: the CVSS 10 JWT Bypass Forging Admin Tokens in the Wild

On September 24, 2026, CISA added CVE-2026-5430 to its Known Exploited Vulnerabilities catalog and gave U.S. federal agencies three days to fix it. The vulnerability is a JWT authentication bypass in WSO2 API Manager and the gateways built on it, scored CVSS 10.0. The uncomfortable part is the calendar: WSO2 shipped the fix on May 3, 2026. The catalog entry and the working exploit arrived nearly five months later, which means the window between "patched" and "weaponized" was almost half a year — and most of the people who owned an affected gateway spent that window doing nothing, because nothing told them to.

At a glance

CVE	CVE-2026-5430
Product / affected versions	WSO2 API Manager 4.1.0–4.6.0; API Control Plane 4.5.0–4.6.0; Traffic Manager 4.5.0–4.6.0; Universal Gateway 4.5.0–4.6.0
Fixed in	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; API Control Plane 4.6.0 U22 · 4.5.0 U58; Traffic Manager 4.6.0 U21 · 4.5.0 U56; Universal Gateway 4.6.0 U21 · 4.5.0 U57 (advisory WSO2-2026-5328, 2026-05-03)
CVSS	10.0 Critical (CVSS 3.1, WSO2/CNA; AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H); 9.8 for single-tenant deployments (S:U)
Exploited in the wild	Yes — watchTowr honeypots captured forged admin JWTs from 2026-09-13 (reported via The Hacker News)
CISA KEV	Added 2026-09-24; federal due date 2026-09-27 (BOD 26-04, forensic triage required)
Public PoC	None public as of 2026-09-25; researchers reproduced it without published technical details (The Hacker News)
Official advisory	WSO2-2026-5328

What CVE-2026-5430 actually is

WSO2 API Manager sits in front of enterprise APIs as the thing that decides who is allowed to call them. It authenticates callers with signed JSON Web Tokens: the caller presents a JWT, the gateway checks the signature against the configured algorithm and key, and only then does the request reach the backend. The whole security model rests on that one check being strict.

It is not. Per the WSO2 advisory, the token validator fails to enforce the configured signing algorithm. When it receives a JWT signed with an algorithm it does not support, instead of rejecting the token it accepts it. An attacker never needs the signing key. They craft a token whose header names an algorithm the validator will not properly verify, set the claims they want — sub: admin, the full API-management scope — and send it. The gateway treats the forged token as a valid administrative session.

This is CWE-347, improper verification of a cryptographic signature: the same failure family as the alg=none bug that has bitten JWT libraries for a decade. The signature is the security control, and the code path that is supposed to reject a bad one lets it through.

What the bypass hands over is not a toehold. When watchTowr replayed the payload against the correct product, authentication fell open to API backend destinations, stored credentials, and the consumer keys and secrets of every registered application. On a multi-tenant deployment the scope crosses tenants, which is why the CVSS vector carries S:C (scope changed) and lands at a flat 10.0; a single-tenant install is scored 9.8. Either way, an unauthenticated attacker becomes the administrator of the box that authenticates everyone else.

The catalog says "path traversal." CVE-2026-5430 is a JWT bypass

Here is the trap that will cost teams their first hunt. CISA's KEV entry names this "WSO2 Multiple Products Path Traversal Vulnerability" and describes it as a path traversal that allows "unrestricted file upload and lead to remote code execution." The vendor advisory, the NVD record, the CWE classification, and the tokens actually caught in the wild all say something different: a JWT authentication bypass. There is no file upload in this bug.

The distinction is not pedantic — it changes where you look.

"We captured forged JWT tokens targeting the flaw on September 13 and reproduced the vulnerability ourselves, despite the lack of public technical details."

A responder who trusts the one-line catalog description will grep the filesystem for freshly written JSPs, diff the webapps directory, and hunt for a dropped web shell. They will find nothing, conclude they were not hit, and move on. The real evidence lives in a different place entirely: authentication logs, admin API access records, and JWTs whose alg header does not match what the gateway is configured to accept. If your detection content was written from the KEV blurb, it is looking for the wrong artifact.

A patch that shipped in May, weaponized in September

The Hacker News reported that watchTowr's honeypot network first captured forged admin JWTs on September 13, 2026 — four months after WSO2 published update levels for every supported branch. The tokens arrived pre-built with administrative claims, which means the attacker understood the bug well enough to weaponize it before any technical write-up was public. CISA listed it eleven days later.

This is the shape of most real-world compromise in 2026: not a zero-day, but a known, fixed vulnerability that nobody applied because no clock was ticking until it was too late. The JWT signature-validation class is especially prone to it. In our own AI Gym knowledge base — an internal Zero Hunt observation, not an industry statistic — the same defect recurs across ecosystem after ecosystem: alg=none acceptance, HMAC-versus-RSA algorithm confusion, and validators that fall open on an unrecognized algorithm show up in JWT libraries and identity proxies year after year. WSO2 is the latest name on a list that keeps growing because the fix is a one-line strictness change and the consequence is total.

The lesson is not "patch faster." It is that a version string on a dashboard tells you a build number, not whether the gateway in production is reachable, exploitable, or already breached. Those are different questions, and only one of them is answered by apt list --installed.

Remediation

1. Am I affected?

Check the product and update level of every WSO2 gateway, including staging and forgotten internal instances. Affected products are API Manager 4.1.0–4.6.0, API Control Plane 4.5.0–4.6.0, Traffic Manager 4.5.0–4.6.0, and Universal Gateway 4.5.0–4.6.0. From the product home, confirm the running update level:

# WSO2 records the applied update level in the update config
cat $CARBON_HOME/updates/product.txt 2>/dev/null
cat $CARBON_HOME/wso2/lib/product.txt 2>/dev/null
# and the WUM/wso2update client will report it
$CARBON_HOME/bin/wso2update_linux --version

Any internet-exposed management or gateway port (default 9443 for the management console and Publisher/DevPortal, 8243/8280 for the API traffic ports) on an unpatched build should be treated as exposed to an unauthenticated attacker.

2. Patch — exact fixed update levels

Apply the update level for your branch verbatim from WSO2-2026-5328:

Product	Branch → fixed update level
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
API Control Plane	4.6.0 → U22 · 4.5.0 → U58
Traffic Manager	4.6.0 → U21 · 4.5.0 → U56
Universal Gateway	4.6.0 → U21 · 4.5.0 → U57

3. Can't patch now? — compensating controls

• Take the management console off the internet. Port 9443 and the Publisher/DevPortal have no business facing the public. Bind them to a management network or an allow-list.
• Validate the JWT algorithm at the edge. Put a reverse proxy or WAF in front of the gateway that rejects tokens whose alg header is anything other than the exact algorithm you issue (typically RS256), and rejects alg=none and unrecognized values outright. This blocks the forged-token shape without waiting on the WSO2 update.
• Rate-limit and alert on the management API so a burst of admin-scoped calls from a new source is not silent.

4. Hunt for compromise — signals and ATT&CK mapping

Because the attack is authentication abuse, not file drop, hunt the auth surface:

• Anomalous JWTs — any accepted token whose alg header is not your configured algorithm, or that carries alg=none. This is the single highest-fidelity signal. (ATT&CK T1550.001 – Application Access Token.)
• Admin sessions with no login — administrative API calls or console actions with no preceding authentication event for that principal. (T1078 – Valid Accounts.)
• Initial access on the gateway — requests to the management/token endpoints from never-seen ASNs immediately followed by privileged actions. (T1190 – Exploit Public-Facing Application.)
• Post-access theft — bulk reads of application consumer keys/secrets and backend credentials, and outbound connections from the gateway to destinations it never normally reaches.

5. Eradicate and verify

Patching closes the door; it does not undo what walked through it. If you find evidence of access — or cannot rule it out, which the mandatory forensic-triage flag on this KEV entry says you must be able to do — assume the gateway's brokered secrets are burned:

• Rotate everything the gateway held: application consumer keys and secrets, backend service credentials, and the token-signing keys themselves. A stolen signing key means the attacker can mint valid tokens even after you patch.
• Invalidate active sessions and issued tokens so forged and replayed sessions die.
• Preserve authentication logs and a system snapshot before you rebuild — the entry's forensicTriage: Yes flag under BOD 26-04 exists precisely because a rooted appliance can rewrite its own records.
• Re-verify after patching with the same forged-token payload shape against the specific build you now run — a fixed version number is not proof the fix landed in your configuration.

Where Zero Hunt fits

Every step in that eradication list is a decision — what to rotate, in what order, whether the fix actually held — and it is exactly the work Zero Hunt's AI Remediation Advisor is built to carry. The advisor ranks the finding by real exploitability, not raw CVSS: a KEV listing with observed forged-token traffic outranks a quiet 9.8, so a WSO2 gateway on your perimeter moves to the top of the queue. It then produces the specific plan — the exact update level for your branch, the algorithm allow-list to drop at the edge while you schedule the change, and the full rotation of consumer keys, backend credentials, and signing keys that a JWT-bypass compromise demands — with rollback notes, and it re-verifies the fix with the same proof that would have demonstrated the issue.

That proof is the other half. As an autonomous AI red team running on-premise on its own models, with a human in the loop for every action that matters, Zero Hunt does not read a version string and call the gateway safe. Its 10-agent swarm writes a per-target exploit with a local model — no public PoC required, which matters for a bug weaponized before any write-up existed — and answers the question the dashboard cannot: is this gateway reachable from an attacker's position, does the forged-token bypass land on your build, and, after you patch, did the fix actually hold? Every step is backtested in the AI Gym before it touches production and signed at write time into a hash-chained evidence trail. And because a rooted API gateway owns its own logs, the traffic-analysis model watching the wire — reading the anomalous admin-scoped token abuse and the outbound credential theft while they happen — is the one honest witness left when the box itself has been told to lie. Coverage maps continuously against the frameworks that make this an incident to declare, wherever you operate.

CVE-2026-5430 was fixable in May. The organizations that get hurt by it in October will not be the ones that lacked a patch. They will be the ones who never had a way to know the patch was needed, applied, and holding.