The CVSS 9.1 score is technically accurate—unauthenticated SQL injection in a WordPress plugin warrants that rating—but it tells you little about what actually matters: the blast radius and the likelihood of recurrence. This plugin is a directory solution, which means the injection almost certainly targets custom database tables WordPress doesn't manage, sitting outside the sanitization patterns the plugin likely uses for core tables. The version boundary 'before 1.5.5' is narrow, which tells you the fix was surgical—a single parameter sanitization rather than a query architecture overhaul. That's the real signal. Surgical fixes in WordPress plugin CVEs have a documented pattern: they close the reported door while leaving adjacent code paths on the same custom tables vulnerable. If you patch this CVE, treat 1.5.5 as a starting point for your own audit, not an all-clear. Check the changelog—if it reads 'security hardening' without referencing broader code review, assume the underlying query architecture wasn't touched. More importantly: directory plugins are integration hubs. They touch email marketing, payment processing, geolocation APIs, and third-party sync workflows. The SQL injection reads whatever your database user can reach, not just directory listings. That means you're not containing a data leak—you're watching a potential pivot point. Review what credentials this plugin's database user has been granted. If it's broader than what's needed for directory functionality, that's your immediate remediation priority. Finally, watch for time-based blind injection. Directory plugins process high-volume search queries, so extraction traffic blends into normal usage patterns. An attacker running systematic extraction over hours isn't noise—they're just another heavy search user. Monitor for atypical query volumes from single IPs and for search operators or wildcards in search fields, which are the likely vectors for this injection.