CVE-2026-5430 is a critical authentication bypass in WSO2's API management products. WSO2 shipped the fix on April 6, 2026 and published advisory WSO2-2026-5328 on May 3. Attackers started using it in September, and CISA added it to its Known Exploited Vulnerabilities catalog on September 24. If every API Manager node you run has been on a current update level since April, you are covered. If you are not sure, this post sets out what to check, in order.
What the flaw is
The JWT validation in the affected products accepted tokens signed with an algorithm the deployment does not support. An attacker who can reach an affected endpoint can forge a token that carries administrator rights. No login and no user interaction are needed. WSO2 rates it CVSS 10.0 in general and 9.8 for single-tenant deployments.
The impact is larger than one component suggests, because the gateway sits on the path of every API call. With admin rights, an attacker can read the consumer keys and secrets of every registered application and reach the backends those APIs front. The attempts watchTowr reported in September used forged JWTs.
Which products and versions are affected
| Product | Version | Minimum fixed update level |
|---|---|---|
| API Manager | 4.6.0 | 21 |
| API Manager | 4.5.0 | 57 |
| API Manager | 4.4.0 | 72 |
| API Manager | 4.3.0 | 108 |
| API Manager | 4.2.0 | 197 |
| API Manager | 4.1.0 | 257 |
| API Control Plane | 4.6.0 | 22 |
| API Control Plane | 4.5.0 | 58 |
| Traffic Manager | 4.6.0 | 21 |
| Traffic Manager | 4.5.0 | 56 |
| Universal Gateway | 4.6.0 | 21 |
| Universal Gateway | 4.5.0 | 57 |
Update levels from WSO2-2026-5328, checked November 8, 2026.
Update levels apply to deployments with a WSO2 subscription, which receive WSO2 Updates. Community deployments of the open-source product do not get update levels. They apply WSO2's public fixes from GitHub and rebuild, or move to a release that is not affected. The advisory is the authoritative list; check it before you act.
Step 1: Find every instance
Production is the obvious one. The instances that get missed are dev, test and disaster recovery environments, gateways another team deployed in another region, and separate Traffic Manager and Universal Gateway nodes. For each one, record the product, version, update level, and whether its management APIs can be reached from the internet.
Step 2: Confirm the update level
For subscription deployments, your WSO2 Updates records show the update level of each product home. Compare it with the table above. For community builds, confirm that the two fix pull requests linked in the advisory are in the build you actually run, not only in the source tree.
Step 3: Patch, or cut exposure until you can
Apply the update. If patching will take more than a few days, take the management and admin APIs off the public internet now and allow them only from a VPN or a trusted network segment. That reduces exposure. It does not fix the flaw.
Step 4: Look for signs of use
watchTowr first observed exploitation attempts on September 13, but the fix and the advisory were public from the spring, so review logs back to April 2026. Look for:
- Successful requests to the admin, publisher and developer portal REST APIs (/api/am/admin/, /api/am/publisher/ and /api/am/devportal/) from addresses you do not recognize
- New or changed administrator accounts
- Applications, subscriptions or keys that nobody can tie to a change ticket
- Unexpected file uploads through the management console
Step 5: If you find anything, rotate
Treat it as an incident. Rotate the consumer keys and secrets of registered applications and the credentials your APIs use to reach their backends. Then check those backends for calls from the gateway that do not match normal traffic. Patching closes the door. It does not take back what was already read.
A note on how scanners describe it
CISA's catalog entry describes CVE-2026-5430 as path traversal linked to file upload. WSO2's advisory describes a JWT authentication bypass. If a scanner or a ticket uses a different description, match on the CVE number and follow WSO2's advisory for the fix.
What this says about running WSO2 in production
The fix existed for five months before attackers arrived. The gap was operational, not technical: knowing which instances you run and at which update level, and having someone whose job is to apply updates within days. That work is routine, and it is easy to lose between teams. If you would rather hand it off, our WSO2 support and managed services cover update tracking, patching and incident response with published response times. If production is affected now, use the urgent option on the WSO2 support quote form.
