# GHSA-h4fw-6r7f-w494: Webauthn has a User Verification Downgrade via Default-Open ClientOverridePolicy

> Attackers with physical access to a victim's authenticator can bypass user verification requirements in the Symfony Webauthn bundle by manipulating client override policies.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Over the internet
- **Victim action needed:** A user has to click or open something
- **Fix available:** Yes
- **Published:** 7 May 2026

## What is GHSA-h4fw-6r7f-w494?

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.

### Official 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:

```php
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](https://webauthn-doc.spomky-labs.com/webauthn-in-a-nutshell/user-verification#checking-the-uv-flag) 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.

## Which versions are affected by GHSA-h4fw-6r7f-w494?

2 open source packages ship an affected version, including web-auth/webauthn-framework.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `web-auth/webauthn-framework` | Packagist | From 5.3.0 | 5.3.1 |
| `web-auth/webauthn-framework` | Packagist | From 5.3.0 | 5.3.1 |

## How do I fix GHSA-h4fw-6r7f-w494?

Upgrade web-auth/webauthn-framework to 5.3.1 or later.

## Is GHSA-h4fw-6r7f-w494 being exploited?

There is no known exploitation of GHSA-h4fw-6r7f-w494 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-h4fw-6r7f-w494 and fix it if it is affected.

What 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.
Exploitation: There is no known exploitation of GHSA-h4fw-6r7f-w494 in the wild and no public exploit code.

Affected packages and fixed versions:
- web-auth/webauthn-framework (Packagist): affected from 5.3.0; fixed in 5.3.1
- web-auth/webauthn-framework (Packagist): affected from 5.3.0; fixed in 5.3.1

Task:
1. 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.
2. 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.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-h4fw-6r7f-w494/ (Markdown: https://insights.sbomify.com/GHSA-h4fw-6r7f-w494/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-h4fw-6r7f-w494

---
From sbomify Insights: https://insights.sbomify.com/GHSA-h4fw-6r7f-w494/
Summaries are generated and may contain mistakes; the official description above is the record.