CVE-2026-76793

CVE-2026-76793 is an authentication bypass in a Firebase Auth WordPress plugin. The vulnerability: the plugin accepts the email claim from a Firebase ID token and links or creates a local WordPress account without checking whether Firebase has verified that email address. An attacker who obtains a valid Firebase token for an unverified email address can authenticate as that user to the WordPress site. The attack works because Firebase tokens include an `email_verified` boolean claim, and the plugin ignores it. The fix is a single-line check: verify that `email_verified` is `true` before trusting the email claim for account matching or session issuance. If your plugin handles Firebase authentication, audit the token handling code for exactly this condition. The pattern to search for is any code that extracts the `email` or `email_verified` claim from the Firebase token and passes it to `wp_set_auth_cookie()`, `wp_signon()`, or user creation/linking functions without a verification gate. Three factors make this more than a one-off coding mistake. First, Firebase's own documentation and quickstart examples often show token extraction without demonstrating the verification check — developers copying from official tutorials inherit the vulnerable pattern. Second, this specific attack vector was documented and assigned CVEs as early as 2019 (CVE-2019-12348, CVE-2021-27891), making it a known vulnerability class rather than a novel finding. Third, the WordPress plugin ecosystem operates at a remove from security-advisory feeds — developers building authentication integrations often learn from Firebase docs and WordPress hooks, not from CVE databases, meaning the institutional knowledge about this class of bypass never reached the developers who kept re-implementing it. The systemic lesson: authentication libraries that surface identity claims without making verification status visually or structurally prominent create a trust boundary that developers naturally assume is handled upstream. It's not negligence — it's a documentation and tooling gap that makes the insecure path the path of least resistance. When you integrate any federated identity provider, explicitly validate the provider's verification status before linking claims to local accounts, regardless of what the quickstart examples show.

Reviewed through automated stages and approved by a human before publication.