SPS-Suite EUVD-2026-88095

Exploitation requires the plugin's static-page search feature to be explicitly enabled - this is the concrete gating condition stated in the description and the reason for AC:H. The target must run SPS-Suite version ≤1.4.0. No authentication is required (PR:N) and no user interaction is needed (UI:N), so any anonymous visitor can submit the malicious search input over the network once the feature is active. The primary limiting factor is that the vulnerable search feature is not necessarily enabled by default, which narrows the exposed population; SSVC further rates the attack as not automatable.

Signals are mixed and point to a real-but-conditional issue rather than an urgent priority. The CVSS 3.1 vector (6.8, AV:N/AC:H/PR:N/UI:N/S:C/C:H) shows an unauthenticated, network-reachable SQL injection with high confidentiality impact, but AC:H flags a meaningful precondition - the static-page search feature must be enabled - which is corroborated by the description ('when its static-page search feature is enabled'). This is reinforced by CISA SSVC, which rates Exploitation as 'none' (no observed active exploitation), Automatable as 'no', and Technical Impact as 'partial' - a decidedly non-emergency SSVC profile. A public exploit exists via WPScan, but POC availability is distinct from active exploitation: there is no KEV listing and no EPSS score provided, so widespread automated abuse is not evidenced. Net assessment: a legitimate unauthenticated SQLi worth patching, but its non-default feature dependency, AC:H, and 'not automatable' SSVC rating make it a moderate rather than critical real-world priority. Note a minor inconsistency to verify: the vendor set S:C (scope change) with C:H/I:N/A:N, whereas a search-driven SELECT-based SQLi typically maps to S:U - the scope-change choice is debatable.

An unauthenticated attacker locates a WordPress site running SPS-Suite ≤1.4.0 with the static-page search feature enabled and submits a crafted search query that is concatenated unsanitized into a backend SQL statement. By manipulating the query, the attacker extracts sensitive database contents such as user records or credential hashes. A public exploit/technical writeup is available from WPScan, lowering the effort to reproduce.