Vulnerable plugins cause more WordPress hacks than almost anything else.

Not weak passwords. Not outdated WordPress core. Plugins.

According to WPScan’s 2025 WordPress Vulnerability Report, plugins account for over 93% of all known WordPress vulnerabilities. That number should scares. You can have the strongest password on the planet, the best hosting money can buy, and a fully updated WordPress core  but a single outdated or poorly coded plugin can hand an attacker the keys to your entire site.

The frustrating part? Most site owners have no idea that vulnerable plugins are sitting in their WordPress dashboards. It  may look fine. It may work fine. But underneath it contains a security flaw that attackers are actively scanning for and exploiting at scale.

This guide walks you through on how to detect vulnerable plugins on your WordPress site, how to fix them correctly, and how to build a system that catches vulnerabilities before attackers do. Every step is practical. Every tool we recommend is real and tested.

Why WordPress Plugins Become Vulnerable

Before we get into detection and fixes, you need to understand what actually makes a plugin vulnerable.Understanding the cause makes you a much smarter decision-maker about which plugins you install and keep.

Unpatched security flaws. Every plugin is code, and all code contains bugs. When a developer discovers a security bug in their plugin or when a security researcher reports one  the developer needs to release a patch quickly. The window between public disclosure and patching is when attacks spike dramatically, because attackers read the same vulnerability databases developers do. Sites running the old version become immediate targets.

Abandoned plugins. The WordPress plugin repository contains over 59,000 plugins. A significant portion of those haven’t been updated in years. When a developer stops maintaining a plugin, security flaws pile up with no one fixing them. WordPress.org marks plugins as “not tested with the latest 3 major releases of WordPress” but it doesn’t remove them, and it doesn’t block you from installing them.

Poorly written code. Some plugins enter the ecosystem with security flaws baked in from the start. Insufficient input validation, weak authentication checks, and improper database query handling are the most common coding mistakes that create exploitable vulnerabilities. These plugins may work perfectly well from a functionality standpoint while being genuinely dangerous from a security standpoint.

Third-party dependencies. Plugins often rely on external libraries and frameworks. When those dependencies contain vulnerabilities, the plugin inherits them even if the plugin developer’s own code is flawless.

Nulled plugins. Pirated versions of premium plugins contain intentional backdoors. Attackers seed them through piracy sites knowing that users won’t scrutinize free versions of paid software. Installing a nulled plugin is not a security risk. It’s a guarantee of compromise.

The Most Common Vulnerability Types in WordPress Plugins

Security researchers who report WordPress plugin vulnerabilities use specific terms to describe what they find. Knowing these terms helps you understand severity when you read a vulnerability report  and helps you communicate clearly with a developer or security professional if you need help.

SQL Injection (SQLi). This happens when a plugin passes user-supplied data directly into a database query without properly cleaning it first. An attacker can manipulate the query to extract data from your database, modify records, or in worst-case scenarios, take over your site entirely. SQL injection vulnerabilities in plugins are consistently among the most severe findings in WordPress security research.

Cross-Site Scripting (XSS). An XSS vulnerability lets an attacker inject malicious JavaScript into pages that other users see. Stored XSS is the more dangerous variant — the malicious script gets saved to your database and executes every time a visitor loads the affected page. Reflected XSS requires the victim to click a specially crafted link. Both are serious, especially on sites with logged-in users.

Cross-Site Request Forgery (CSRF). CSRF tricks a logged-in WordPress user into unknowingly performing actions on your site like changing settings, creating admin accounts, or deleting content by visiting a malicious external page. Plugins that don’t properly verify the source of requests are vulnerable to this attack.

Broken Access Control. This covers situations where a plugin fails to check whether the person making a request actually has permission to do what they’re asking. A subscriber-level user shouldn’t be able to access admin functionality but a plugin with broken access control might allow exactly that.

Remote Code Execution (RCE). The most severe category. An RCE vulnerability lets an attacker execute arbitrary code on your server. This typically gives them full control of your site and potentially other sites on the same server.

File Upload Vulnerabilities. Plugins that allow file uploads without properly validating file types create a path for attackers to upload malicious PHP files and execute them on your server.

How to Detect Vulnerable Plugins on Your WordPress Site

Now let’s get practical. Here are the proven methods to detect vulnerable plugins, starting with the fastest and moving to the most thorough.

Method 1: Use WPScan — The Most Reliable Vulnerability Scanner

