CVE-2026-30964: 
PHP vulnerability analysis and mitigation

CVE-2026-30964 is an origin validation error (CWE-346) in the Spomky-Labs WebAuthn Framework (web-auth/webauthn-framework) and related packages that allows attackers to bypass exact-origin validation required by the WebAuthn Level 2 specification. The vulnerability affects web-auth/webauthn-framework, web-auth/webauthn-lib, and web-auth/webauthn-symfony-bundle versions >= 5.2.0 and < 5.2.4. It was published on March 8, 2026, and patched in version 5.2.4. The CVSS v3.1 base score is 5.4 (Medium) (Github Advisory, GitHub Advisory DB).

The root cause lies in the CheckAllowedOrigins class (CheckAllowedOrigins.php), which incorrectly reduces both configured allowed origins and the incoming clientDataJSON.origin to their host component only using PHP's parse_url(), discarding scheme and port information. Specifically, the code stored each allowed origin as parse_url($allowedOrigin)['host'] ?? $allowedOrigin and compared it against the similarly reduced client origin — meaning https://login.example.com:8443 and https://login.example.com:9443 were treated as identical (both reduced to login.example.com). This violates the WebAuthn Level 2 specification (§7.1 and §7.2), which requires verifying that C.origin matches the RP's full origin (scheme + host + port). In non-browser or custom clients, scheme confusion for URL-like entries is also exploitable (Github Advisory, Patch Commit).

Successful exploitation allows an unauthenticated attacker to forge WebAuthn authentication or registration responses from a different-port or different-scheme origin that shares the same hostname as a configured allowed origin, effectively bypassing the authentication mechanism. This results in low confidentiality and low integrity impact — an attacker could authenticate as a legitimate user or register a malicious credential, potentially enabling unauthorized account access or privilege escalation. Availability is not impacted, and the scope is unchanged, but the authentication bypass undermines the core security guarantee of WebAuthn-based passwordless or MFA flows (Github Advisory, GitHub Advisory DB).

A proof-of-concept exploit is publicly documented in the GitHub Security Advisory, demonstrating the bypass with a specific YAML configuration and a crafted clientDataJSON.origin value (e.g., sending https://login.example.com:9443 when only https://login.example.com:8443 is allowed). No in-the-wild exploitation has been reported as of the time of this report. The vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.017% (4th percentile), indicating a low probability of near-term exploitation (Github Advisory, GitHub Advisory DB).

1. Identify a vulnerable deployment: Locate a web application using web-auth/webauthn-framework, web-auth/webauthn-lib, or web-auth/webauthn-symfony-bundle versions >= 5.2.0 and < 5.2.4 with allowed_origins configured (e.g., https://login.example.com:8443).
2. Craft a malicious origin: Prepare a WebAuthn registration or authentication response where clientDataJSON.origin is set to a different-port variant of the allowed origin (e.g., https://login.example.com:9443) or a different-scheme variant (e.g., http://login.example.com:8443) in non-browser clients.
3. Submit the crafted response: Send the registration or authentication response with the manipulated clientDataJSON.origin to the vulnerable server endpoint. User interaction is required (the victim must initiate a WebAuthn ceremony, e.g., by visiting a malicious page that triggers the flow).
4. Bypass origin validation: The server's CheckAllowedOrigins reduces both the configured origin and the submitted origin to their host component (login.example.com), finds a match, and returns early — accepting the response without enforcing scheme or port constraints.
5. Achieve authentication bypass: The forged credential is accepted, allowing the attacker to authenticate as the targeted user or register a malicious authenticator credential (Github Advisory).

• Logs: WebAuthn ceremony completions (registration or authentication) originating from unexpected ports or schemes on the same hostname as a configured allowed origin (e.g., requests from https://login.example.com:9443 when only :8443 is configured).
• Application Logs: Successful WebAuthn authentications or registrations from origins not matching the exact configured allowed_origins values — review server-side logs for clientDataJSON.origin values that differ in port or scheme from the configured list.
• Network: Unexpected WebAuthn ceremony requests (POST to /webauthn/ or equivalent endpoints) from origins with non-standard ports for the application's domain.
• Credential Store: Newly registered WebAuthn credentials associated with user accounts that the legitimate user did not initiate, which may indicate unauthorized credential registration (Github Advisory).

Upgrade web-auth/webauthn-framework, web-auth/webauthn-lib, and web-auth/webauthn-symfony-bundle to version 5.2.4 or later. The fix rewrites CheckAllowedOrigins to perform full origin comparison (scheme + host + port) as required by the WebAuthn Level 2 spec, with default port normalization (443 for HTTPS, 80 for HTTP). Origins configured without a scheme retain host-only matching for backward compatibility. No configuration-based workaround is available for unpatched versions; upgrading is the only remediation. After upgrading, review allowed_origins configuration to ensure all entries include explicit scheme and port where strict origin enforcement is required (Github Advisory, Patch Commit, Red Hat Bugzilla).

The vulnerability was reported by researcher dorakemon and published by the maintainer Spomky on March 8, 2026. Red Hat tracked the issue via Bugzilla (Bug 2446118) and classified it as medium severity. No significant broader media coverage or notable community debate has been identified beyond the standard advisory and patch release (Github Advisory, Red Hat Bugzilla).