The CVSS 7.5 score for this unauthenticated SQL injection is the most analytically significant detail — not because it accurately reflects severity, but because it signals something specific about the exploitation mechanics. A 7.5 for any SQLi, let alone an unauthenticated one, is an outlier. The most parsimonious explanation is that this is a time-based blind injection, where attackers must infer database values through boolean logic gated by database delays. This explains the surprisingly low EPSS (0.00247): automated scanners struggle to reliably confirm blind SQLi, reducing opportunistic exploitation, and targeted exploitation requires crafting tailored payloads for specific hosting environments (MySQL versions, connection latency, WAF interference).
However, the low CVSS score likely obscures the actual blast radius. WordPress plugins routinely request and receive broad database privileges because the permission model is coarse. A SQLi in a plugin often has the same blast radius as SQLi in core: you're reading users, passwords, session tokens, and whatever postmeta or custom table data the plugin touches. The 60-90 second per query extraction time that explains the 7.5 conflates exploit speed with damage scope — they're orthogonal. A patient attacker extracting data over hours still gains access to the entire user table if the plugin has access to wp_users, which it almost certainly does.
The more concerning dimension is abandonment. WordPress plugin SQLi CVEs at version 1.x with a CVE filed are frequently in abandoned code — the developer left the project live on the repo, or hasn't touched the vulnerable code path because it was written by a previous contributor or copied from a deprecated pattern. Neither state produces reliable patches. The CVSS 7.5 tells defenders to prioritize, but when the vulnerable code is in the sediment layer — maintained by no one, still executing on thousands of sites — the score is measuring a theoretical remediation timeline that may never materialize.
What should you do? Treat this as a high-severity vulnerability regardless of the 7.5. Verify whether the plugin is actively maintained — if it's abandoned, your remediation path is deinstallation, not waiting for a patch. Check the plugin's database permissions: if it has access to wp_users, treat database compromise as certain if exploitation succeeds. The low EPSS is not a reliable predictor of attacker interest for WordPress plugin vulnerabilities; scanner economics are indiscriminate by design, and these CVEs routinely surface in botnet dwell lists and pentester runbooks years after disclosure.