Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐘
🐘 Packagist
Not in CISA KEV
LOW severity

GHSA-h4fw-6r7f-w494 web-auth/webauthn-framewo…

LOW

GHSA-h4fw-6r7f-w494 is a low-severity (CVSS 2.1) vulnerability in web-auth/webauthn-framework. A fix is available for web-auth/webauthn-framework — see the affected versions and patch details below.

Webauthn has a User Verification Downgrade via Default-Open ClientOverridePolicy

Published
May 7, 2026
Updated
May 7, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of May 7, 2026 · OSV.dev, FIRST.org (EPSS)

Real-World Exposure

1 pkg affected
🐘web-auth/webauthn-framework

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.

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.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐘Packagistweb-auth/webauthn-framework5.3.0&&< 5.3.15.3.1composer require web-auth/webauthn-framework:^5.3.1

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for web-auth/webauthn-framework, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update web-auth/webauthn-framework to 5.3.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-h4fw-6r7f-w494 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-h4fw-6r7f-w494 can be triaged on real exposure rather than presence alone.

Tailored to GHSA-h4fw-6r7f-w494. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## 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
O3 Security · Impact-Aware SCA

Is GHSA-h4fw-6r7f-w494 in your dependencies?

O3 Security finds GHSA-h4fw-6r7f-w494 across Packagist dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.

GHSA-h4fw-6r7f-w494: Low 2.1 severity | O3 Security