Skip to content

Webauthn has a User Verification Downgrade via Default-Open ClientOverridePolicy

Low severity GitHub Reviewed Published May 2, 2026 in web-auth/webauthn-framework • Updated May 7, 2026

Package

composer web-auth/webauthn-framework (Composer)

Affected versions

>= 5.3.0, < 5.3.1

Patched versions

5.3.1

Description

Summary

In version 5.3.0 of the Symfony bundle, Webauthn\Bundle\Policy\ClientOverridePolicy defaulted to allowing all client overrides, including userVerification. A client could send {"userVerification": "discouraged"} in the assertion or attestation options request to override a server-configured userVerification: required, causing the emitted WebAuthn options to instruct the authenticator to skip user verification. The CheckUserVerification ceremony step then read the same downgraded options and skipped its check.

Affected versions

  • Vulnerable: 5.3.0
  • Patched: 5.3.1

5.3.0 was released on 2026-05-01 and 5.3.1 was published roughly 18 hours later, on 2026-05-02. Practical exposure window was minimal.

Note on earlier 5.x versions

Versions 5.0.0 to 5.2.x did not ship ClientOverridePolicy (introduced in 5.3.0), so the exact code path described above does not apply. However, on those versions the ProfileBasedRequestOptionsBuilder and ProfileBasedCreationOptionsBuilder already passed the client-supplied userVerification value directly to the options factory, where the profile value is only applied via ??=. The functional outcome (a client can downgrade userVerification) is the same. The recommended mitigation (see below) applies regardless of the version, and users on 5.0.x – 5.2.x are encouraged to upgrade to 5.3.1 or later.

Severity

This is a defense-in-depth issue rather than a primitive that grants authentication on its own:

  • The attacker must already possess the victim's authenticator (a stolen security key, an unlocked device). Without that, the downgrade is inconsequential.
  • The framework exposes the actual UV outcome on the returned authenticator data (AuthenticatorData::isUserVerified()). Applications that gate sensitive operations on this flag — as documented — remain protected even on the vulnerable version.

Mitigation

Applications gating sensitive operations on user verification MUST re-check the UV flag on the returned authenticator data after a
successful ceremony, regardless of what was requested in the options:

if (! $authenticatorData->isUserVerified()) {
    throw new AccessDeniedHttpException('User verification is required.');
}

This is the authoritative signal that user verification actually occurred. The hardened default in 5.3.1 closes the implicit profile-bypass; the application-level check remains the recommended defense in depth and is now documented explicitly in the
User Verification guide.

Fix

ClientOverridePolicy::canOverride() now defaults to false instead of true. The Symfony bundle DI configuration ships user_verification overrides as disabled by default, with a default allowed_values list that excludes discouraged even when an operator opts in.

Credit

Reported by @offset.

References

@Spomky Spomky published to web-auth/webauthn-framework May 2, 2026
Published to the GitHub Advisory Database May 7, 2026
Reviewed May 7, 2026
Last updated May 7, 2026

Severity

Low

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Physical
Attack complexity
Low
Privileges required
None
User interaction
Required
Scope
Unchanged
Confidentiality
None
Integrity
Low
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:P/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N

EPSS score

Weaknesses

Incorrect Authorization

The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. Learn more on MITRE.

CVE ID

No known CVE

GHSA ID

GHSA-h4fw-6r7f-w494

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.