WPScan is the gold standard for WordPress vulnerability scanning. Security professionals use it worldwide, and its vulnerability database is the most comprehensive source of WordPress- specific security issues available.

WPScan maintains a dedicated WordPress vulnerability database at wpscan.com that security researchers, plugin developers, and hosting providers all reference. The database tracks vulnerabilities across WordPress core, plugins, and themes with severity ratings, affected versions, and patch information.

Using WPScan via command line:

If you have server access via SSH, you can run WPScan directly against your site:

wpscan --url https://yoursite.com --enumerate p --plugins-detection aggressive

The --enumerate p flag scans for plugins. The --plugins-detection aggressive flag checks installed plugin files against the vulnerability database. Add an API token (free at wpscan.com) to get access to the full vulnerability data:

wpscan --url https://yoursite.com --enumerate p --api-token YOUR_TOKEN_HERE

WPScan will return a list of your installed plugins, their versions, and any known vulnerabilities — along with CVE references and severity scores.

Using WPScan’s online database directly:

You don’t need to run a command-line scan to use WPScan’s data. Go to wpscan.com/plugins, search for any plugin by name, and see every recorded vulnerability for that plugin along with which versions are affected and whether a fix is available.

Make this part of your research process before installing any new plugin.

Method 2: Install a Security Plugin That Scans Continuously

Running WPScan manually is excellent for a point-in-time check, but you need ongoing detection. Security plugins that run continuous vulnerability scanning catch problems automatically and alert you before you’d think to check manually.

Wordfence Security scans your installed plugins and themes against its vulnerability intelligence database. It flags plugins with known vulnerabilities directly in your WordPress dashboard with a clear warning, the severity level, and what action to take. The free version scans weekly. Wordfence Premium scans in real time.

To run a manual scan in Wordfence: go to Wordfence → Scan → Start New Scan. Wordfence checks plugin versions against its database and flags anything with a known issue.

Solid Security (formerly iThemes Security) includes site scanning that checks plugin vulnerabilities. Its Security Dashboard gives you a clear visual overview of your site’s security posture, including outdated and vulnerable plugins.

Patchstack deserves special mention here. It’s a dedicated WordPress security platform not just a plugin — that focuses specifically on virtual patching and vulnerability intelligence. Patchstack monitors your installed plugins continuously, notifies you of new vulnerabilities the moment they’re added to their database, and on paid plans, applies virtual patches automatically before you’ve even had time to update. Security researchers who specialize in WordPress use Patchstack’s database as a primary reference.

Method 3: Check the WordPress Plugin Repository for Update Warnings

The WordPress plugin repository itself gives you visible warning signals , if you know what to look for.

Go to your WordPress dashboard → Plugins → Installed Plugins. Look at each plugin carefully:

A yellow “Update Available” notification means a newer version exists. This isn’t always a security issue, but if you’re behind multiple versions, it increases the probability that you’re missing security patches.

More importantly, go to the plugin’s page on wordpress.org. Look at the “Last Updated” date and the “Tested up to” WordPress version. A plugin that hasn’t been updated in over 12 months and hasn’t been tested with recent WordPress versions is a risk. A plugin untouched for two or more years with no developer activity on the support forums is effectively abandoned.

Method 4: Monitor the CVE Database and WPVulnerabilities

The CVE (Common Vulnerabilities and Exposures) database at cve.mitre.org is the authoritative global database for publicly disclosed security vulnerabilities. WordPress plugin vulnerabilities get CVE IDs assigned to them, which makes it possible to track them independently of any commercial tool.

For a WordPress-specific view of the CVE database, wpvulnerabilities.com aggregates WordPress-related CVEs and presents them in a more readable format. You can search by plugin name and subscribe to email alerts for plugins you use.

The Wordfence Threat Intelligence blog at wordfence.com/blog is also an excellent source of real-time vulnerability disclosures. Wordfence’s research team discovers and responsibly discloses a significant number of WordPress plugin vulnerabilities — their blog posts are detailed and highly readable.

Method 5: Run a Manual Plugin Audit

No automated tool catches everything. Every few months, do a manual audit of every plugin on your site.

Open your Installed Plugins page and ask these questions for each plugin:

Do you still actively use this plugin? Deactivated plugins you’ve forgotten about still exist on your server and can still be exploited. If you’re not using it, delete it.

When was the last update? Sort your plugins by “Last Updated” if your security plugin shows that data, or check each one on wordpress.org individually.

How many active installations does it have? A plugin that’s dropped from 200,000 installations to 20,000 may have had a significant security incident that caused mass deactivation.

