WholesaleX CVE-2026-111955

Exploitation requires the WholesaleX plugin (version before 3.0.9) deployed on WordPress with the account/registration workflow that leaves new accounts in a pending state awaiting administrator approval before login. The specific logic flaw is that the plugin does not verify a stored account confirmation code has actually been set before comparing it to the attacker-supplied value, so a request can satisfy the comparison against the unset/empty stored value. The main limiting factors are: the site must use WholesaleX's admin-approval registration flow, and a pending (unactivated) target account must exist to be activated. Per CVSS AV:N/AC:L/PR:N/UI:N, no authentication or user interaction is needed and it is remotely reachable against the default approval configuration.

This is a moderate-priority access-control flaw whose signals are largely consistent. The provided CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N) describes a remotely reachable, low-complexity, unauthenticated issue, and the SSVC framework agrees it is Automatable:yes with partial technical impact - meaning it can be scripted but yields only limited (C:L/I:L) impact rather than full compromise. SSVC Exploitation is rated 'none' (no active exploitation observed), which is NOT contradicted by the separately reported public POC: a publicly available exploit code exists, but POC availability is distinct from confirmed in-the-wild use. No EPSS score was supplied, so widespread-exploitation probability cannot be quantified from this data. There is no CISA KEV listing. Net: a genuine, easily automated authentication-bypass bug worth patching promptly on affected WordPress sites, but the impact ceiling is limited to activating pending accounts / bypassing admin approval (no code execution, no confidentiality of sensitive data beyond account access), so it is a real but mid-tier priority rather than a critical emergency. The CVSS 6.5 (Medium) rating aligns with the limited scope.

A WholesaleX site is configured so new (e.g. wholesale/B2B) registrations remain pending until an administrator manually approves them. An unauthenticated attacker who has registered or knows of a pending account sends a crafted account-activation request; because the plugin compares the supplied confirmation code without first verifying a stored code was ever set, the check passes (e.g. against an empty/unset value) and the pending account is activated, bypassing the required admin approval. A public POC for this flaw is available, lowering the barrier to exploitation.