EUVD-2025-210626
GHSA-g8w9-p6wx-8fxc
Severity by source
AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:N/A:N
Network-reachable login endpoint, no auth or interaction needed; AC:H reflects non-default Multi-Attribute Login prerequisite; only limited username disclosure, no integrity or availability impact.
Primary rating from Vendor (WSO2).
CVSS VectorVendor: WSO2
Lifecycle Timeline
2DescriptionCVE.org
When Multi-Attribute Login is enabled, the login interface fails to consistently mask the existence of user accounts. For valid users, the server resolves and displays their canonical username, while for non-existent users, it echoes the original input. This occurs regardless of the validate_username configuration.
The discovery of valid usernames can increase the risk of brute force attacks, social engineering attacks, and targeted information leakage. Attackers can leverage this information to craft more effective phishing campaigns or social engineering tactics to compromise user accounts or extract sensitive data.
AnalysisAI
Username enumeration via observable login response discrepancy affects WSO2 Identity Server, WSO2 Identity Server as Key Manager, WSO2 API Manager, WSO2 Open Banking AM, and WSO2 Open Banking IAM when the Multi-Attribute Login feature is enabled. When a valid username is submitted, the server resolves and returns the canonical form of that username; when an invalid username is submitted, the server echoes the raw input unchanged - creating a deterministic, scriptable oracle for account existence. This disclosure path persists regardless of the validate_username configuration setting, meaning a common hardening measure provides no defense. No public exploit code has been identified at time of analysis, and the vulnerability is not listed in the CISA KEV catalog.
Technical ContextAI
CWE-203 (Observable Discrepancy) describes vulnerabilities where a system's behavior leaks information through differences in response content, timing, or structure depending on internal state. Here, the WSO2 Multi-Attribute Login subsystem - which allows users to log in using alternate identifiers such as email or mobile number - must resolve the submitted attribute to a canonical internal username before authentication proceeds. For valid accounts, this resolution succeeds and the canonical username is surfaced in the response; for non-existent accounts, no resolution occurs and the raw input is returned verbatim. The affected CPEs span five WSO2 products: wso2_identity_server, wso2_identity_server_as_key_manager, wso2_api_manager, wso2_open_banking_am, and wso2_open_banking_iam, all under the cpe:2.3:a:wso2 namespace with wildcard version ranges, indicating broad version coverage across the product family. The validate_username configuration flag - presumably intended to control whether usernames are validated or masked - has no effect on this disclosure path, suggesting the discrepancy is introduced before that control is applied.
RemediationAI
Consult the WSO2 security advisory WSO2-2025-4013 at https://security.docs.wso2.com/en/latest/security-announcements/security-advisories/2026/WSO2-2025-4013/ for the official patch and fixed version details, as no specific remediated release version was confirmed in available intelligence. As an immediate compensating control, if Multi-Attribute Login is not operationally required, disable the feature entirely in the WSO2 Identity Server configuration - this removes the vulnerable code path completely. For deployments where Multi-Attribute Login is required, restrict access to the login endpoint at the network perimeter (WAF or reverse proxy rule) to known IP ranges or authenticated networks, reducing the attacker's ability to probe accounts at scale; note that this does not eliminate the vulnerability, only constrains who can exploit it. Additionally, implement account lockout and rate-limiting on the login endpoint to increase the cost of systematic enumeration, and configure alerting on high volumes of failed login attempts from single sources.
More in Wso2 Api Manager
View allAuthentication bypass in WSO2 API Manager and related components (Universal Gateway, Traffic Manager, API Control Plane,
Server-side request forgery in WSO2 API Manager lets unauthenticated remote attackers coerce the gateway into making ser
Privilege escalation in WSO2 API Manager and related Carbon-based products allows a low-privileged user, using a validly
Authentication bypass in WSO2 Identity Server and multiple WSO2 platform products (API Manager, Open Banking AM/IAM/KM,
Persistent denial of service in multiple WSO2 products - including WSO2 API Manager, WSO2 Universal Gateway, WSO2 Traffi
OS command injection (CWE-78) in WSO2's shared Carbon Console administrative interface allows an authenticated administr
The XML parsers within multiple WSO2 products accept user-supplied XML data without properly configuring to prevent the
Role-based access control bypass in WSO2 API Manager 3.x allows authenticated users with the 'Internal/Everyone' role to
Reflected cross-site scripting across at least eight WSO2 platform products - including Identity Server, API Manager, AP
The authentication endpoint fails to adequately validate user-supplied input before reflecting it back in the response.
Reflected cross-site scripting in the authentication endpoint of WSO2 API Manager and Identity Server allows unauthentic
WSO2 API Manager and API Control Plane use a non-cryptographic PRNG in the API Publisher component to generate shared se
Same weakness CWE-203 – Observable Discrepancy
View allSame technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today