WPCOM Member CVE-2026-104803

Exploitation requires that the target site has at least one social login provider configured, since that is what registers the vulnerable social-login callback on the WordPress init hook; without a configured provider the handler is inactive. It further requires that the attacker knows or can enumerate the victim account's bound social identifier (openid or unionid) - admin takeover specifically requires knowing the administrator's bound openid. These are the key limiting factors: the attack is unauthenticated and needs no user interaction, but it is gated by the non-universal social-provider configuration and by prior knowledge/discoverability of the bound openid value.

This is a genuine high-priority vulnerability, not merely a high-CVSS paper risk. The NVD CVSS 3.1 vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, 9.8) describes a network-reachable, unauthenticated flaw with full confidentiality/integrity/availability impact, and an authentication-bypass-to-administrator outcome is among the most consequential WordPress failure modes. However, the signals are not fully aligned: the description itself imposes two real preconditions the CVSS AC:L rating does not capture - the target must have at least one social login provider configured (which activates the vulnerable init handler), and the attacker must know or be able to enumerate the victim account's bound openid/unionid. These are meaningful limiters, which is why my independent assessment lowers attack complexity to AC:H. No EPSS score, no CISA KEV listing, and no public POC were provided in the input, so exploitation likelihood cannot be quantified; per the data, there is no public exploit identified at time of analysis. The vendor identifier (whyun/wpcom_member) and the WeChat-oriented 'weapp_new_user()' logic indicate a niche, predominantly Chinese-market plugin, so real-world blast radius is constrained by low deployment prevalence rather than by exploit difficulty. Net: treat as urgent for any site actually running this plugin with social login enabled, but overall fleet-wide risk is tempered by limited prevalence and the openid-knowledge prerequisite.

On a WordPress site running WPCOM Member <=1.7.27 with at least one social provider configured, an unauthenticated attacker who knows an administrator's bound openid sends a crafted GET request to the social-login callback that writes an attacker-controlled entry into the global (underscore-prefixed) session namespace. A second GET request triggers weapp_new_user() to read that forged entry, resolve the openid to the bound admin account, and call wp_set_auth_cookie(), handing the attacker an authenticated admin session. No public exploit code was identified at time of analysis, but the flaw is network-reachable with low interaction.