Identifying WordPress Plugin Vulnerabilities Using SearchSploit

When maintaining a WordPress site, we often focus on keeping the core up to date. However, the real risk may lie within third-party plugins. In this post, I’ll demonstrate how to use SearchSploit, a powerful local exploit search tool, to identify vulnerabilities in a WordPress setup — using a real plugin vulnerability as an example.

What is SearchSploit?

SearchSploit is a command-line utility that allows you to search for publicly disclosed exploits and vulnerability information stored in the Exploit-DB. It comes pre-installed on many security-focused Linux distributions like Kali Linux.

Instead of querying an online database, it works offline — allowing for quick lookups of known vulnerabilities based on keywords like software versions, plugins, etc.

Initial Search: WordPress 6.8.1

To start, I ran the following command in the terminal:

searchsploit wordpress 6.8.1

This scanned the local exploit database for any matching vulnerabilities related to this specific WordPress version or associated components.

From this result, one particular plugin caught my attention:

• NEX-Forms plugin (versions < 7.9.7)
• Vulnerability: Authenticated SQL Injection (SQLi)
• Type: Time-based blind injection
• Exploit-DB ID: 51042

---

Exploit Details

According to the advisory, this vulnerability allows an authenticated attacker to execute blind SQL injection via a GET parameter in the plugin’s dashboard page.

Payload Example (GET):

form_id=1 AND (SELECT 4715 FROM (SELECT(SLEEP(5)))nPuJi)

The test can be executed using sqlmap as follows:

sqlmap -r nex_forms_req.txt -p form_id --technique=T --dbms=mysql --level 5 --risk 3

This assumes that the request has been saved (via Burp Suite, for example) as nex_forms_req.txt.

What Can We Learn from This?

• Just because WordPress core is up to date doesn’t mean the system is secure.
• Vulnerabilities often lie in plugins — especially those with admin/dashboard functionality.
• Even authenticated-only vulnerabilities can become dangerous if admin access is compromised via brute force or social engineering.

Defense: How to Stay Protected

To prevent such attacks:

1. Keep plugins updated — especially high-privilege ones.
2. Remove unused plugins completely, not just deactivate them.
3. Use a reliable login security plugin to block brute-force attacks.
   • In my case, I used a lightweight login limiter plugin .
   • Other alternatives include generic brute force blockers or firewall integrations.
4. Limit access to sensitive endpoints using .htaccess or web server configs.
5. Regularly scan your plugins/themes using tools like WPScan and keep an eye on exploit announcements.

---

Final Thoughts

This was a great example of how a known exploit, found via SearchSploit, can be used to proactively assess risk — even if the vulnerability doesn’t affect your current stack. Treat these scans as a prevention tactic, not a reaction.

This post is for educational and awareness purposes only. The examples shown here were conducted on isolated test environments — never use such methods on systems you do not own or have explicit permission to test.