WSO2 API Flaw Under Attack, and It Powers RBI's Lending System

Security researchers didn't have to guess whether attackers would go after a months-old software flaw — they watched it happen in real time, on a decoy server built to look like a real target. On September 13, forged login tokens carrying admin-level access started hitting a trap system run by threat-intel firm watchTowr. The software being attacked: WSO2 API Manager, a widely used open-source tool that lets companies control and secure how their internal systems talk to each other over APIs.

What's actually broken

The flaw, tracked as CVE-2026-5430, lives in how WSO2's software checks login tokens called JWTs (JSON Web Tokens) — small signed packets of data that prove a user or system is who it claims to be, commonly used to log into apps and APIs without re-entering a password every time. WSO2's verification code was supposed to reject any token signed with an algorithm it didn't recognize. Instead, it let those tokens through. An attacker who knows this can hand-craft a JWT, mark it as belonging to an administrator, sign it with an algorithm the server doesn't support, and walk in the front door with full admin rights — no password, no valid credentials, nothing.

It carries a near-maximum severity score of 9.8 out of 10 and affects API Manager versions 4.1.0 through 4.6.0, along with WSO2's API Control Plane, Traffic Manager, and Universal Gateway products. WSO2 actually shipped a fix for this back in April, published a public advisory in May, and the CVE number was only formally assigned in August. Attackers started probing for it in the wild barely a month after that — a reminder that a patch sitting unapplied on a server is functionally the same as no patch at all.

Caught in the act

What makes this case unusually well-documented is that watchTowr's honeypot — a fake system deliberately exposed to the internet to attract and study attacks — caught the exploit attempt almost by accident. The attacker first fired a forged token at the wrong product in watchTowr's network, then came back and replayed the same trick successfully against the correct target. Yordan Ganchev, a principal threat intelligence specialist at watchTowr, put it bluntly:

"Our honeypots were fortunate to be mixed up, but the same may not be guaranteed about real victim systems."

Once inside, an attacker doesn't just get a login screen — they get the keys to the API management plane itself: every backend endpoint the gateway routes to, plus the consumer keys and secrets for every application registered on it. For a company using WSO2 to broker access between its internal services, that's close to a full compromise of the traffic layer.

Who's actually running this

WSO2 counts somewhere close to a thousand enterprise customers globally, spanning banking, telecom, government, and logistics. Telstra and Vodafone UK have both been named as users of the affected products in prior reporting. This isn't obscure niche software — it's the kind of infrastructure that sits quietly behind banking apps, telecom billing systems, and government portals, doing work nobody outside the IT team ever thinks about until it breaks.

• Full administrator access to the API management console, without valid credentials
• Visibility into every backend API endpoint the gateway connects to
• Exposure of consumer keys and secrets for every registered application
• No authentication logs to flag the intrusion, since the token looks technically "valid" to the system

Why this matters in India

This isn't a purely foreign problem. WSO2's own case studies describe its API Manager and Identity Server products as the technology stack behind the Reserve Bank of India Innovation Hub's Unified Lending Interface — the RBI-backed system that lets lenders pull a borrower's data from multiple sources in real time to speed up loan approvals. WSO2 has also worked with Indian banks including Federal Bank and Karnataka Bank on API-driven core banking projects. If any part of that lending or banking stack is still running an unpatched version of the affected software, this isn't an abstract CVE number — it's a live risk to systems that move real credit decisions and real money.

As of this writing, CERT-In hasn't published a public advisory on CVE-2026-5430, even though the RBI has separately pushed banks and NBFCs toward tighter API security requirements under its broader cybersecurity framework for regulated entities. That gap is worth watching. We've seen this pattern before with the PaperCut printer software bug that let attackers hit 395 organizations months after a fix was available — the software gets patched, but the patch doesn't reach every server that needs it, and attackers eventually notice the gap.

The real lesson here

A patch existing since April didn't stop this from becoming an active attack in September. That five-month window is where the actual damage happens — not in the moment a researcher finds a bug, but in the long stretch where organizations know a fix exists and haven't gotten around to applying it. For any Indian bank, fintech, or enterprise running WSO2 infrastructure, the fix here isn't complicated: check the version number, apply the patch, and stop treating "we'll get to it" as an acceptable answer for internet-facing admin access.