Blocksy Companion Pro EUVD-2026-37589

The target site must have Blocksy Companion Pro installed and activated at any version below 2.1.29, and the vulnerable HTTP endpoint (admin-ajax action or REST route registered by the plugin) must be reachable from the attacker's network position - which is the WordPress default since admin-ajax.php and /wp-json/ are exposed to anonymous users out of the box. No authentication, user interaction, license activation status, or non-default configuration is required (CVSS PR:N/UI:N), and exploitation works against default installations. The only limiting factor identified is the presence of a WAF in front of the site or removal/deactivation of the plugin; the specific affected feature or parameter is not disclosed in the available description and would need to be confirmed from the Patchstack advisory or the 2.1.29 patch diff.

Risk is high in practice: CVSS 9.3 reflects network-reachable, low-complexity exploitation with no privileges and no user interaction (AV:N/AC:L/PR:N/UI:N), which matches the description's 'Unauthenticated' wording - these signals are consistent. The scope-changed confidentiality impact (S:C/C:H) implies an attacker can read arbitrary database content including wp_users password hashes and secret_keys, which often enables full site takeover even though the vector only lists I:N/A:L. EPSS, KEV status, POC availability, and SSVC decision data were not provided in the input, so real-world exploitation pressure cannot be quantitatively confirmed - however, unauthenticated SQLi in commercial WordPress plugins is historically a high-priority target for mass exploitation campaigns once a Patchstack advisory is indexed, so defenders should treat this as urgent regardless of the missing telemetry.

An unauthenticated attacker discovers a site running Blocksy Companion Pro (fingerprintable via the /wp-content/plugins/blocksy-companion-pro/ asset path) and sends a crafted HTTP request to the vulnerable plugin endpoint with a SQL payload in an unsanitized parameter, exfiltrating wp_users password hashes and the WordPress auth secret keys from wp_options via UNION-based or time-based injection. The hashes are cracked offline or the secrets are used to forge a logged-in administrator cookie, after which the attacker uploads a malicious plugin or theme to obtain RCE. No public PoC was identified in the supplied intelligence, but the AC:L/PR:N/UI:N profile makes weaponization straightforward once the vulnerable parameter is reverse-engineered from the 2.1.29 diff.