Boost Plugin EUVD-2026-31044

The vulnerable Boost plugin from PixelYourSite must be installed and active on a WordPress site at version 2.0.3 or earlier, and the attacker must be able to reach the HTTP(S) endpoint that accepts the 'current_url' or 'user_name' parameters (default for any internet-facing WordPress install). No authentication, no user interaction, and no non-default configuration are required - CVSS PR:N/UI:N confirms this. Limiting factors: the injection is time-based blind (C:H/I:N/A:N), so exploitation is bandwidth- and latency-sensitive and slower than UNION-based extraction, and a WAF in front of the site or aggressive rate limiting on the affected endpoints would materially slow or block automated exfiltration.

The CVSS vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N is internally consistent with the description: network-reachable, low-complexity, no authentication, no user interaction, and confidentiality-only impact (which fits time-based blind exfiltration rather than data modification or DoS). Real-world risk is meaningful because WordPress plugins are mass-scanned by automated tooling and Wordfence's disclosure typically precedes opportunistic exploitation, but no EPSS score, KEV listing, or public PoC was provided in the input, suggesting the threat is currently latent rather than active. SSVC-style assessment: exploitation status is 'none' (no public exploit identified), automatable is likely 'yes' given the unauthenticated network vector and parameterized injection points, and technical impact is 'partial' (confidentiality only). Net priority: high for any site running Boost <=2.0.3, but not an emergency on the order of an actively exploited KEV entry.

An unauthenticated attacker discovers a WordPress site running Boost <=2.0.3 via plugin fingerprinting and sends crafted HTTP requests injecting time-based SQL payloads (e.g., a SLEEP(5) conditional) into the 'current_url' or 'user_name' parameter of a Boost endpoint. By measuring response delays, the attacker iteratively exfiltrates the contents of wp_users (including password hashes) and wp_options (including secret keys/API tokens), enabling subsequent credential cracking or pivoting. No public exploit identified at time of analysis, but the injection pattern is trivially reproducible from the description.