Vulnerable WordPress Plugins: How They Get You Hacked (and Fixes)
If a WordPress site gets hacked, a plugin is usually to blame. Plugins run with full access to your site, they're written by thousands of different developers, and a single vulnerable one is enough. This guide explains how plugin vulnerabilities are exploited, how to audit what you run, and how to shrink your attack surface.
Check your exposure now: run a free MageArgus scan for outdated components and web-reachable indicators of compromise.
- Plugins account for the clear majority of disclosed WordPress vulnerabilities — WPScan / Patchstack
- Thousands of new plugin vulnerabilities are catalogued every year — Patchstack annual report
How plugin vulnerabilities get exploited
Common classes: SQL injection and cross-site scripting (XSS) from unsanitised input, broken access control (an action that should be admin-only isn't), arbitrary file upload leading to a webshell, and PHP object injection. Once a vulnerability is disclosed, automated bots scan the whole web for sites running the affected version — often within hours.
Why 'deactivated' isn't safe
A deactivated plugin still has its files on disk, and some vulnerabilities are reachable without the plugin being active. If you're not using it, delete it, don't just deactivate it.
Audit what you run
List your plugins and their versions, and cross-check against a vulnerability database:
wp plugin list --fields=name,status,version,updateFlag anything outdated, anything not updated by its author in 12+ months, and anything you don't actively use. Fewer plugins = smaller attack surface.
Reduce the risk
- Update promptly — enable auto-updates for trusted plugins.
- Prefer popular, actively-maintained plugins with a good security track record.
- Never install nulled/pirated plugins — they routinely contain backdoors.
- Add a WAF or security plugin as virtual patching for the window between disclosure and update.
If a plugin already let someone in
Assume a backdoor was planted. Follow the malware removal guide: replace files from clean sources, remove backdoors, reset secrets, update the vulnerable plugin (or remove it), then re-scan.
Frequently asked questions
How do I know if a plugin I use is vulnerable?
Check its version against a vulnerability database like WPScan or Patchstack, and watch for update notices. A scanner that flags outdated components will surface the obvious cases automatically.
Are paid plugins safer than free ones?
Not inherently — both can have vulnerabilities. What matters is active maintenance, a responsive developer, and prompt updates. A well-maintained free plugin beats an abandoned paid one.