What is the CVSS score of CVE-2026-46419?

CVE-2026-46419 has a CVSS 3.1 base score of 7.5 (High). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H. EPSS exploitation probability: 0.0%.

Which versions of java-webauthn-server are affected by CVE-2026-46419?

Organizations relying on Yubico java-webauthn-server 2.8.0-2.8.1 for multi-factor authentication face a critical vulnerability that allows attackers to gain unauthorized access to user accounts…. A patch is available.

How to fix or mitigate CVE-2026-46419?

Within 24 hours: Identify all applications and deployments using Yubico webauthn-server-core versions 2.8.0 or 2.8.1; assess scope of impact including number of affected users and sensitivity of protected systems. Within 7 days: Consult Yubico's security advisory to identify the patched version; deploy the updated release to all affected systems. Within 30 days: Conduct comprehensive testing of second-factor authentication workflows to verify that credential validation correctly restricts access to the intended user account only.

java-webauthn-server CVE-2026-46419

EUVD-2026-30211 HIGH

Incorrect Check of Function Return Value (CWE-253)

2026-05-14 mitre

GHSA-wq52-w6cx-5mg2

Information Disclosure Webauthn Server Core

7.5

CVSS 3.1 · NVD

Severity by source

NVD PRIMARY

7.5 HIGH

AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

Primary rating from NVD · only source for this CVE.

CVSS VectorNVD

CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:H/A:H

Attack Vector

Network

Attack Complexity

High

Privileges Required

Low

User Interaction

None

Scope

Unchanged

Confidentiality

High

Integrity

High

Availability

High

Lifecycle Timeline

Source Code Evidence Fetched

Jun 08, 2026 - 08:43 vuln.today

Analysis Generated

Jun 08, 2026 - 08:43 vuln.today

Patch available

May 14, 2026 - 03:01 EUVD

DescriptionCVE.org

Yubico webauthn-server-core (aka java-webauthn-server) 2.8.0 before 2.8.2 incorrectly checks a function's return value in the second factor flow, leading to impersonation.

AnalysisAI

Authentication bypass in Yubico java-webauthn-server (webauthn-server-core) 2.8.0 through 2.8.1 allows an attacker holding any valid registered credential to impersonate other users during the second-factor flow. The flaw stems from an unchecked return value in finishAssertion that accepts a successful authentication result even when the authenticated credential belongs to a different user than the one named in StartAssertionOptions.username. No public exploit identified at time of analysis, and EPSS is very low (0.01%), but CISA SSVC rates the technical impact as total.

Technical ContextAI

java-webauthn-server is Yubico's reference Java implementation of the W3C Web Authentication (WebAuthn) Relying Party API, widely embedded in identity providers and applications that adopt passkeys or FIDO2 second-factor authentication. The bug is classified as CWE-253 (Incorrect Check of Function Return Value): the RelyingParty.finishAssertion and RelyingPartyV2.finishAssertion methods fail to enforce that the credential which actually signed the assertion is owned by the username supplied in StartAssertionOptions, so a mismatched-but-otherwise-valid assertion is treated as a successful login. Affected component per NVD CPE is cpe:2.3:a:yubico:webauthn-server-core, versions 2.8.0 up to but not including 2.8.2.

RemediationAI

Vendor-released patch: 2.8.2 - upgrade the webauthn-server-core (java-webauthn-server) dependency to 2.8.2 or later as published at https://github.com/Yubico/java-webauthn-server/releases/tag/2.8.2 and review the advisory at https://www.yubico.com/support/security-advisories/ysa-2026-02/. Until the upgrade is deployed, the compensating control is to validate, in your own application code immediately after calling finishAssertion, that the returned AssertionResult.getUsername() (or getCredential().getUserHandle()) matches the username originally supplied to startAssertion; reject the authentication if they differ. Operators who cannot patch quickly should also consider temporarily disabling WebAuthn second-factor flows for high-value accounts and falling back to an alternative MFA factor, accepting the UX regression, since logging or alerting alone will not prevent impersonation.