WSO2 JWT Bypass CVE-2026-5430 Now Under Active Exploitation

Attackers are actively forging JSON Web Tokens to bypass authentication in WSO2 API Manager and three related products, exploiting CVE-2026-5430, a critical flaw that WSO2 patched five months ago but that only came under real-world attack starting September 13, 2026. The bug lets a JWT signed with an algorithm the gateway does not know how to verify sail through as if it were legitimately signed, and the forged tokens researchers are now seeing carry administrator privileges baked in.

How does the JWT bypass actually work?

WSO2's own advisory, WSO2-2026-5328, describes the root cause in one line: "JWT authentication can be bypassed when a token is signed using an unsupported algorithm, allowing unauthorized access." WSO2 classifies it as improper verification of a cryptographic signature. A JWT carries a header naming the algorithm used to sign it, and a correctly written verifier checks the signature against that named algorithm, rejecting anything it cannot validate. Here, the gateway apparently accepted tokens signed with an algorithm outside its expected set instead of rejecting them, so an attacker who understands the gap can hand-craft a token and walk in without ever knowing a real signing key.

RelatedCritical JFrog Artifactory Bug Lets Hackers Forge Admin Tokens

That is a well known class of bug. What makes this instance dangerous is where it sits: a gateway that fronts an organization's backend APIs and holds the credentials those APIs depend on.

Why is CVE-2026-5430 rated a perfect 10?

WSO2 scored the flaw 10.0 under CVSS 3.1, with the vector AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. That string means it is exploitable over the network, requires no special access or user interaction, and delivers full compromise of confidentiality, integrity and availability with a scope change to boot. WSO2 adjusts that down to 9.8 for single-tenant deployments, and both figures are circulating in coverage: The Hacker News cites 9.8, SecurityWeek cites 10.0. They are the same advisory read two different ways, not a discrepancy.

The impact line from WSO2 is blunt: "unauthorized access, including potential compromise of administrative accounts and full account takeover." Hacktron Team is credited with the original discovery. WSO2 fixed the bug in its code in April 2026 and published the advisory a month later, on May 3. The CVE-2026-5430 record itself did not appear until early August, and WSO2 has never published a technical write-up. watchTowr reproduced the bug by diffing the vendor's own patch against the prior code, a common way to reverse-engineer a fix when a vendor stays quiet on specifics.

Which WSO2 products and versions are affected?

Four product lines carry the flaw across ten version entries in total: WSO2 API Manager 4.1.0, 4.2.0, 4.3.0, 4.4.0, 4.5.0 and 4.6.0; WSO2 API Control Plane 4.5.0 and 4.6.0; WSO2 Traffic Manager 4.5.0 and 4.6.0; and WSO2 Universal Gateway 4.5.0 and 4.6.0.

Subscription customers reach a fix through WSO2 Updates, at product-specific update levels that WSO2 lists ranging from Update 21 to Update 257 depending on the exact product and version. Anyone running the open-source builds can pull the two GitHub pull requests directly: carbon-apimgt PR #13752 and product-apim PR #14167.

1. April 2026WSO2 ships the fix patched in open-source code and pushed to subscription update channels before any public advisory
2. May 3, 2026Advisory WSO2-2026-5328 published rated Critical, CVSS 10.0 (9.8 for single-tenant deployments)
3. Early August 2026CVE-2026-5430 record published no technical write-up accompanied it; WSO2 never detailed the bug
4. September 13, 2026Honeypot hits begin watchTowr's network logs forged JWTs carrying admin privileges
5. September 16, 2026Exploitation attempts go public The Hacker News and SecurityWeek report on the honeypot findings

What is watchTowr seeing in the wild?

watchTowr runs a network of honeypots designed to look like real, exposed systems, and on September 13, 2026 those honeypots logged forged JWT tokens arriving with administrator privileges already embedded. Yordan Ganchev, principal threat intelligence specialist at watchTowr, put the blast radius plainly: "The forged token yields access to every API backend endpoint and its credentials, consumer keys and secrets for every registered application." He added that a compromised gateway can intercept API requests outright, which opens the door to data theft and lateral movement into whatever systems those APIs touch.

One detail suggests the attackers are still tuning their aim: an early payload landed against the wrong WSO2 product entirely. watchTowr confirmed separately that the same payload works against genuinely vulnerable systems, so the misfire looks like reconnaissance sloppiness, not proof the bug is hard to exploit.

RelatedCisco UCM SSRF Flaw CVE-2026-20230 Is Under Active Attack

Who is actually at risk right now?

Anyone running an unpatched, internet-reachable instance of the four affected products is exposed today, five months after a fix existed. That gap is a familiar pattern: once a CVE record goes public and a vendor's patch sits on GitHub for anyone to diff, attackers get a blueprint even without an official write-up. watchTowr caught a similar dynamic in early September 2026 with JFrog Artifactory CVE-2026-82329, where in-the-wild exploitation also involved forging admin tokens against a widely deployed developer tool. GenZTech covered that case at its own report. Two unrelated products, same lesson: a patch diff is often enough to hand attackers a working exploit.

CVE-2026-5430 has not appeared on CISA's Known Exploited Vulnerabilities catalog as of this writing, though active exploitation reports like watchTowr's frequently precede a KEV addition.

What should WSO2 admins do next?

Three steps matter more than general advice to "patch everything." First, update to the listed patch levels or apply the two GitHub pull requests directly on open-source builds. Second, rotate consumer keys, secrets and admin credentials on any instance that sat internet-exposed and unpatched after May 3, since a forged token could already have walked off with them. Third, review gateway logs for tokens carrying unexpected algorithm values going back to at least September 13, when watchTowr's honeypots first caught the pattern.

Our take

The five month lag between WSO2's April patch and September's exploitation attempts is not unusual, but it is a reminder that a quiet vendor disclosure buys time, not safety. WSO2 never published exploit details, yet a competent research team reproduced the bug from the patch alone within weeks of the CVE going public. Treat "no technical write-up" as a false sense of security. If your organization runs API Manager, Traffic Manager, Universal Gateway or the API Control Plane and has not checked update levels since spring, this is the week to do it.

Original analysis by GenZTech, drawing on the primary source and the sources listed above.