Is the plugin closed on wordpress.org? When WordPress.org closes a plugin (removes it from the repository), they do so because of unresolved security issues or other policy violations. If a plugin you use gets closed, treat it as an immediate security incident and replace it.

How to Fix Vulnerable Plugins — The Right Way

Detecting a vulnerability is only half the job. Here’s exactly how to handle each scenario you’ll encounter.

Fix #1: Update the Plugin Immediately

This is the right answer in the vast majority of cases. If a vulnerability has been patched in a newer version, update the plugin now. Don’t wait until your next maintenance window. Don’t wait to see if the update causes any issues. Update it.

The risk of running a known vulnerable plugin for even a few extra hours vastly outweighs the inconvenience of a temporary site issue from an update.

Before updating any plugin on your live site:

Back up your site first. A complete backup — database and files — takes a few minutes and protects you from update-related breakage. Use UpdraftPlus or your host’s backup system to grab a fresh backup immediately before you update.

Then update and test the key functionality of your site. Check your homepage, your contact form, your checkout process if you run WooCommerce. If something breaks, restore from your backup and investigate.

If you manage multiple WordPress sites:

ManageWP and MainWP both let you update plugins across all your sites from a single dashboard. ManageWP also offers Safe Updates — it takes an automatic backup before each update and runs a visual comparison to detect breakage. This is one of the most practical tools available for multi-site managers who need to apply security patches quickly.

Fix #2: Apply a Virtual Patch If You Can’t Update Immediately

Sometimes you can’t update a plugin immediately. Maybe the update broke something in your staging test. Maybe the developer hasn’t released a patch yet and the vulnerability is already public (a situation called a zero-day). Maybe the plugin is custom-built and no update is coming.

A virtual patch sometimes called a WAF rule  blocks exploitation of the vulnerability at the firewall level without touching the plugin code itself. It’s a temporary measure, not a permanent solution, but it buys you time to update safely.

Patchstack’s paid plans apply virtual patches automatically for WordPress plugin vulnerabilities the moment Patchstack becomes aware of them often before many site owners have even seen the vulnerability notification.

Wordfence Premium also updates its firewall rules in real time when new WordPress vulnerabilities are discovered, providing effective virtual patching for many vulnerability types.

If you run your site behind Cloudflare, you can manually create a WAF rule to block specific attack patterns associated with a known vulnerability — Cloudflare’s documentation explains how to do this, and many vulnerability disclosures include specific request patterns you can block.

Fix #3: Deactivate and Delete Plugins With No Available Fix

When a plugin has a known vulnerability and no patch exists either because it’s abandoned, because the developer hasn’t responded to the disclosure, or because it’s been closed on wordpress.org  deactivation is not enough. You need to delete the plugin completely.

Deactivated plugins still exist on your server. An attacker who knows the file paths can potentially still access and exploit vulnerable files in a deactivated plugin. Deleting the plugin removes it from your server entirely.

Yes, this means you lose the functionality that plugin provided. But functionality you can’t restore is a recoverable problem. A compromised site is a much harder one.

Before you delete the plugin, find an alternative. The WordPress plugin repository has over 59,000 plugins. For almost any functionality a vulnerable, unmaintained plugin provides, a well-maintained alternative exists. Search WordPress.org, check the alternative’s update history, verify it hasn’t appeared in vulnerability databases, and make the switch.

Fix #4: Replace Nulled Plugins Immediately

If you currently have any nulled (pirated) plugins or themes on your site, stop reading this right now and delete them. This isn’t a gray area. Every security professional who works with WordPress sites will tell you the same thing: nulled plugins are the most reliable path to getting hacked.

Attackers intentionally distribute nulled versions of popular premium plugins through piracy sites with backdoors already built in. The backdoor lets them access your site on their schedule, often waiting weeks or months before doing anything obvious ,so you don’t connect the compromise to the plugin.

Replace every nulled plugin with a legitimate licensed copy. If you can’t afford the license, find a free alternative that provides similar functionality. The cost of a plugin license is never worth comparing to the cost of a successful hack.

Fix #5: Harden Your wp-config.php and File Permissions

After you’ve addressed specific vulnerable plugins, take this opportunity to verify that your general hardening measures are in place. A vulnerable plugin creates an entry point  but proper hardening limits what an attacker can do once they’re in.

Verify that your wp-content/uploads directory blocks PHP execution. Add a .htaccess file to that directory with this content:

<Files *.php>
deny from all
</Files>

