WordPress security hardening: a practical checklist for 2026
Originally published at hamzaahmadaslam.com. How this article was made: drafted with AI assistance from a researched brief, then checked against primary documentation before publishing. Short answer: outdated plugins,
Originally published at hamzaahmadaslam.com.
How this article was made: drafted with AI assistance from a researched brief, then checked against primary documentation before publishing.
Short answer: outdated plugins, reused passwords and forgotten admin accounts are all risks to review. Good WordPress security hardening comes down to a few habits: keep everything updated, remove what you don't use, lock down logins and file editing, stop PHP from running in the uploads folder, and keep off-site backups you have restored. Use this checklist to review the installation and plan the changes it needs.
Cleaning up infected WordPress sites is part of my work. Start with an inventory of installed code and account access, then record how you will detect a problem and recover from it.
Start with a read-only review
Before changing anything, find out where you stand. If you have WP-CLI on the server, these read-only commands tell you a lot:
# Are core files exactly what WordPress.org shipped?
wp core verify-checksums
# Same check for plugins from the WordPress.org directory
wp plugin verify-checksums --all
# Who can change everything?
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
# What is out of date?
wp plugin list --update=available
wp theme list --update=available
Any checksum mismatch, admin you don't recognise or plugin that is years behind goes straight to the top of your to-do list.
The WordPress hardening checklist
| Area | What to do | Why it matters |
|---|---|---|
| Updates | Turn on automatic minor core updates and plugin auto-updates for well-maintained plugins | Reduces exposure to known, patched vulnerabilities |
| Plugins | Delete (don't just deactivate) anything unused; replace plugins abandoned for over a year | Inactive code can still be reached |
| Accounts | One admin per real person, strong unique passwords, two-factor authentication | Stolen passwords are the cheapest way in |
| Logins | Rate-limit wp-login.php and XML-RPC |
Stops credential stuffing |
| File editing | Disable the built-in theme and plugin editor | Removes the dashboard editor as one route to changing code |
| Uploads | Block PHP execution inside wp-content/uploads
|
Uploaded web shells can't run |
| Secrets | Unique salts in wp-config.php, rotated after any incident |
Invalidates stolen sessions |
| Backups | Automatic, off-site, versioned, and tested by restoring one | A backup you've never restored is a guess |
| Monitoring | Watch uptime, vulnerabilities and file changes | You fix what you see |
1. Put wp-config.php to work
These constants restrict selected dashboard actions and connection behavior:
// Nobody edits PHP from the dashboard. Deploy changes instead.
define( 'DISALLOW_FILE_EDIT', true );
// Always use HTTPS for the admin area.
define( 'FORCE_SSL_ADMIN', true );
// Allow automatic minor core updates (security releases).
define( 'WP_AUTO_UPDATE_CORE', 'minor' );
If you also deploy plugins through Git or a pipeline, DISALLOW_FILE_MODS blocks installing and updating from the dashboard too. Only enable it if something else keeps your plugins updated.
Rotate your salts whenever you suspect a leak. This signs everyone out:
wp config shuffle-salts
2. Stop PHP from running in uploads
The uploads folder should only ever contain media. On Apache, add an .htaccess file inside wp-content/uploads:
<FilesMatch "\.(?:php[0-9]?|phtml|phar)$">
Require all denied
</FilesMatch>
On Nginx, add this to the server block:
location ~* /wp-content/uploads/.*\.(?:php[0-9]?|phtml|phar)$ {
deny all;
}
3. Tighten logins
- Turn on two-factor authentication for every account that can publish or manage plugins.
- Give people the lowest role that works. Editors rarely need to be administrators.
- Limit login attempts at the web application firewall or with a well-maintained plugin.
- If nothing uses XML-RPC (Jetpack and some older integrations still do), block
xmlrpc.phpat the server.
4. Set sane file permissions
A common baseline is 755 for folders and 644 for files, with wp-config.php readable only by the account PHP runs as (640 or 600, depending on your host). Never use 777.
5. Add security headers
Headers cost nothing and block common browser-side attacks. Start with X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin, a frame-ancestors rule (or X-Frame-Options) and HSTS once the site is fully on HTTPS. A Content Security Policy is the strongest of all, but test it carefully, because page builders often rely on inline scripts.
For the details, see which WordPress security headers to set and how to test them safely.
If a site is already infected
- Take a full copy first (files and database). You'll want it for investigation.
- Put up a maintenance page or block traffic while you work.
- Reinstall core and every plugin and theme from clean sources. Don't try to "fix" infected copies.
- Search for PHP files that shouldn't exist, especially in
uploads, and checkmu-pluginsand.htaccess. - Review scheduled tasks with
wp cron event list. Malware likes to schedule its own return. - Remove unknown admin users, then reset every password and shuffle the salts.
- Update everything, then find the entry point. If the entry point remains open, the site can be compromised again.
- Request a review in Google Search Console if the site was flagged.
If the site is already compromised, follow the step-by-step guide to cleaning a hacked WordPress site.
Keep it that way
Hardening needs review as plugins, accounts and hosting change. Subscribe to a vulnerability feed such as Wordfence Intelligence, WPScan or Patchstack, and check it against the plugins you run. Once you look after more than a handful of sites, automate that check. That is exactly why I built Fleet Sentinel.
Need a hand hardening or cleaning a site? Check my maintenance & security service or get in touch directly. Hardening and malware cleanup are a regular part of my work.
Originally published by Dev.to Security. Aggregated on AIWithGhost for educational purposes β full credit and traffic to the original publisher.