Most WordPress hacks don’t come through WordPress itself. They come through plugins — the form builder you installed two years ago and never updated, the premium slider with a flaw nobody patched, the little utility plugin with twelve thousand installs and one unmaintained file. Following WordPress plugin security best practices isn’t paranoia; it’s maintenance. Here’s the checklist our team actually runs on client sites.
Why plugins are the attack surface
WordPress core gets a lot of scrutiny and patches quickly. Plugins are the long tail: thousands of independent authors, wildly different code quality, and update habits that range from same-day fixes to “abandoned in 2021.” Attackers know this. Security researchers at Wordfence reported a critical file-upload flaw in Elementor Pro (CVE-2026-32475) affecting sites with roughly six million active installations — unauthenticated attackers could upload executable files through a form widget. Wordfence alone blocked more than 190,000 exploit attempts against that single bug. A separate privilege-escalation flaw in the Pods plugin put over 100,000 sites at risk of full administrator takeover, and BleepingComputer covered active exploitation of a WooCommerce Wholesale Lead Capture flaw (CVE-2026-27540) where attackers uploaded PHP webshells through an unauthenticated AJAX endpoint. The pattern repeats: a popular plugin, a public disclosure, a patch — and a long tail of sites that never applied it.
The uncomfortable truth: in almost every incident we’ve cleaned up, the vulnerable version was already patched. The site just hadn’t updated. The checklist below is ordered by impact, not by convenience.
The plugin security checklist
1. Inventory everything and delete what you don’t need
You can’t secure what you don’t know is installed. Pull a full plugin list — active and inactive — and remove anything that isn’t earning its place. Deactivate is not enough: delete inactive plugins, because their files still sit on the server and still have exploitable endpoints. We’ve seen hacked sites where the entry point was a plugin deactivated two years earlier. The rule of thumb: if no page, workflow, or integration uses it, it’s gone.
2. Vet plugins before installing, not after
Before adding any plugin, check three things: is it actively maintained (updated in the last six months, tested with a recent WordPress version), does the author have a track record, and does it do only what you need? A plugin with 2 million installs and a security team behind it is a fundamentally different risk from a niche widget maintained by one person in their spare time. For premium plugins, confirm the vendor publishes a security changelog and responds to disclosures — that’s the difference between Elementor-style same-week patches and silent abandonment.
3. Update on a schedule, not on vibes
Set a weekly update cadence at minimum, and treat security releases as same-day work. Enable auto-updates for minor plugin releases you trust, but run major updates through a staging copy first — a broken checkout page costs more than a day’s delay. The attack window between disclosure and your update is exactly when scanners find you; Wordfence’s telemetry on the Elementor Pro flaw showed exploitation attempts spiking within days of disclosure.
4. Harden user roles and logins
Most plugin exploits escalate through accounts. Enforce two-factor authentication for every administrator and editor, give people the lowest role that lets them do their job, and audit the user list quarterly. Delete old freelancer and agency accounts instead of leaving them dormant — dormant admin accounts are the first thing an attacker enumerates after gaining a foothold. Limit login attempts and consider renaming or restricting /wp-admin access by IP for back-office teams.
5. Add layers: WAF, file integrity, and backups
A web application firewall with virtual patching buys you time when you can’t update instantly — it blocked known exploits for the flaws above before many sites patched. Pair it with file-integrity monitoring that alerts when plugin files change unexpectedly, and with tested, off-site backups you can restore from in minutes. Untested backups are wishes, not plans; restore one quarterly so you know the process works under pressure.
What people are actually asking
The question we hear most from owners: “Is it the number of plugins, or which ones?” It’s the which — and their update state. A site with 40 well-maintained plugins from reputable authors is safer than a site with 6 plugins where one hasn’t been touched in three years. The second most common: “Will a security plugin fix everything?” No. Security plugins are a layer, not a plan. They can’t patch vulnerable code; only updates do that. Use them for the firewall, malware scanning, and login hardening — then keep doing the unglamorous work above.
Frequently asked questions
How often should I update WordPress plugins?
Review updates weekly at minimum. Apply security releases the same day they’re announced — the window between disclosure and exploitation is often measured in days, as seen in the 2026 Elementor Pro and WooCommerce plugin campaigns. Run major-version updates on a staging site first if your site takes payments or bookings.
Are premium plugins safer than free ones?
Not automatically. What matters is maintenance quality: an active author, a published security changelog, and fast patches. Plenty of free plugins on WordPress.org meet that bar, and plenty of premium plugins don’t. Judge the vendor’s security posture, not the price tag.
Can a deactivated plugin still get my site hacked?
Yes. Deactivated plugins leave their files on the server, and vulnerable code can still be reached directly by attackers in many configurations. Delete plugins you don’t use rather than merely deactivating them.
What’s the single highest-impact plugin security habit?
A scheduled, non-negotiable update cadence with same-day action on security releases — backed by tested backups so a bad update is a ten-minute rollback, not a crisis. Every major plugin incident we’ve remediated involved an already-available patch that hadn’t been applied.
Plugin security is maintenance, not a project. If you’d rather have a team run this checklist for you — or you’re weighing custom WordPress plugin development where security is designed in from day one — talk to us. We’ve been shipping and securing WordPress sites for nine years, and the boring checklist is exactly what keeps them online.