decrypted · 17 september 2026 · vulnerabilities and patching · supply chain · uk policy and law

A forged token is all it takes to become admin on WSO2's gateway

WSO2 patched a critical flaw in its API management software back in April. By September, watchTowr's honeypots were catching forged tokens arriving with administrator privileges already baked in, proof that whoever built the exploit had read the patch notes rather than the original advisory. It is a reminder that publishing a fix and getting it installed are two very different events, and the gap between them is where attackers make a living.

The bug: letting the visitor pick the rulebook

WSO2 API Manager, along with its Traffic Manager, API Control Plane and Universal Gateway products, checks who is calling an API using JSON Web Tokens: signed credentials that say, in effect, "this request comes from this user, trust me." The flaw, CVE-2026-5430, sits in how that check happens. WSO2's own advisory describes it plainly: JWT authentication could be bypassed by signing a token with an algorithm the system was not expecting.

Picture a bouncer whose job is to check ID against a specific rulebook, except the design lets the visitor decide which rulebook applies. Present a token signed with a weaker or unsupported method and the gateway would still wave it through, administrator rights and all. WSO2 rates the flaw 10.0 out of 10, the maximum possible on the CVSS scale.

Months of runway, then a rush

WSO2 shipped a fix in April, published its advisory in May, and the CVE record was formally opened in August. That is a long window for defenders to patch and for attackers to take notice. Both happened. Exposure management firm watchTowr says its honeypot network began catching forged JWTs with admin rights arriving on 13 September, and by Tuesday it was warning publicly that exploitation attempts were under way against internet-facing deployments. Hacktron Team gets credit for finding the flaw; whoever wrote the exploit clearly worked from WSO2's own patch commits.

Secure by Design: don't let the caller choose the lock

This pattern is not new. JSON Web Token libraries have been catching algorithm-confusion bugs for well over a decade, and the lesson keeps not sticking: a verifier must fix, in advance, exactly which algorithm and which key it will accept, and never take instructions on that point from the token being verified. Anything else lets an attacker pick the cryptography that suits them.

For UK organisations the stakes are not abstract. WSO2's own Open Banking toolkit, built for compliance with the UK's Open Banking Standard, runs on top of WSO2 Identity Server and API Manager. There is no evidence any Open Banking deployment has been touched by this specific flaw, but the architecture makes the point: API gateways are not administrative plumbing, they are often the entire trust boundary between the internet and a bank's core systems. If a gateway can be fooled about who it is talking to, nothing behind it is protected by anything else. Any UK organisation running WSO2 API Manager, Traffic Manager or Universal Gateway on versions 4.1.0 through 4.6.0 should check its patch level now, rather than wait for a breach notice to make the decision urgent.

Also this week

The ICO is getting a new name and a board. From 30 September, the Information Commissioner's Office becomes the Information Commission, moving from a single Commissioner to a board-led body under the Data (Use and Access) Act 2025. The ICO says its regulatory powers and duties carry over unchanged, and continuity is the message for anyone with an open complaint or investigation. Mainly worth knowing so the citation in your next data protection policy does not look out of date by October.

A Chinese-speaking group turned a five-month-old Gitea bug into a source code raid. Acronis's Threat Research Unit found a threat actor it calls Red Heron scanning nearly 1,400 internet-facing Gitea instances and exploiting CVE-2026-60004, a critical remote code execution flaw patched in Gitea 1.27.1 back in July, within days of proof-of-concept code appearing online. Confirmed victims span government and industrial targets in Taiwan, the US, Canada, Argentina and Sri Lanka, with hundreds of repositories, including SCADA and IoT tooling, stolen from one industrial firm before the attackers installed a custom Linux rootkit to cover their tracks. No UK organisation has been named, but any team self-hosting Gitea, or any code hosting platform, on the open internet should treat this as the week to check the version number: stolen source code is not just embarrassing, it is a blueprint for whatever gets built on it next.

Sources

If you want a second opinion on how your organisation's authentication design holds up under scrutiny, get in touch.

More like this

Get the next post by email: subscribe to Decrypted. Double opt-in, unsubscribe any time, or take the RSS feed.

Prefer to listen? Decrypted on Apple Podcasts, or paste the podcast feed into any app.