CVE-2025-10908: Authentication Bypass Vulnerability

CVE-2025-10908 Overview

CVE-2025-10908 is an authorization flaw affecting WSO2 products that fail to validate user account state during authentication. Locked user accounts can still authenticate successfully when using Magic Link or Passkey authentication methods. The flaw bypasses the account lock security control that should prevent access to restricted accounts.

The vulnerability is classified under [CWE-863: Incorrect Authorization]. WSO2 disclosed the issue in security advisory WSO2-2025-4388.

Critical Impact
Attackers can authenticate to accounts that administrators have explicitly locked, gaining unauthorized access to applications and sensitive data while undermining brute-force protections.

Affected Products

WSO2 products implementing Magic Link authentication
WSO2 products implementing Passkey (FIDO2/WebAuthn) authentication
Refer to WSO2 Security Advisory WSO2-2025-4388 for the full version matrix

Discovery Timeline

2026-05-11 - CVE-2025-10908 published to NVD
2026-05-13 - Last updated in NVD database

Technical Details for CVE-2025-10908

Vulnerability Analysis

The vulnerability is an authorization bypass in the authentication pipeline. WSO2 enforces an account lock mechanism that should reject login attempts against accounts marked as locked. The lock state is intended to apply uniformly across all authentication methods.

The Magic Link and Passkey authentication flows do not query the account lock attribute before issuing a session. As a result, an attacker with a valid Magic Link token or registered passkey credential can authenticate to a locked account. The intended security control is silently skipped.

This weakens the response to credential-stuffing and brute-force attacks. Administrators who lock an account in response to suspicious activity cannot rely on the lock to stop alternate-factor logins. The flaw also affects accounts locked for administrative reasons such as offboarding or policy violations.

Root Cause

The root cause is missing state validation in the authenticator implementations for Magic Link and Passkey. The authentication handlers verify possession of the token or credential but do not check the accountLocked claim before completing the login. Password-based authenticators perform this check correctly, which is why only the alternate methods are affected.

Attack Vector

The attack is network-reachable and requires no privileges or user interaction. An attacker who previously obtained a Magic Link via email interception, phishing, or token reuse can authenticate after the account has been locked. An attacker who registered a passkey before the lock event can authenticate using that credential despite the lock. Exploitation does not require any code execution; the attacker uses the standard authentication endpoints exposed by the WSO2 deployment.

No verified public proof-of-concept code is available. See the WSO2 advisory for technical details.

Detection Methods for CVE-2025-10908

Indicators of Compromise

Successful authentication events for users whose accountLocked attribute is true
Login activity via MagicLinkAuthenticator or FIDOAuthenticator immediately following an account lock event
Session creation for accounts that have exceeded the configured failed-login threshold
Access to protected applications from users that the SOC has manually disabled

Detection Strategies

Correlate WSO2 Identity Server audit logs for LOGIN_SUCCESS events against the user store accountLocked attribute and flag mismatches
Alert when a passkey or Magic Link authentication succeeds within a short window after an ACCOUNT_LOCK event for the same user
Baseline the ratio of password vs. Magic Link / Passkey logins per user and alert on anomalous spikes in alternate-method use

Monitoring Recommendations

Forward WSO2 Identity Server authentication, audit, and admin logs to a centralized SIEM
Enable verbose logging on the org.wso2.carbon.identity.application.authentication.framework package
Monitor administrative changes to user account lock state and reconcile against subsequent login activity

How to Mitigate CVE-2025-10908

Immediate Actions Required

Apply the patches referenced in WSO2 Security Advisory WSO2-2025-4388 for your specific product versions
Audit currently locked accounts for unexpected successful logins through Magic Link or Passkey since deployment
Invalidate active sessions and outstanding Magic Link tokens for any locked accounts
Force re-registration of passkeys for accounts that were locked due to confirmed compromise

Patch Information

WSO2 has published fixes in the WUM (WSO2 Update Manager) and U2 (Updates 2.0) update channels. Customers should apply the updates listed in advisory WSO2-2025-4388 for their product and version. The patch adds account state validation to the Magic Link and Passkey authenticator handlers so locked accounts are rejected before session issuance.

Workarounds

Disable Magic Link authentication in the Identity Server console until the patch is applied
Disable Passkey (FIDO2) authentication for sensitive applications until the patch is applied
Enforce password-based authentication as the only enabled factor for privileged users
Implement a custom authentication script that explicitly checks the accountLocked claim before allowing login through any authenticator

bash

# Example: custom adaptive authentication script enforcing lock check
var onLoginRequest = function(context) {
    executeStep(1, {
        onSuccess: function(context) {
            var user = context.steps[1].subject;
            var locked = user.localClaims['http://wso2.org/claims/identity/accountLocked'];
            if (locked === 'true') {
                Log.error('Blocked login for locked account: ' + user.username);
                fail();
            }
        }
    });
};