WSO2 API Manager CVE-2026-1728

Exploitation requires the attacker to already hold a low-privileged (non-admin) user account on the affected WSO2 product AND be able to obtain a valid token for that account; with that token, they directly invoke the product-level Admin REST APIs, which fail to reject the insufficiently-restricted token. Limiting factors: valid authenticated credentials/token are mandatory (not truly unauthenticated despite the published PR:N), and the practical exposure depends on how easily an attacker can acquire a low-privileged account - trivial in deployments with open/self-service registration or multi-tenant subscriber access, much harder in closed deployments with tightly controlled account provisioning and no public signup.

The published CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, score 9.8) conflicts with the vulnerability's own description, which explicitly states the attacker must 'already possess a low-privileged user account and be able to obtain a valid token for it.' That prerequisite is authenticated access, which is PR:L, not PR:N - so the true base score is closer to 8.8 (High) than 9.8 (Critical); verify PR with the vendor. Even adjusted, the risk is serious: network-reachable, low complexity, no user interaction, and full confidentiality/integrity/availability impact via admin takeover. There is no EPSS score, no KEV listing, and no SSVC decision data in the input, and no public exploit identified at time of analysis, so this appears to be a vendor-reported issue rather than one with evidence of active exploitation. The gating factor - needing a valid low-privileged account - makes this most dangerous in multi-tenant or self-service-signup deployments where obtaining a low-privileged account is trivial.

An attacker registers or is granted an ordinary low-privileged account (e.g., a subscriber/developer on a shared API Manager instance), obtains a valid OAuth/JWT token for that account, and then replays it against the product's Admin REST API endpoints. Because the token's privileges are not properly restricted, the admin API accepts it, letting the attacker perform administrative actions up to full account/tenant takeover. No public exploit code is identified, and the low attack complexity means a simple authenticated API request suffices once a token is held.