Attackers Are Actively Exploiting a Perfect-10 WSO2 Authentication Flaw

Key points

• CVE-2026-5430, a vulnerability in WSO2's API platform, carries a maximum severity score of 10 out of 10.
• WSO2 patched the flaw in April 2026, but criminals began actively exploiting it on September 13, 2026, according to WatchTowr.
• The bug lets attackers forge a JWT (a digital login token) and gain full access to API back-end credentials and internal systems.
• WSO2 has nearly 1,000 enterprise customers in banking, government, telecom and logistics, plus thousands more open-source deployments.
• WatchTowr confirmed the exploit works even though no public technical details had been released, because the fix itself revealed how the flaw worked.

WSO2 is a widely used software platform that helps large organisations manage their APIs and digital identities. An API, or application programming interface, is the plumbing that lets different software systems talk to each other: it moves data between a bank's app and its servers, between a government portal and its database. When that plumbing is broken, a lot of sensitive information is suddenly in reach.

The flaw, tracked as CVE-2026-5430, lives inside how WSO2 handles JWTs, which stands for JSON Web Tokens. Think of a JWT as a digital badge: it tells a system who you are and what you're allowed to do. WSO2 is supposed to check that the badge was issued by a trusted authority before letting anyone through. This bug means it skips that check when the badge was signed using an unrecognised method, accepting the forgery as genuine.

With a forged token in hand, an attacker gets the keys to everything the API platform touches: backend endpoint credentials, consumer keys and secrets for every registered application, and a front-row seat to intercept data flowing between internal systems. WSO2's own May advisory put it plainly: exploitation can lead to full account takeover, including administrator accounts.

How did the criminals find this?

They didn't need leaked source code or an insider tip. WatchTowr's team reverse-engineered the attack simply by studying WSO2's own April patch.

WatchTowr principal threat intelligence specialist Yordan Ganchev told SecurityWeek that the CVE record was only published in early August, and that no public technical write-up exists. None of that mattered. "The only mystery here is what took everyone else so long," Ganchev said.

WatchTowr's honeypot network, a set of decoy systems designed to attract and log real attacks, recorded the first exploitation attempt on September 13. The attacker targeted a slightly wrong product variant, which is the only reason their honeypot caught it cleanly. Ganchev's team then replayed the same payload against the correct product and it worked.

Should customers be worried?

Yes, particularly anyone running an unpatched WSO2 deployment. Patching in April and sitting still since then isn't necessarily enough if the update wasn't applied promptly.

If your organisation uses WSO2, confirm you're running a version released after April 2026. Then review your API access logs for unexpected authentication events, particularly any token-based logins that don't match known applications or users. Check against WSO2's vendor advisory for version-specific guidance.

For ordinary people this one is largely invisible: the risk sits inside enterprise infrastructure, not consumer-facing login pages. Customers of banks, government agencies or telecoms providers running WSO2 should watch for breach notifications over the coming weeks.

We first covered this vulnerability on 16 September in "Hackers Are Forging Admin Tokens to Take Over WSO2 API Manager"; this story adds WatchTowr's honeypot findings and the exploitation timeline.

A four-month gap between patch and active exploitation isn't unusual. It's still four months that unpatched organisations spent exposed to a maximum-severity flaw with a trivially reproducible exploit. The patch existed. The window was there.