CVE-2024-6832: 
WSO2 API Manager vulnerability analysis and mitigation

CVE-2024-6832 is an account lockout bypass vulnerability in multiple WSO2 products caused by a protection mechanism failure (CWE-693). When secondary user stores are inaccessible, the account locking mechanism fails to trigger, allowing unauthenticated attackers to perform brute force attacks against user accounts in accessible stores without consequence. Affected products include WSO2 Identity Server (5.10.0–7.0.0), WSO2 API Manager (3.1.0–4.6.0), WSO2 API Control Plane (4.5.0–4.6.0), WSO2 Traffic Manager (4.5.0–4.6.0), WSO2 Universal Gateway (4.5.0–4.6.0), WSO2 Identity Server as Key Manager (5.10.0), WSO2 Open Banking IAM/AM (2.0.0), and WSO2 Enterprise Integrator (6.6.0). The vulnerability was published on August 6, 2026, with a CVSS v3.1 base score of 5.9 (Medium) per the GitHub Advisory, though NVD assigns 7.5 (High) (GitHub Advisory, WSO2 Advisory).

The root cause is classified as CWE-693 (Protection Mechanism Failure), specifically in the WSO2 Carbon User Manager Kernel (org.wso2.carbon:org.wso2.carbon.user.core) and the broader WSO2 identity and API management stack. When the system is configured with multiple user stores and one or more secondary stores become unreachable, the account locking logic does not maintain a consistent state — it fails to apply lockout to accounts in the remaining accessible stores. An unauthenticated attacker can exploit this by deliberately targeting authentication endpoints during periods of secondary user store unavailability (e.g., network partition, service outage), submitting unlimited invalid credential attempts without triggering the lockout threshold. No special privileges or user interaction are required, and the attack is conducted entirely over the network (GitHub Advisory, WSO2 Advisory).

Successful exploitation allows an unauthenticated attacker to conduct unlimited brute force attempts against user accounts in accessible user stores, with the primary impact being high confidentiality loss through potential credential compromise. There is no direct integrity or availability impact from the vulnerability itself. If credentials are successfully guessed, an attacker could gain unauthorized access to the affected WSO2 platform — which may manage API access, identity federation, and open banking flows — potentially enabling lateral movement into downstream systems and exposure of sensitive user or API data (GitHub Advisory, WSO2 Advisory).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at the time of disclosure (GitHub Advisory). The EPSS score is approximately 0.25% (15th percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. NVD's SSVC assessment classifies exploitation as "none" and technical impact as "partial," and notes the attack is not fully automatable due to the dependency on secondary user store unavailability as a precondition.

1. Reconnaissance: Identify internet-facing WSO2 Identity Server, API Manager, or related product instances running affected versions using tools like Shodan or Censys, targeting login endpoints.
2. Trigger or await secondary user store unavailability: The lockout bypass only activates when secondary user stores are unreachable. An attacker may wait for natural outages, or in some configurations, attempt to cause a secondary store to become unavailable (e.g., network-level disruption).
3. Identify target accounts: Enumerate valid usernames through error message differences, public directories, or other OSINT techniques targeting the primary/accessible user store.
4. Launch brute force attack: Submit repeated authentication requests with invalid passwords against the target account via the WSO2 login endpoint (e.g., /commonauth or API authentication endpoints). Because the lockout mechanism fails to trigger, there is no account lockout consequence.
5. Achieve credential compromise: Upon successfully guessing a valid password, authenticate as the target user and access the WSO2 platform, potentially gaining access to APIs, identity management functions, or open banking services (GitHub Advisory, WSO2 Advisory).

• Network: High volume of authentication requests (POST to /commonauth, /oauth2/token, or similar WSO2 authentication endpoints) from a single or small set of IP addresses; repeated failed login attempts without triggering account lockout events.
• Logs: WSO2 authentication logs showing numerous consecutive failed login attempts for the same username without corresponding account lock events; absence of AccountLocked audit log entries despite repeated failures; errors or warnings related to secondary user store connectivity (e.g., LDAP/AD unreachable).
• Application Behavior: User store connectivity errors in WSO2 server logs (e.g., UserStoreException or LDAP connection timeout messages) coinciding with a spike in authentication failures for primary store users.

WSO2 has released patched versions for all affected products. Key fixed versions include: WSO2 Identity Server ≥ 5.10.0.320, 5.11.0.427, 6.0.0.254, 6.1.0.195, 7.0.0.82; WSO2 API Manager ≥ 3.1.0.296, 3.2.0.386/455, 3.2.1.74, 4.1.0.238, 4.2.0.179, 4.3.0.91, 4.4.0.55, 4.5.0.39, 4.6.0.4; WSO2 API Control Plane ≥ 4.5.0.40, 4.6.0.5; WSO2 Traffic Manager and Universal Gateway ≥ 4.5.0.38, 4.6.0.4/5; WSO2 Identity Server as Key Manager ≥ 5.10.0.314; WSO2 Open Banking IAM ≥ 2.0.0.366; WSO2 Open Banking AM ≥ 2.0.0.345; WSO2 Enterprise Integrator ≥ 6.6.0.229. As interim workarounds, organizations should ensure all configured secondary user stores remain highly available, implement IP-based rate limiting or WAF rules on authentication endpoints, and monitor for secondary user store connectivity failures. Upgrading to a patched version is the recommended remediation (WSO2 Advisory, GitHub Advisory).