ProfilePress CVE-2026-92536

Exploitation requires the ProfilePress Member Directory feature to be in use and rendered, since the leak occurs through its per-row user rebinding when attacker-supplied base64 [pp-custom-html] shortcodes invoke [profile-email], [profile-username], and [profile-date-registered]. The default path requires subscriber-level (or higher) authentication, which is low-friction to obtain. Exploitation escalates to fully unauthenticated ONLY when the WordPress core 'users_can_register' option is enabled, in which case the attacker injects the split shortcode fragments via the plugin's registration handler through the reg_nickname and reg_bio fields, which are processed without a nonce requirement. Limiting factors: if the Member Directory is not deployed, or if self-registration is disabled and no low-privilege accounts exist, the realistic attack surface is substantially reduced; leaked data is limited to emails, login names, and registration dates rather than passwords or full account takeover.

The input CVSS base score is 8.8 (High) with vector AV:N/AC:L/PR:L/UI:N/C:H/I:H/A:H, but this score is internally inconsistent with the described impact: the vulnerability is a Sensitive Information Exposure that lets an attacker read other users' email addresses, login names, and registration dates - a confidentiality-only effect. The I:H and A:H ratings in the supplied vector therefore appear inflated, and the CWE-94 (Code Injection) classification plus the 'RCE' tag overstate the realized impact, which is data leakage via shortcode injection rather than arbitrary code execution. No EPSS score was provided, the CVE is NOT on the CISA KEV list, and no public proof-of-concept was supplied, so there is no public exploit identified at time of analysis. The practical risk is moderate: exploitation requires only subscriber-level access (PR:L), which is trivial to obtain on any site allowing self-registration, and drops to fully unauthenticated when the WordPress users_can_register option is enabled, because the plugin's registration handler processes reg_nickname and reg_bio without a nonce. Realistically this is a credible privacy/account-enumeration issue (useful for phishing and credential-stuffing target lists) rather than a server-compromise event; treat the headline 8.8 with caution and prioritize based on whether the Member Directory feature is deployed and whether open registration is enabled.

An attacker registers a free subscriber account (or, if open registration is enabled, acts unauthenticated) and submits attacker-controlled base64 payloads containing split [pp-custom-html] shortcode fragments that invoke [profile-email], [profile-username], and [profile-date-registered]. When the Member Directory renders, its per-row user rebinding resolves these tags against other users, leaking their emails, login names, and registration dates. No public exploit code is known, but the technique is straightforward given the detailed description.