Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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…
Recommended action: Upgrade to 5.3.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When allowedorigins is configured, CheckAllowedOrigins reduces URL-like values to their host component and accepts on host match alone. This makes exact origin policies impossible to express: scheme and port differences are silently ignored. Details CheckAllowedOrigins stores each configured allowed origin as: and later reduces the received clientDataJSON.origin the same way: If the reduced value matches, the method returns early. As a result, for the normal allowedorigins path, the later HTTPS check is not reached. This differs from WebAuthn Level 2, which requires verifying that C.origin matches the RP's origin (scheme + host + port), separately from verifying that authData.rpIdHash matches the expected RP ID. Affected code: - CheckAllowedOrigins.php Spec references: - §7.1 Registering a New Credential - §7.2 Verifying an Authentication Assertion - CollectedClientData.origin PoC Configuration: Send a registration or authentication response whose clientDataJSON.origin is:…
Recommended action: Upgrade to 5.2.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The ProfileBasedRequestOptionsBuilder method returns allowedCredentials without any credentials if no username was found. Details When WebAuthn is used as the first or only authentication method, an attacker can enumerate usernames based on the absence of the allowedCredentials property in the assertion options response. This allows enumeration of valid or invalid usernames. Proposal how to resolve it: PoC curl https://example.com/assertion/options \ -H 'content-type: application/json' \ --data-raw '{"username":"NotMeRandomUsername123"}' Impact By knowing which usernames are valid, attackers can focus their efforts on a smaller set of potential targets, increasing the efficiency and likelihood of successful attacks.
Recommended action: Upgrade to 4.9.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Webauthn Framework 3.3.x before 3.3.4 has Incorrect Access Control. An attacker that controls a user's system is able to login to a vulnerable service using an attached FIDO2 authenticator without passing a check of the user presence.
Recommended action: Upgrade to 3.3.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.