WSO2 Identity Server CVE-2025-10908

Exploitation requires that the target WSO2 deployment has the Magic Link authenticator module or the Passkey/FIDO2 authenticator enabled for the affected application, and that the attacker can complete one of those flows for a specific locked account - i.e., access to the mailbox that receives the magic link, or a passkey already registered to that account. The precondition that makes the flaw meaningful is that the account is in a locked state (administratively or via failed-login lockout); against unlocked accounts there is no security gain. Limiting factors: the password-based login path is unaffected, so environments using only password/MFA authenticators are not exposed; exploitation is scoped to accounts whose magic-link channel or passkey the attacker controls, not arbitrary accounts, which is why the impact is rated Low rather than High.

Signals are mostly consistent toward a moderate, non-urgent priority. The NVD CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N, C:L/I:L/A:L, base 7.3) reflects network reachability and low-but-real triple impact, while SSVC scores Exploitation=none, Automatable=yes, Technical Impact=partial - meaning no observed exploitation but the flow could be scripted once a valid factor is held. EPSS is very low (0.03%, 8th percentile) and the CVE is not in CISA KEV, so widespread opportunistic exploitation is unlikely. The important caveat is that PR:N overstates ease: exploitation is not truly unauthenticated in practice because the attacker must already possess a valid magic link (mailbox access) or a registered passkey for the specific locked account - the 'no privileges' rating captures that no interactive password is submitted, not that any anonymous user can walk in. This is best treated as an authentication-control-integrity issue affecting locked accounts, not a mass-exploitable RCE.

A user account is locked after repeated failed password attempts (the intended anti-brute-force response), but the attacker has already compromised the victim's email inbox or holds a previously registered passkey. The attacker requests a magic link (or invokes the passkey flow) and is authenticated straight through despite the lock, gaining access to the application and its data. No public exploit code is identified, and the attack requires possession of the account's magic-link delivery channel or passkey.