Verify that your file permissions follow the correct WordPress structure: 755 for directories, 644 for files, 400 or 440 for wp-config.php.

Disable file editing in the WordPress dashboard by adding this to your wp-config.php:

define('DISALLOW_FILE_EDIT', true);

How to Prevent Vulnerable Plugin Problems Going Forward

Detection and response are essential skills. However, prevention is where you really win. Here’s how to build a system that stops vulnerable plugins from becoming a crisis.

Set Up Automated Vulnerability Alerts

You need to know about vulnerabilities in your plugins the moment they’re publicly disclosednot days later when you happen to check your dashboard.

Subscribe to the Wordfence Intelligence email newsletter. Sign up for Patchstack’s free vulnerability alerts at patchstack.com. Add WPScan’s mailing list at wpscan.com. Follow the WPSecureStack blog for curated, plain-English vulnerability alerts.

For each plugin you actively use, you can also set a Google Alert for “[plugin name] vulnerability” to catch any public disclosures that make the news before formal databases are updated.

Establish a Plugin Update Schedule

Don’t let plugin updates pile up. Set aside time every week  or enable automatic updates for plugins you trust to review and apply available updates.

For plugins that power critical site functionality (WooCommerce, contact forms, membership systems, page builders), be slightly more cautious with automatic updates. Test major version updates in staging before pushing to production. But for minor and security releases, update immediately.

If your host provides one-click staging environments (Kinsta, WP Engine, SiteGround, and most managed hosts do), use them. Test every update in staging. Then deploy to production with confidence.

Audit Your Plugin List Every Quarter

Fewer plugins means a smaller attack surface. Most WordPress sites accumulate plugins over time you install something to test it, forget to delete it, and it sits deactivated for months with no updates applied. This is a genuinely common attack vector.

Every quarter, open your Installed Plugins page and delete anything you’re not actively using. For every plugin you keep, confirm it has been updated in the last six months and that its developer is still actively maintaining it.

Ask yourself honestly: does this plugin provide value that justifies the security risk it introduces? For low-value plugins that haven’t been updated in over a year, the answer is almost always no.

Choose Plugins Deliberately

The best time to evaluate plugin security is before you install it, not after. Before you install any new plugin, run through this checklist:

Check the plugin’s page on wordpress.org. Look at the last updated date, the active installation count, the developer’s response rate in the support forum, and the rating trends over time.

Search the plugin by name on wpscan.com/plugins. If it has existing vulnerabilities, check whether they’re patched in the current version.

Check how many open unresolved vulnerability reports exist at patchstack.com or wordfence.com/threat-intel.

Look at the plugin’s changelog. A healthy plugin has a detailed changelog with regular entries. “General improvements” with no specifics is a yellow flag. A changelog that hasn’t been updated in 12 months is a red one.

Look for plugins that follow responsible disclosure practices — where their changelogs reference security fixes clearly and link to CVEs when patches are released. That transparency shows a security-conscious developer.

Enable Two-Factor Authentication and Limit Login Attempts

Vulnerable plugins create attack surface but attackers also need to actually reach and exploit that surface. Strong authentication reduces their ability to do so.

Enable two-factor authentication for all admin and editor accounts. Use an authenticator app, not SMS. Enable login attempt limiting  three to five failed attempts before lockout. These steps don’t fix plugin vulnerabilities, but they make it significantly harder to exploit them.

What to Do If a Vulnerable Plugin Has Already Been Exploited

Sometimes you detect a vulnerability after it’s already been used. Here’s how to respond.

Step 1: Take the site offline immediately. Put it in maintenance mode. If you can’t do that quickly, use your hosting dashboard to temporarily suspend the site. A hacked site that stays online continues to harm your visitors and continues to dig deeper into your server.

Step 2: Run a full malware scan. Use Wordfence’s complete scan or MalCare’s scanner. These tools look for injected code, malicious files, and backdoors. Generate the full report — you need a complete picture of what the attacker did, not just where they got in.

Step 3: Check your activity logs. If you’ve been running WP Activity Log or any activity logging plugin, review the logs from the past 30 days. Look for unexpected admin account creation, settings changes, file modifications, or unusual login patterns. This helps you understand the scope and timeline of the compromise.

Step 4: Change every password and credential immediately. WordPress admin accounts, SFTP/FTP, database credentials, hosting control panel, any API keys stored in wp-config.php. All of them. An attacker who was in your system may have harvested these credentials.

