Attackers Exploit a Maximum-Severity WSO2 API Manager Flaw With Forged Admin Tokens

Security firm watchTowr says its honeypot network caught real attackers exploiting a maximum-severity vulnerability in WSO2’s API management software starting September 13, sending forged authentication tokens that already carry administrator privileges baked in. The vulnerability itself is not new. WSO2 quietly fixed the underlying code back in April and published a public advisory in May. What changed this month is that someone finally started using it.

WSO2 API Manager is open source middleware that lets organizations design, secure, and manage APIs, services, and identities across hybrid and multi-cloud environments. According to SecurityWeek, the platform has nearly 1,000 enterprise customers worldwide in sectors including banking, government, telecom, and logistics, with thousands more running it through open source deployments, OEM relationships, and partners. That scale matters here because an API gateway sits between the outside world and an organization’s other systems by design, so a forged administrator credential at that layer has consequences well beyond the gateway itself.

How the Bypass Works

The flaw, tracked as CVE-2026-5430, lives in how WSO2’s JWT authentication mechanism checks the cryptographic signature on a JSON Web Token before trusting it. NIST’s National Vulnerability Database classifies it as CWE-347, improper verification of a cryptographic signature. In plain terms, the service accepts tokens signed with algorithms it was never configured to support, and validates them anyway instead of rejecting them outright.

“JWT authentication can be bypassed when a token is signed using an unsupported algorithm, allowing unauthorized access,” WSO2 wrote in its own advisory. “Successful exploitation of the vulnerability may lead to unauthorized access, including potential compromise of administrative accounts and full account takeover.”

WSO2’s advisory lists the base severity as critical, with a CVSS score of 10.0, the maximum possible, in deployments where a compromise in one tenant can spill into others. The company notes that in single-tenant deployments, it adjusts that score down to 9.8, since the impact there “is contained within a single security authority boundary.” Yordan Ganchev, principal threat intelligence specialist at watchTowr, put it more bluntly in a statement shared with The Hacker News: “So, it’s easy to see why this is a critical bug (CVSS 10.0). It affects API Manager 4.1.0 through 4.6.0, API Control Plane, Traffic Manager and Universal Gateway.” NVD’s own record confirms the 10.0 base score.

What a Forged Token Buys an Attacker

Because API Manager is built to sit in front of an organization’s other applications, a valid-looking administrator token does more damage there than it would on an ordinary web app. “The forged token yields access to every API backend endpoint and its credentials, consumer keys and secrets for every registered application,” Ganchev told SecurityWeek. “The service is also by definition made to intercept API requests on their way to internal systems, which provides a great opportunity to tap and steal sensitive data in transit and interact with internal services through this ‘Lateral Movement-as-a-Service’ product.”

WatchTowr’s own discovery came with a stroke of luck built in. Ganchev said the firm’s honeypots first observed an attacker aiming a forged token at the wrong WSO2 product, one that was not actually vulnerable to this specific flaw, before the researchers replayed the identical payload against a real, exploitable deployment and watched it work. “Our honeypots were fortunate to be mixed up,” Ganchev said, “but the same may not be guaranteed about real victim systems.”

A Four-Month Gap Between the Patch and the Attacks

The timeline is the part of this story that stands out. WSO2 engineers merged the underlying code fix on GitHub on April 12, 2026, then published a formal security advisory three weeks later, on May 3. A public CVE identifier for the bug did not appear until August 6, roughly three months after that, and WSO2 has still not released technical details beyond what its advisory already states. WatchTowr’s honeypots did not record a real exploitation attempt until September 13, more than five months after the code fix shipped.

Ganchev told SecurityWeek that his team easily reproduced the vulnerability based on WSO2’s own patch, despite the lack of public technical detail. “The only mystery here is what took everyone else so long,” he said.

Fixes are available for every affected product. API Control Plane needs update level 4.5.0.58 or 4.6.0.22, Traffic Manager needs 4.5.0.56 or 4.6.0.21, and Universal Gateway needs 4.5.0.57 or 4.6.0.21, depending on which branch a deployment runs. API Manager alone needs one of six different fix levels depending on its own branch: 4.1.0.257, 4.2.0.197, 4.3.0.108, 4.4.0.72, 4.5.0.57, or 4.6.0.21. Community users can apply the fix directly from WSO2’s published pull requests for carbon-apimgt and product-apim. Hacktron Team is credited with originally discovering and reporting the flaw to WSO2, according to The Hacker News. As of publication, CVE-2026-5430 has not been added to CISA’s Known Exploited Vulnerabilities catalog, though that omission may not last given watchTowr’s public confirmation that exploitation is already underway.