WSO2 Identity Server CVE-2025-13591

Exploitation requires only network reachability to the WSO2 Identity Server authentication endpoint; per the CVSS vector (AV:N/AC:L/PR:N/UI:N) no authentication, user interaction, or special privileges are needed, and the flaw is present in the default behavior of the affected authenticators (Email OTP Authenticator, WSO2 Carbon Abstract OTP Authenticator) rather than requiring a non-default configuration. The limiting factor is impact rather than access: the attacker only learns which usernames are valid (CWE-203 response discrepancy) and gains no credentials, data, or code execution directly, so value is realized only when chained with brute-force, password-spraying, or social-engineering follow-on attacks. Exposure is reduced where the authentication endpoint is not reachable from untrusted networks or is fronted by rate-limiting/WAF controls.

This is a low-to-moderate priority information-disclosure issue (CVSS 5.3), not a critical flaw. The CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N) correctly reflects a username-enumeration weakness (CWE-203): remotely reachable over the network, trivial to execute, no authentication or user interaction, but with only limited confidentiality impact and zero integrity or availability impact. No EPSS score was provided, the CVE is not listed in CISA KEV, and no public proof-of-concept is referenced - so there is no signal of active or imminent exploitation. The real-world risk is that of a precursor/amplifier rather than a direct compromise: it hands attackers a validated list of usernames that strengthens downstream credential brute-forcing, password spraying, and targeted phishing. Signals are internally consistent (low-severity scope-unchanged confidentiality leak with network reach), so there is no conflict to flag; the main caveat is that all exploitation and impact data derive from the single vendor advisory and the NVD vector, with no independent exploitation telemetry available.

An unauthenticated attacker scripts repeated requests to the WSO2 Identity Server authentication endpoint using a candidate username list, observing that responses differ for existing versus non-existing accounts. By comparing these discrepant responses, the attacker compiles a list of valid usernames. No public exploit code is referenced, but the technique requires only an HTTP client and simple response-diffing.