The EPSS score of 0.00231 for this SQL injection in Check & Log Email reflects automated scanner behavior, not actual impact. EPSS trains on mass-exploitation signatures — it doesn't model authenticated admin compromise, session hijacking, or lateral movement between admin accounts. Treat that low score as a measure of scanner irrelevance, not severity.
Here's what makes this specific vulnerability non-trivial: the plugin logs outbound WordPress emails. The admin dashboard shows you "email sent to [email protected]" but not the contents. This SQL injection gives you the actual email bodies — password reset tokens, WooCommerce order confirmations, new user registration data — from every email sent during the vulnerable window. That's not redundant capability; it's lateral exfiltration of communication metadata the WordPress admin interface never surfaces in queryable form.
The privilege requirement isn't a CVSS modifier to dismiss. It's a clue about the developer failure pattern: someone wrote SQL queries assuming admin-context means trusted input. The fix needs actual parameterized queries, not just capability checks. If your remediation is "only admins can reach it," you've missed the point — the code should be safe regardless of who's calling it.
Two threat model adjustments worth making: First, in shared hosting environments, this SQL injection can cross site boundaries through the shared database connection — the blast radius extends beyond the compromised site's data. Second, audit other plugins by this developer. The mental model that produces admin-trusted SQL queries in one plugin typically exists across their entire portfolio.
The temporal dimension is the overlooked factor. The vulnerable period isn't just future risk — it's past exposure. Any admin compromised during that window could have exfiltrated accumulated email logs containing credentials and user data, and the evidence lives in those same database tables, invisible to standard forensic review.