{"id":"GHSA-h4fw-6r7f-w494","aliases":[],"url":"https://o3.security/vulnerability/GHSA-h4fw-6r7f-w494","summary":"Webauthn has a User Verification Downgrade via Default-Open ClientOverridePolicy","details":"## Summary\n\nIn 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.\n\n## Affected versions\n\n- **Vulnerable**: 5.3.0\n- **Patched**: 5.3.1\n\n5.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.\n\n## Note on earlier 5.x versions\n\nVersions 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.\n\n## Severity\n\nThis is a **defense-in-depth** issue rather than a primitive that grants authentication on its own:\n\n- The attacker must already possess the victim's authenticator (a stolen security key, an unlocked device). Without that, the downgrade is inconsequential.\n- 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.\n\n## Mitigation\n\nApplications gating sensitive operations on user verification MUST re-check the `UV` flag on the returned authenticator data after a\nsuccessful ceremony, regardless of what was requested in the options:\n\n```php\nif (! $authenticatorData->isUserVerified()) {\n    throw new AccessDeniedHttpException('User verification is required.');\n}\n```\n\nThis 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\n[User Verification](https://webauthn-doc.spomky-labs.com/webauthn-in-a-nutshell/user-verification#checking-the-uv-flag) guide.\n\n## Fix\n\n`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.\n\n## Credit\n\nReported by @offset.","published":"2026-05-07T21:05:33Z","modified":"2026-05-07T21:18:48.987495Z","cvss":{"score":2.1,"severity":"LOW","vector":"CVSS:3.1/AV:P/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N"},"epss":null,"cisaKev":null,"exploitsKnown":0,"affectedPackages":[{"ecosystem":"Packagist","name":"web-auth/webauthn-framework","fixedVersion":"5.3.1"}],"fix":null,"references":[{"type":"WEB","url":"https://github.com/web-auth/webauthn-framework/security/advisories/GHSA-h4fw-6r7f-w494"},{"type":"PACKAGE","url":"https://github.com/web-auth/webauthn-framework"}],"provenance":{"sources":["OSV.dev","FIRST.org (EPSS)"],"lastVerified":"2026-05-07T21:18:48.987495Z"}}