WSO2 API Control Plane

CVE-2026-5430, WSO2 API Manager, API Control Plane, Traffic Manager, Universal Gateway: a JWT algorithm-confusion bypass reaches full administrative control of the API gateway, exploited since 13 September (CVSS 10.0/9.8)

WSO2's API management stack sits between client applications and the backend services, keys and secrets it fronts, so a broken authentication boundary at the gateway compromises everything behind it. CVE-2026-5430 is exactly that break: a JSON Web Token verifier that should refuse any token signed with an algorithm it does not support instead accepts it, so a forged token is treated as a legitimate, admin-scoped session (WSO2, 2026-05-03). The bug reaches WSO2 API Manager, API Control Plane, Traffic Manager and Universal Gateway across the release lines WSO2's advisory lists (4.1.0 through 4.6.0), and needs no credentials and no user interaction, WSO2 rates it CVSS 10.0 on multi-tenant deployments and 9.8 on single-tenant, where impact stays inside one security-authority boundary. WSO2 published the fix on 2026-05-03; four months later, on 2026-09-13, exposure-management firm watchTowr's honeypot network caught the first forged-token exploitation attempt in the wild, and watchTowr says it "easily reproduced" the vulnerability based on the vendor's own patch (SecurityWeek, 2026-09-16). CISA added CVE-2026-5430 to its Known Exploited Vulnerabilities catalog on 2026-09-24, alongside an unrelated Adobe Commerce flaw (CISA, 2026-09-24).

The forged admin token is not a narrow read-only leak: watchTowr's Yordan Ganchev describes it as yielding "access to every API backend endpoint and its credentials, consumer keys and secrets for every registered application," and notes the gateway is "by definition made to intercept API requests on their way to internal systems," turning a compromised node into what he calls a "Lateral Movement-as-a-Service" product for reaching everything the gateway fronts (SecurityWeek, 2026-09-16). Ganchev also cautions that the observed attack targeted the wrong WSO2 product in watchTowr's own honeypot mix, but the same forged payload worked when replayed against the correct one; a coincidence that will not repeat on every real deployment. One notable inconsistency for defenders relying on the KEV catalog alone: CISA's own alert lists this addition as "WSO2 Multiple Products Path Traversal Vulnerability", a title that matches neither WSO2's advisory nor any researcher account, all of which agree this is a JWT-signature bypass, not path traversal (CISA, 2026-09-24; WSO2, 2026-05-03). A team that searches its KEV feed only for "path traversal" risks missing that this is the entry meant.

Kill chain: an attacker crafts a JWT whose header names a signing algorithm the gateway's verifier does not support, then presents it at the API Manager, Control Plane, Traffic Manager or Universal Gateway front door (T1190, exploiting the public- or partner-facing gateway interface); the verifier's missing algorithm check accepts the token instead of rejecting it, so the forged credential (T1606, Forge Web Credentials) is treated as an authenticated, administrator-scoped session with no legitimate login behind it. From that session the attacker can read every backend endpoint's credentials, every registered application's consumer keys and secrets, and tap API traffic passing through the gateway to internal systems.

Hunt and detection, telemetry class first: in gateway and Carbon HTTP access and authentication logs, look for admin-scoped sessions or privileged API calls with no corresponding identity-provider login event in the same window, that absence, not any single request, is the signal. Where a WAF or reverse proxy in front of the gateway logs JWT or Authorization header fields, check for alg values a correctly configured verifier should never have accepted. In application and consumer-key audit trails, flag reuse, mass export, or unexpected changes to registered applications' keys and secrets immediately following an anomalous authentication event. Start any hunt at 2026-09-13, the date of watchTowr's first observed exploitation attempt, and only look earlier with a specific reason to. Triage: a legitimate admin session traces back to a real, logged identity-provider authentication; an admin-scoped session or privileged API call with nothing behind it in the identity provider's own logs is the discriminator; an old version banner or a single stray Bearer token alone is not enough to escalate on.

Hardening: inventory every WSO2 API Manager, API Control Plane, Traffic Manager and Universal Gateway node (including partner-facing, OEM and forgotten lab instances) and bring each to its fixed update level (community users can apply WSO2's published fixes directly from its carbon-apimgt and product-apim repositories; support subscribers apply the corresponding WSO2 Updates release). Where immediate patching is not possible, remove management and gateway interfaces from public exposure. Because upgrading fixes the software but says nothing about the window between May and the patch date, any node found running below the fixed level should be treated as untrusted: rotate consumer keys, application secrets and admin credentials, and review every registered application and backend the gateway fronted before trusting it again (WSO2, 2026-05-03; Inception Security, 2026-09-21).