WSO2 Identity Server CVE-2025-13736

The Multi-Attribute Login feature must be explicitly enabled in the WSO2 deployment - this is the single required configuration prerequisite. The vulnerability persists regardless of how the validate_username setting is configured, meaning that control provides no mitigation. The login endpoint must be network-reachable by the attacker (AV:N), but no authentication or user interaction is required (PR:N, UI:N). The AC:H rating reflects the deployment constraint: the attacker must identify a target where Multi-Attribute Login is active, but once a qualifying target is found, exploitation is deterministic and requires no special tooling or timing. Exploitation is limited to information disclosure - no direct account compromise occurs from this vulnerability alone. Deployments with Multi-Attribute Login disabled are not affected.

The NVD-assigned CVSS 3.1 score of 3.7 (Low) reflects a narrow confidentiality impact (C:L) with no integrity or availability consequence, and AC:H acknowledges that the attack is constrained to deployments with Multi-Attribute Login enabled - a non-default feature. EPSS data was not provided, and no KEV or POC signals are present, indicating no confirmed or publicly demonstrated exploitation at time of analysis. The real-world risk is best understood as an enabler rather than a primary attack: alone, this vulnerability yields only username existence information, which is low-value. However, against WSO2 deployments in regulated sectors (banking, financial services, API gateway environments), validated usernames can meaningfully increase the precision and success rate of credential-stuffing, brute force, and spear-phishing campaigns. The AC:H rating partially reflects the deployment constraint but should not be interpreted as high technical complexity once a target environment is confirmed - the discrepancy is deterministic and automatable. Risk is moderate for organizations where Multi-Attribute Login is deployed in externally facing IAM portals, and low for those where it is disabled or the login interface is not internet-accessible.

An external attacker targeting an organization's WSO2 Identity Server portal - which has Multi-Attribute Login enabled for employee self-service - writes a script that submits login requests with a wordlist of email addresses. Requests for real employee accounts receive responses containing the canonical WSO2 username (e.g., the employee's internal username), while requests for non-existent addresses echo the raw submitted value. Within minutes, the attacker builds a validated list of active accounts and uses it to launch a targeted credential-stuffing campaign against the same portal using previously breached password datasets. No public exploit code is known at time of analysis, but the mechanism is straightforward to implement independently.