Step 5: Remove the malware. If you’re comfortable doing this manually, Wordfence’s documentation provides detailed guidance. Most site owners, however, are better served using a professional cleanup service. Sucuri’s malware removal service and MalCare’s one-click cleanup both handle this reliably. Your host may also offer incident response assistance — Kinsta and WP Engine both do.

Step 6: Restore from a clean backup if necessary. If the infection is extensive or you can’t verify that the cleanup was complete, restore from a backup that predates the attack. Then reapply any changes made after that backup date, and apply security hardening before you go live again.

Step 7: Close the entry point. Update or delete the vulnerable plugin. Don’t bring your site back online with the same vulnerability that allowed the attack in the first place.

Step 8: Monitor intensively for 30 days. After a cleanup, watch your site closely. Attackers often leave secondary backdoors. If malware reappears within a few weeks of cleanup, you haven’t fully removed the infection. Go back to Step 2 and work more thoroughly.

FAQ: WordPress Plugin Vulnerabilities

Q: How do I find out if a specific plugin has a known vulnerability?

Search the plugin name on wpscan.com/plugins, patchstack.com/database, and wordfence.com/threat-intel. All three maintain comprehensive WordPress vulnerability databases that are publicly searchable. If you find an entry for your plugin, check which versions are affected and whether a fixed version is available.

Q: Are free plugins less secure than premium plugins?

Not necessarily. Security quality depends on the developer’s practices, not the price. Many free plugins in the WordPress repository are extremely well-maintained by capable developers. Conversely, some premium plugins have poor security track records. What matters is the developer’s update frequency, how they respond to security reports, and whether they follow responsible disclosure practices. Check the history, not the price tag.

Q: How quickly should I update a plugin after a security vulnerability is disclosed?

Immediately. As in, that same day. When a vulnerability is publicly disclosed, the window between disclosure and active exploitation is often measured in hours, not days. Attackers run automated scanners constantly looking for sites still running vulnerable versions. Don’t give them the window.

Q: Is it safe to enable automatic plugin updates?

For most plugins, yes — especially for security-focused plugins like Wordfence or Solid Security, where staying current is critical. For complex plugins that power key functionality (WooCommerce, page builders, membership systems), consider enabling automatic updates for minor and patch releases but reviewing major version updates manually in staging first. The risk of a slightly broken feature from an auto-update is almost always lower than the risk of running a known vulnerable plugin version.

Q: A plugin I depend on was closed on WordPress.org. What should I do?

Treat it as a security emergency. WordPress.org closes plugins because of unresolved security issues or policy violations. Deactivate and delete the plugin immediately. Search for an actively maintained alternative. Most functionality has multiple plugin options — find one with a recent update history and a clean vulnerability record. Yes, you’ll need to reconfigure things. That’s far better than the alternative.

Q: Can I check plugin security before installing?

Absolutely — and you should, every time. Check the plugin’s page on wordpress.org for update frequency and developer activity. Search the plugin name on wpscan.com and patchstack.com for any historical vulnerabilities. Read through the recent support forum threads for any mentions of security issues. Check the changelog for evidence that security fixes are documented clearly. This takes five minutes and filters out the vast majority of problematic plugins before they ever touch your site.

Q: My site was hacked through a plugin. Do I need to rebuild from scratch?

Probably not, but you do need to be thorough. A proper cleanup — complete malware scan, full removal of malicious code and backdoors, credential rotation, and vulnerability patching — can restore most hacked WordPress sites to full health. The key is being certain the cleanup is complete. If you’re not confident in your ability to verify this, use a professional cleanup service. Never rush a cleanup to get a site back online faster — an incomplete cleanup almost always results in reinfection.

Final thoughouts

Vulnerable plugins are the leading cause of WordPress hacks — but they’re also one of the most manageable risks if you build the right habits.

Scan your site regularly with WPScan or a continuous monitoring tool like Patchstack or Wordfence. Update the moment you see a vulnerability notification. Delete plugins you don’t use. Vet new plugins thoroughly before you install them. And build a response plan so you know exactly what to do if something gets through.

The goal isn’t a perfect, impenetrable site. No such thing exists. The goal is making your site significantly harder to hack than the thousands of WordPress sites that do none of this so that automated attacks move on and sophisticated attackers don’t find your site worth their effort.

Build that habit and you’ll stay ahead of the vast majority of threats that target WordPress every day.

Disclosure: WPSecureStack may earn a commission on purchases made through links in this article. Our editorial recommendations are based on independent evaluation and genuine security merit.