CVSS 10.0 WSO2 API Manager JWT authentication bypass exploited in the wild

Enterprises warned over critical WSO2 flaw

Enterprises running WSO2's API management products are being warned about active attacks exploiting a critical authentication bypass tracked as CVE-2026-5430. According to SecurityWeek, the vulnerability carries a CVSS score of up to 10.0 and is unauthenticated, meaning attackers need no valid account to target it. Researchers at watchTowr recorded the first exploitation attempts on September 13, 2026, and WSO2 has published a security advisory (WSO2-2026-5328) covering the issue.

The affected portfolio includes WSO2 API Manager, API Control Plane, Traffic Manager, and Universal Gateway.

How the bypass works

The flaw lies in how the products validate JSON Web Tokens. Affected versions accept JWTs signed with unsupported signing algorithms, which lets an attacker forge a token and have it treated as genuine. No credentials are stolen and no user interaction is required; the only precondition is that the attacker can reach the vulnerable JWT authentication process, typically an internet-facing API or management endpoint.

watchTowr's reproduction testing showed what a successful bypass yields. After replaying a captured payload against the correct product, researchers gained access to API backend destinations, credentials, and the consumer keys and secrets of registered applications. Because an API management platform sits in front of internal services and stores their credentials, this single hop can expose a wide slice of the internal estate.

What was actually observed in the wild

The field evidence deserves a careful reading. In watchTowr's honeypot network, an attacker sent a forged JWT — but aimed it at the wrong product, and that attempt did not succeed. watchTowr then replayed the same payload against the correct target and confirmed the authentication bypass works as described.

The picture, then, is that exploitation attempts are confirmed in the wild and the vulnerability is confirmed exploitable, but public reporting does not yet document successful compromises of real victim environments or subsequent data theft. That gap gives defenders a window to act before confirmed breaches start appearing.

Patching and containment

The WSO2 advisory sets product- and version-specific update levels. Subscription customers should verify they are on the required update level for their version branch, while community deployment users need to check that the applicable public fixes have been applied.

Restricting network access to the vulnerable paths also blocks this attack route, but the analysis notes that making only the management console private may not be enough: if other exposed APIs are configured to accept vulnerable JWTs, they remain attackable. Any credentials or consumer secrets that could have been exposed should be identified and rotated, with dependent services accounted for in the rotation plan.

What defenders should look for

Because no user interaction is involved, business users may notice nothing unusual. Useful signals include JWTs carrying unexpected or unsupported signing algorithms followed by high-privilege responses, access to API destinations or credentials by unknown or anonymous principals, and audit log changes to registered applications, consumer keys and secrets, or backend definitions. Standard URL-based proxy logs will not show JWT header contents, so these need to be cross-referenced with authentication and API audit logs. Teams should also watch for traffic from the gateway to internal APIs or data stores it does not normally connect to.

Why it matters

API management infrastructure is a choke point by design: it holds credentials for backend services and relays traffic to them, which is why a full takeover of administrator accounts could become a starting point for lateral movement into internal systems. A maximum-severity, unauthenticated bypass, combined with in-the-wild attempts observed days before the public warning, makes patching urgent for any exposed deployment. Teams that cannot patch immediately should restrict access to the vulnerable endpoints, and those who find evidence of a bypass should assume credentials were exposed and rotate them accordingly.