java-webauthn-server EUVD-2026-30211

The attacker must (1) already possess a valid registered WebAuthn credential accepted by the same relying party (reflected in CVSS PR:L), (2) reach the relying party's second-factor / assertion endpoint over the network, and (3) drive a finishAssertion call where StartAssertionOptions.username names the victim while the assertion is signed by the attacker's own credential. Exploitation is limited to deployments using webauthn-server-core 2.8.0 or 2.8.1 specifically in the second-factor (assertion) flow; passwordless/usernameless flows and 2.8.2+ are not in scope, no user interaction is required from the victim (UI:N), and the CVSS AC:H reflects that the attacker must control the assertion ceremony with a mismatched credential rather than simply replaying traffic.

Signals are mixed and require careful interpretation. CVSS 7.5 with vector AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H indicates a network-reachable but high-complexity attack requiring low privileges (the attacker must already possess a valid registered WebAuthn credential on the target deployment), with total impact on confidentiality, integrity, and availability of the impersonated account. EPSS is extremely low (0.01%, 3rd percentile) and SSVC reports Exploitation: none and Automatable: no, consistent with the AC:H rating - exploitation is not trivial and no public exploit identified at time of analysis. However, SSVC Technical Impact is rated 'total' and the vendor advisory (YSA-2026-02) confirms the bypass enables full account impersonation, so for any deployment relying on this library as the sole second factor the real-world risk to individual high-value accounts is significant even if mass exploitation is unlikely. This is a targeted-impersonation risk, not a worm-style mass-compromise risk.

An attacker who has enrolled their own legitimate WebAuthn credential (for example as a low-privilege user on a SaaS tenant) initiates a second-factor login claiming the victim's username, completes the assertion with their own authenticator, and the relying party - using vulnerable webauthn-server-core 2.8.0/2.8.1 - returns success because the credential-to-username binding is not verified. The attacker is then logged in as the victim. No public exploit identified at time of analysis, but the vendor release notes describe the exact mismatched-credential condition needed to reproduce.