{"answers":{"affected":"2 open source packages ship an affected version, including web-auth/webauthn-framework.","exploited":"There is no known exploitation of GHSA-h4fw-6r7f-w494 in the wild and no public exploit code.","fix":"Upgrade web-auth/webauthn-framework to 5.3.1 or later.","what":"GHSA-h4fw-6r7f-w494 is a vulnerability in web-auth/webauthn-framework, published on 7 May 2026. Any signed-in user can exploit it over the network, and only if a user opens a file or follows a link."},"fix_prompt":"Check this codebase for GHSA-h4fw-6r7f-w494 and fix it if it is affected.\n\nWhat it is: GHSA-h4fw-6r7f-w494 is a vulnerability in web-auth/webauthn-framework, published on 7 May 2026. Any signed-in user can exploit it over the network, and only if a user opens a file or follows a link.\nExploitation: There is no known exploitation of GHSA-h4fw-6r7f-w494 in the wild and no public exploit code.\n\nAffected packages and fixed versions:\n- web-auth/webauthn-framework (Packagist): affected from 5.3.0; fixed in 5.3.1\n- web-auth/webauthn-framework (Packagist): affected from 5.3.0; fixed in 5.3.1\n\nTask:\n1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.\n2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.\n3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.\n4. Run the tests and summarise what changed and why.\n5. If nothing in the project is affected, say so and change nothing.\n\nReference: https://insights.sbomify.com/GHSA-h4fw-6r7f-w494/ (Markdown: https://insights.sbomify.com/GHSA-h4fw-6r7f-w494/index.md)","id":"GHSA-h4fw-6r7f-w494","markdown":"https://insights.sbomify.com/GHSA-h4fw-6r7f-w494/index.md","name":"GHSA-h4fw-6r7f-w494","record":{"aliases":[],"analysis":{"component_type":"library","fix_type":"upgrade","impacts":["security_bypass"],"network_reachable":"yes","non_default_config":false,"product_category":"Symfony Webauthn bundle","requires_auth":"low_privilege","summary":"Attackers with physical access to a victim's authenticator can bypass user verification requirements in the Symfony Webauthn bundle by manipulating client override policies.","user_interaction":"required","vuln_class":"security_feature_bypass"},"analysis_generated_by":"qwen3.8-flash-next","assigner":null,"cpe":[],"cvss":{"score":null,"severity":null,"source":null,"vector":null,"version":null},"cwes":[],"description":"## 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-\u003eisUserVerified()) {\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.","ecosystems":["Packagist"],"exploits":{"exploitdb":null,"first_seen":null,"github_poc":null,"max_poc_stars":null,"metasploit":null,"nuclei":null,"refs":[],"tier":null},"has_fix":true,"headline":"Webauthn has a User Verification Downgrade via Default-Open ClientOverridePolicy","id":"GHSA-h4fw-6r7f-w494","indexable":true,"kev":null,"kind":"advisory","links":{"ecosystem":"Packagist","product":null,"products":[],"type":"security_feature_bypass","year":"2026"},"n_packages":2,"n_references":null,"packages":[{"ecosystem":"Packagist","fixed":["5.3.1"],"introduced":["5.3.0"],"last_affected":[],"package":"web-auth/webauthn-framework","purl":null,"source":"GHSA-h4fw-6r7f-w494"},{"ecosystem":"Packagist","fixed":["5.3.1"],"introduced":["5.3.0"],"last_affected":[],"package":"web-auth/webauthn-framework","purl":"pkg:composer/web-auth/webauthn-framework","source":"GHSA-h4fw-6r7f-w494"}],"products":null,"published":"2026-05-07","related":[],"sources":[{"class":"attribution","licence":"CC BY 4.0","name":"GitHub Advisory Database","prefix":"GHSA"}],"ssvc":{"automatable":null,"exploitation":null,"technical_impact":null},"state":null,"updated":null,"vendors":null},"summary":"Attackers with physical access to a victim's authenticator can bypass user verification requirements in the Symfony Webauthn bundle by manipulating client override policies.","url":"https://insights.sbomify.com/GHSA-h4fw-6r7f-w494/"}