A WordPress Plugin Security Checklist

Updated 26 September 2026 · 6 min read

Most WordPress trouble that looks like “hacking” starts as ordinary neglect: an old plugin, an extra admin user, a copy of a paid plugin downloaded from a stranger, no backup. Security is a checklist you repeat, not a single shield plugin. This article is a practical list for site owners: updates, unused plugins, nulled files, user roles, two-factor authentication, backups before updates, abandoned plugins, and first steps if something already went wrong. It is general education, not a guarantee and not an incident-response contract.

Keep plugins, themes, and core updated

Updates patch holes that attackers already know how to scan for. In wp-admin, look at Dashboard → Updates. Turn on automatic updates for plugins you trust if your host and workflow allow it, or set a weekly reminder. Update on staging first when the site takes payments or uses a lot of custom code.

Read the changelog when the version jump is large. Then update, click around the site, and only then move on. Updating ten plugins at once on a live shop is how you lose the afternoon to an unknown conflict. If an update fails, see troubleshooting plugin conflicts rather than repeating the click.

PHP itself needs updates too. An ancient PHP version can leave even a current plugin on a shaky foundation. Site Health will warn you. Plan PHP upgrades with the host; they are not a plugin setting.

Remove unused plugins, do not only deactivate

Deactivated plugins still live under wp-content/plugins. Their files can still contain old vulnerabilities. If a web server can be tricked into running those files, “inactive” is not the same as gone. Delete plugins you do not use. Confirm on a staging copy if you are unsure whether a must-have shortcode lives in old content.

Do the same for unused themes. WordPress needs one theme; extras are extra PHP. Keep a default theme such as a current Twenty-something theme as a fallback, and remove the rest you do not intend to switch to.

After deletions, check leftover tables and options only if you know how (or ask a developer). Orphaned options are usually a lesser issue than leftover executable files, but backup plugins and builders can leave large data. The cleanest time to remove a plugin is soon after you decide you do not need it, while you still remember what it touched.

Never install nulled plugins

A “nulled” plugin is a pirated copy of a paid product, often bundled with extra code the original author did not ship. That extra code is the point for the person who packaged it: a backdoor, a spam injector, a crypto miner, a mailer. You cannot audit a zip from a random forum by looking at the filename.

If you need a paid feature, buy it from the author or do without. If budget is the issue, use a maintained free plugin that does a smaller job. The cost of a compromise — cleanup, lost sales, poisoned search results, customer trust — dwarfs a licence you were avoiding. More on that choice is in free vs premium plugins.

Also skip plugins advertised as “GPL download” on unrelated blogs when the real product is sold elsewhere. Stick to WordPress.org for free plugins, and to the developer’s own site for paid ones.

Least-privilege users and 2FA

Every person who can install plugins is a full administrator in practice. Give Administrator to people who need to change the site, Editor to people who need to publish, and lower roles to everyone else. Do not share one “admin” login. When a contractor finishes, remove their user or at least demote and reset passwords.

Use unique passwords. A password manager is a process, not a product pitch; reuse across wp-admin, hosting, and email is how one leak becomes three. Enable two-factor authentication (2FA) for administrators. Many security plugins and dedicated 2FA plugins can do this. Keep backup codes somewhere offline so you are not locked out on a phone swap.

Limit login URLs only if you understand the tradeoff (it hides nothing from a determined attacker, and it can break apps). It is optional seasoning. Unique users, strong passwords, 2FA, and updates are the meal.

Back up before you update

A backup is part of security because it is how you recover from a bad plugin, a bad click, or a real intrusion. Take a backup before bulk updates and before installing anything new. Confirm that the backup includes both the database and the files you care about, and that a copy sits off the server. Practice a restore on staging. The routine is spelled out in WordPress backups explained.

Host snapshots are good. They are not always enough if they skip wp-content/uploads or if the restore ticket takes two days. Know how to open a ticket, and know how to revert a single plugin folder if wp-admin is down.

Watch for abandoned plugins

Abandonment looks like: no updates for a long time, support threads unanswered, “tested up to” stuck on an old WordPress, authors’ website gone. That plugin may still run. It is also unlikely to get a patch when the next hole is found.

Make a yearly (or quarterly) pass. For each plugin: still needed? still maintained? still the simplest way to do the job? If not, plan a replacement on staging, then remove the old one. Popularity does not save an abandoned project. Neither does “but it still works.”

Custom plugins a developer left without documentation are a special case. Budget time to understand them, or replace the feature. Unmaintained custom code is still a plugin in wp-content/plugins.

If you think the site is compromised

Stay calm and do not log in from a computer you suspect is infected. Work from a clean machine. Typical first moves, in order you can actually do:

Put the site in maintenance or take it offline if it is spreading spam or stealing data.
Change hosting, FTP/SFTP, database, and WordPress passwords; rotate API keys and salts if you know how or the host can.
Restore to a known-good backup from before the strange behavior, then update everything. If you do not have that backup, you are in cleanup territory: file comparison, malware plugins as a temporary aid, or a professional.
Remove unused plugins and themes; replace core files with fresh copies from WordPress if instructed by someone who knows the site.
Check users for extra Administrators you did not create. Check cron, .htaccess, and unexpected PHP files in uploads.
Tell your host. They can often see outbound mail floods or infected accounts on the same server.

Do not pay a ransom pop-up. Do not download a “fixer” from the same strange ad that appeared on your site. After recovery, the checklist above is how you try not to repeat the week.

Checklist

Core, themes, and plugins current; PHP not abandoned.
Unused plugins and themes deleted, not merely deactivated.
No nulled or random-zip plugins.
Unique admin users, strong passwords, 2FA on administrators.
Backup before updates; off-site copy; restore tested.
Abandoned plugins scheduled for replacement.
If compromised: isolate, rotate credentials, restore or clean, then patch the process.

Pick a recurring calendar slot — monthly is enough for many brochure sites — and run this list. A short, boring habit beats a dramatic cleanup.

Related guides

Independent information; we are not affiliated with WordPress or any plugin developer. Always back up before changing plugins.