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
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact Webauthn\SimpleFakeCredentialGenerator is the library-provided default implementation of the FakeCredentialGenerator interface. It returns a stable list of decoy PublicKeyCredentialDescriptor objects for a given username so that an assertion request for an unknown user looks the same as a request for a real one, which mitigates username enumeration. The generator derives the whole decoy list from a single seed: When it is constructed without a secret (its constructor default, $secret = ''), the seed depends only on the username. The username is attacker-chosen and the algorithm is public, so an unauthenticated requester can recompute the exact, byte-for-byte decoy list the server returns for any username. The attacker then compares a probed username's response against the locally computed list and decides whether the account is real or fake, which is precisely the distinction the mechanism is meant to hide. With any non-empty secret the seed becomes a value the attacker cannot…
Recommended action: Upgrade to 5.3.5 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.