WSO2 API Manager CVE-2026-5430

Exploitation requires network reachability to a WSO2 component that authenticates requests via the affected JWT mechanism (API Manager, Universal Gateway, Traffic Manager, API Control Plane, or the Carbon REST API Utility) and the ability to submit a self-crafted JWT with an algorithm outside the configured/supported set. Per the CVSS vector (AV:N/AC:L/PR:N/UI:N) there is no requirement for prior authentication, valid credentials, user interaction, or a non-default toggle - the weakness is in how any token's algorithm is validated. The principal limiting factor is exposure: risk is highest where these endpoints (especially the admin/management REST APIs) are reachable by the attacker, and the impact ceiling differs by deployment model - the description notes single-tenant deployments contain the blast radius to one security authority (9.8) versus scope-crossing impact (10.0) in shared/multi-tenant setups.

All available severity signals point to top-tier risk on paper: the CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N (network-reachable, low complexity, no privileges, no user interaction) with high confidentiality, integrity, and availability impact, yielding 10.0 scope-changed and 9.8 scope-unchanged. A signature-verification bypass on an authentication mechanism is directly weaponizable and typically automatable, and it targets the exact component whose job is to enforce trust, so technical impact is total for the protected authority. Tempering that: there is no EPSS score, no CISA KEV listing, and no POC referenced in the provided data, so this is high-severity-by-design rather than confirmed in-the-wild exploitation - no public exploit identified at time of analysis. The scope metric is the one genuine conflict in the input: the top-line vector uses S:C (10.0) while the description argues S:U/9.8 for single-tenant deployments where impact is contained within one security authority; defenders running multi-tenant gateways should treat it as scope-changed, while single-tenant operators can use 9.8 - either way it is a real, high-priority patch.

An attacker who can reach the WSO2 API/management endpoints over the network crafts a JWT using an algorithm the server should not accept - for example forcing 'none' or an algorithm-confusion substitution - and presents it to the authentication layer. Because the mechanism validates tokens signed with algorithms other than those configured, the forged token is accepted and the attacker is granted a session, potentially as an administrator, with no prior credentials or user interaction. No POC was referenced in the provided data, but the technique is well-understood and low-complexity per the CVSS AC:L rating.