CVE-2026-104803 in WPCOM Member Plugin
Summary
by MITRE • 10/10/2026
The WPCOM Member plugin for WordPress is vulnerable to Authentication Bypass in all versions up to, and including, 1.7.27 via the `uuid` and `code` parameters of the social-login callback handler registered on the `init` hook. The vulnerability exists because the `login` function's social-login flow performs no nonce validation, no OAuth state verification, and no per-visitor namespace isolation in the session store, allowing an unauthenticated attacker to issue a crafted GET request that writes an attacker-named, attacker-valued entry into the global session namespace (bypassing the per-visitor prefix by prepending an underscore), then issue a second GET request triggering `weapp_new_user()` to read that forged entry and resolve the attacker-supplied `openid` value to a bound WordPress account before `wp_set_auth_cookie()` establishes a fully authenticated session. This makes it possible for unauthenticated attackers to log in as any WordPress user — including administrators — whose bound social provider identifier (openid/unionid) is known or discoverable. Successful exploitation requires that the target site has at least one social provider configured (which activates the vulnerable handler) and that the attacker knows or can enumerate the victim account's bound openid or unionid.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/10/2026
The WPCOM Member plugin for WordPress, specifically in versions up to 1.7.27, contains a critical authentication bypass vulnerability within its social login callback handler. This flaw is triggered via the uuid and code parameters during the initialization phase of the application lifecycle. The core technical deficiency lies in the absence of fundamental security controls typically required for OAuth-based authentication flows. Specifically, the implementation fails to validate nonces, does not verify OAuth state parameters, and lacks proper per-visitor namespace isolation within its session storage mechanism. These omissions create a pathway for unauthenticated attackers to manipulate the server-side session data directly, effectively circumventing the intended authentication checks that should occur before user identity is established.
The exploitation of this vulnerability relies on a two-step process involving crafted HTTP GET requests targeting the social-login callback endpoint. In the first step, an attacker submits a request containing specific uuid and code values designed to write an entry into the global session namespace. By prepending an underscore character to their chosen username or identifier, the attacker bypasses the per-visitor prefixing logic that is supposed to isolate sessions between different users. This allows the malicious data to be written directly into a shared space accessible by other processes and requests on the server. The second step involves triggering the weapp_new_user function with an additional request that reads this forged session entry. If successful, the system resolves the attacker-supplied openid value against existing WordPress accounts without performing adequate verification of the user's actual identity through the social provider.
The operational impact of this vulnerability is severe, as it allows unauthenticated attackers to log in as any WordPress user whose bound social provider identifier, such as an openid or unionid, is known or can be enumerated by the attacker. This includes high-privilege accounts like administrators, which could lead to complete compromise of the WordPress installation and its associated data. The vulnerability fundamentally undermines the integrity of the authentication system, turning a feature designed for convenience into a vector for unauthorized access. Successful exploitation requires that the target site has at least one social provider configured, as this activates the vulnerable handler code path. Furthermore, the attacker must possess knowledge or be able to discover the victim account's bound openid or unionid value, which may be obtainable through various reconnaissance techniques depending on the specific deployment and data exposure practices of the organization.
From a classification perspective, this vulnerability aligns with CWE-287, Improper Authentication, as it fails to correctly verify identity before granting access. It also relates to CWE-613, Insufficient Session Expiration, due to the manipulation of session state without proper validation or expiration controls inherent in secure OAuth implementations. In terms of attack tactics, this behavior corresponds to ATT&CK technique T1078, Valid Accounts, where attackers use legitimate credentials or identities obtained through other means to gain access. The lack of nonce and state verification also reflects weaknesses associated with CWE-352, Cross-Site Request Forgery (CSRF), although the primary impact here is authentication bypass rather than action execution on behalf of a user.
Mitigation strategies must focus on immediate remediation and long-term security hardening. Administrators should update the WPCOM Member plugin to version 1.7.28 or later, where these issues have been addressed by implementing proper nonce validation, OAuth state verification, and strict per-visitor session namespace isolation. For sites that cannot immediately patch due to compatibility concerns, disabling social login features until an upgrade is possible serves as a temporary workaround. Additionally, organizations should review their access logs for signs of exploitation attempts involving unusual patterns in the uuid or code parameters during login callbacks. Implementing Web Application Firewalls with rules targeting these specific parameter manipulations can provide an additional layer of defense while patching efforts are underway. Regular audits of third-party plugin security and adherence to OWASP guidelines for authentication flows will help prevent similar vulnerabilities in future deployments.