WPBulky CVE-2026-82227

Exploitation strictly requires an authenticated WordPress session with at least Contributor-level role (confirmed by CVSS PR:L). The effective barrier is therefore determined by how the target site manages registration: on sites with open user registration, any internet user can register and potentially obtain Contributor access, making the authentication requirement nearly moot. On sites with closed registration, exploitation is limited to existing Contributor or higher accounts - including insider threats, compromised credentials, or social-engineering attacks targeting those accounts. No special plugin configuration, non-default setting, or specific WordPress version beyond the plugin being installed and active is indicated by available data. Factors that limit exploitation include: closed registration (reduces attacker pool to existing authenticated users), Contributor role not granted by default in closed-registration sites, and absence of a public exploit at time of analysis.

The CVSS base score of 8.5 is broadly consistent with the attack profile: network-accessible, low complexity, no user interaction, but gated behind Contributor-level authentication (PR:L). The Scope:Changed and C:H metrics drive the score upward and are plausible for a read-capable SQL injection in a shared-database WordPress environment. In practice, the effective risk hinges on the site's registration policy - if open registration allows any visitor to self-register as a Contributor or Subscriber, the authentication prerequisite is effectively nullified. Sites with closed registration or tightly controlled Contributor accounts face a lower but non-trivial insider/compromised-account risk. No EPSS data is present in the input; no KEV listing and no known POC constrain the current threat signal, though the well-understood SQL injection class means weaponization requires minimal effort for an attacker with Contributor access.

An attacker self-registers a Contributor account on a WordPress site with open registration and WPBulky ≤ 1.2.2 active, then submits a crafted bulk-edit HTTP POST request containing SQL metacharacters designed to break out of the plugin's query context. The database server executes the injected query and returns sensitive rows - such as WordPress user credentials (bcrypt hashes), private post content, or plugin configuration data - which the attacker harvests to escalate access or sell. No public exploit code has been identified at time of analysis, but the standard UNION- or error-based SQL injection technique is well-documented and trivially applicable once Contributor access is obtained.