WSO2 Carbon OAuth CVE-2025-13173

Exploitation requires a precise non-default configuration: the session-bound token feature must be enabled AND token binding validation must be active AND the 'Revoke token upon user logout' option must be left inactive. The attacker must also already possess a valid session-bound token, meaning prior token acquisition (theft, shared device, or interception) is a hard prerequisite. Limiting factors: if 'Revoke token upon user logout' is enabled, or token binding validation is off, or a fresh SSO request re-triggers revocation, the condition does not arise - which materially narrows real-world exposure and is reflected in the AC:H metric.

This is a moderate, conditionally-exploitable session-management flaw (CWE-613, Insufficient Session Expiration) rather than a top-priority emergency. Multiple signals point the same direction: the CVSS 3.1 base score is 6.5 (MEDIUM) with AC:H, reflecting that exploitation depends on a specific non-default configuration, and the impact is only Low across confidentiality, integrity and availability (C:L/I:L/A:L). There is no CISA KEV listing and no public exploit identified, so there is no evidence of active or opportunistic exploitation - no public exploit identified at time of analysis. No EPSS score and no SSVC decision data were supplied in the input, so automatability and exploitation-status cannot be scored from an external framework. One signal requires explicit caution: the CVSS vector lists PR:N (no privileges), yet the description makes clear the attacker must already 'possess a valid session-bound token,' which in practice means a previously-authenticated credential was obtained - so the pure PR:N reading overstates how unauthenticated this really is; treat it as exploitation that presupposes prior credential/token acquisition. Net: a real but lower-urgency hardening issue for environments running the specific token-binding configuration, not a widespread remote-code-execution class threat.

An attacker who has obtained a valid session-bound token (for example from a shared or kiosk machine, token theft, or a browser left logged in) continues to use that token after the legitimate user ends their session. Because the token is not revoked at logout under the vulnerable configuration, the attacker retains access to WSO2-fronted APIs and resources and can read sensitive user data. No public proof-of-concept is available, and the attack hinges on first acquiring a valid token.