GitHub Advisoryadvisory · Packagist
GHSA-f7pm-6hr8-7ggm Webauthn Framework: allowed_origins collapses URL-like origins to host-only values, bypassing exact origin validation
MEDIUM
Official page ↗
- Aliases
- CVE-2026-30964
- Ecosystem
- Packagist
- Packages
- web-auth/webauthn-framework, web-auth/webauthn-lib, web-auth/webauthn-symfony-bundle
- Severity
- Moderate
- CVSS vector
- CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N
- Weaknesses
- CWE-346
- Reviewed
- 2026-03-10
Affected packages
• Packagist web-auth/webauthn-framework: >= 5.2.0, < 5.2.4 → fixed in 5.2.4
• Packagist web-auth/webauthn-lib: >= 5.2.0, < 5.2.4 → fixed in 5.2.4
• Packagist web-auth/webauthn-symfony-bundle: >= 5.2.0, < 5.2.4 → fixed in 5.2.4
Description
Summary
When `allowed_origins` 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:
```php
parse_url($allowedOrigin)['host'] ?? $allowedOrigin
```
and later reduces the received `clientDataJSON.origin` the same way:
```php
parse_url($C->origin)['host'] ?? $C->origin
```
If the reduced value matches, the method returns early. As a result, for the normal `allowed_origins` 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:
```yaml
webauthn:
allowed_origins:
• https://login.example.com:8443
allow_subdomains: false
```
Send a registration or authentication response whose `clientDataJSON.origin` is:
```text
https://login.example.com:9443
```
Observed: the response is accepted, because both values are reduced to `login.example.com`.
Expected: the response should be rejected, because `https://login.example.com:8443` and `https://login.example.com:9443` are different origins.
Impact
This is an origin validation error (CWE-346) affecting deployments that use `allowed_origins`. The most practical browser-facing scenario is same-host / different-port origin confusion. In non-browser or custom clients, scheme confusion may also be relevant.
Fix
Fixed in version 5.2.4 by rewriting `CheckAllowedOrigins` to perform full origin comparison (scheme + host + port) as required by the WebAuthn spec:
• Origins configured with a scheme (e.g. `https://example.com:8443`) are now stored and compared as full `scheme://host[:port]` values, with default port normalization (443 for HTTPS, 80 for HTTP).
• Origins configured without a scheme are still matched by host only, for backward compatibility.
• Subdomain matching now also verifies scheme and port consistency.
See commit b4cd9a43.
Mitigation
Upgrade to `web-auth/webauthn-framework` (or `web-auth/webauthn-lib` / `web-auth/webauthn-symfony-bundle`) >= 5.2.4.
Related
Alias · CVE (1)
- CVE-2026-30964 web-auth/webauthn-lib is an open source set of PHP libraries and a Symfony bundle to allow developers to integrate that authentication… vulnerability
Weakness · CWE (1)
- CWE-346 Origin Validation Error weakness
References
- https://github.com/web-auth/webauthn-framework/security/advisories/GHSA-f7pm-6hr8-7ggm web
- https://nvd.nist.gov/vuln/detail/CVE-2026-30964 advisory
- https://github.com/web-auth/webauthn-framework/commit/535cc3c2dcbd9c3dfd5e00a254ad4a984e5e7839 web
- https://github.com/web-auth/webauthn-framework/commit/b4cd9a4394c35fcac6080fd2f84f4f58a30abc01 web
- https://github.com/web-auth/webauthn-framework package