Persistent Login CVE-2026-18752

Two conditions must hold simultaneously: the attacking user must possess a valid WordPress account at subscriber level or above (any registered role satisfies this - PR:L per CVSS vector), and the plugin's Login History feature must be explicitly enabled in the site configuration. Sites where Login History is disabled are not reachable by this attack regardless of plugin version installed. No administrative or editor-level privilege is required - subscriber is the minimum threshold. No victim interaction is required (UI:N). The attack is conducted remotely over HTTP (AV:N) by sending a crafted cookie alongside any authenticated request. Attack complexity is low (AC:L) once both prerequisite conditions are satisfied.

The CVSS 6.5 score reflects a network-accessible attack requiring low-privilege authentication (PR:L) with no user interaction, yielding high confidentiality impact and zero integrity or availability impact - accurately characterizing a read-only SQL exfiltration primitive. The absence of EPSS data and KEV listing limits precise exploitation-probability estimation, but both gaps tilt risk assessment toward the lower end of urgency absent other signals. The decisive risk-limiting factor is the Login History feature gate: sites that have never enabled this feature are wholly unexploitable regardless of plugin version. Where Login History is active and subscriber-level registration is open - common on membership sites, WooCommerce stores, or LMS installations - the attacker class is broad and the data at risk (WordPress user table including hashed passwords and emails) is sensitive. Even a mid-sized operator running an open-registration WordPress site should treat this as an urgent remediation when the Login History feature is in use. The overall real-world priority is moderate-to-high for the affected deployment subset, but effectively zero for the majority of sites where Login History is disabled.

An attacker registers or already holds a subscriber-level WordPress account on a target site with Login History enabled, then submits an authenticated HTTP request bearing a wppl_device_id cookie containing appended SQL syntax such as a UNION SELECT or boolean-blind payload. The Login History class processes the cookie without sanitization, executing the injected SQL against the WordPress database, and the attacker retrieves user credentials, emails, or other sensitive records. No public exploit code has been identified at time of analysis.