WordPress security hardening checklist for 2026 (WordPress 7.1)

Most WordPress sites are not compromised through WordPress core. The official hardening guide says attacks are "rarely" attributed to infrastructure and "most often attributed to the application itself", which in practice means outdated plugins, weak passwords and over-privileged accounts. The good news is that the controls which stop most attacks are free and take an afternoon to put in place.

This checklist collects those controls in one place for WordPress 7.1, the current major release. Each item says what to do, why, and how to verify it. It is based on the hardening, backup and wp-config.php pages of the official Advanced Administration Handbook, and on the WP-CLI command reference.

A reminder of why updates come first: WordPress 7.1.3, released on 6 October 2026, fixed seven security issues, including a stored cross-site scripting flaw on the Comments screen and a second-order SQL injection in the WXR export. The release post recommends updating immediately.

1. Keep everything current

• Run the latest WordPress release. The hardening guide is explicit that older versions are not maintained with security updates. Security fixes are backported to older branches as a courtesy, but only the most recent version is actively supported.
• Leave automatic minor updates on. Since WordPress 3.7, maintenance and security releases install automatically by default. The handbook strongly discourages disabling them.
• Update plugins and themes promptly, and delete what you do not use. The guide says: "if you are not using a specific plugin, delete it from the system". A deactivated plugin is still code on your server.
• Install from trusted sources only. Download WordPress only from wordpress.org, and restrict plugins and themes to the WordPress.org directory or well-known vendors. Never install "nulled" copies of paid plugins.
• Run a supported PHP version. WordPress.org recommends PHP 8.3 or later and MySQL 8.0+ or MariaDB 10.11+. WordPress still runs on PHP 7.4 and MySQL 5.5.5, but the requirements page warns these versions are end-of-life and may expose the site to vulnerabilities.

2. Lock down accounts and logins

• Strong, unique passwords for every account, generated by a password manager. The guide lists what to avoid: names, dictionary words, short or single-character-class passwords.
• Turn on two-step authentication for every administrator and editor. The hardening guide recommends it as an additional measure; WordPress core does not include it, so use a well-maintained plugin or your identity provider.
• Avoid predictable usernames such as admin or webmaster, which are attacked first.
• Give people the lowest role that works. Most contributors need Author or Editor, not Administrator. Review the administrator list every quarter and remove people who have left.
• Use HTTPS everywhere and force it for the admin area with FORCE_SSL_ADMIN so that passwords and cookies are never sent in clear text.
• Slow down brute-force attempts with login rate limiting at the web server, a firewall service, or a plugin. The handbook's brute-force page covers server-level options.

3. Harden wp-config.php

wp-config.php holds your database credentials and security keys, and it accepts constants that switch off risky features. These lines are documented in the handbook's wp-config.php page:

// Serve wp-admin and logins over HTTPS only.
define( 'FORCE_SSL_ADMIN', true );

// Remove the built-in theme and plugin file editors.
define( 'DISALLOW_FILE_EDIT', true );

// Optional, stricter: also block installing and updating plugins and themes
// from wp-admin (also disables the file editors). Only use this if updates
// are deployed some other way, for example WP-CLI or CI.
// define( 'DISALLOW_FILE_MODS', true );

// Keep automatic minor (maintenance and security) core updates on.
define( 'WP_AUTO_UPDATE_CORE', 'minor' );

// Never show PHP errors to visitors on production.
define( 'WP_DEBUG', false );
define( 'WP_DEBUG_DISPLAY', false );

Notes on the choices above:

• DISALLOW_FILE_EDIT removes the Dashboard theme and plugin editors. The guide calls the editor "often the first tool an attacker will use if able to login, since it allows code execution."
• DISALLOW_FILE_MODS goes further and blocks plugin and theme installation and updates from wp-admin. It is a good fit when you deploy with Git or WP-CLI, and a bad fit if nobody will update the site by other means.
• WP_AUTO_UPDATE_CORE accepts true (all core updates), false (none) or 'minor'. Leave at least minor updates enabled.

On Apache, also deny direct web access to the file by adding this at the very top of .htaccess:

<Files "wp-config.php">
Require all denied
</Files>

Keep your secret keys and salts unique per site. If you suspect a compromise, generating new ones forces every user to log in again.

4. Set sensible file permissions

The guide's recommended scheme is that all files are owned by your user account, and only wp-content (uploads, and anything a plugin documents) is writable by the web server process. On a typical Linux host:

# Directories 755, files 644 (run from the server shell, adjust the path)
find /path/to/wordpress/ -type d -exec chmod 755 {} \;
find /path/to/wordpress/ -type f -exec chmod 644 {} \;

# wp-config.php readable only by you and the web server
chmod 440 /path/to/wordpress/wp-config.php

The handbook suggests 400 or 440 for wp-config.php, so that only you and the web server can read it. Test that the site still loads afterwards: the right value depends on whether your host runs PHP as your user or as a shared web-server user. When WordPress runs automatic updates, it performs file operations as the owner of the files and sets files to 0644 and directories to 0755.

Always connect with SFTP or SSH rather than plain FTP, so credentials are encrypted in transit.

5. Contain the database

• One database and one database user per site. If one site on a server is compromised, separate credentials make it harder to reach the others.
• Do not expose MySQL to the internet. Disable remote TCP connections unless you need them, and then restrict them by firewall.
• Consider reduced privileges, with care. Day-to-day WordPress operation needs only SELECT, INSERT, UPDATE and DELETE.

-- Day-to-day privileges for the WordPress database user (MySQL 8.0+).
-- Read the warning in the article before revoking schema privileges.
GRANT SELECT, INSERT, UPDATE, DELETE ON wordpress_db.* TO 'wp_user'@'localhost';

The handbook adds a warning: major updates and some plugins change the schema, and attempting them without CREATE/ALTER privileges can cause failures. It does not recommend revoking those privileges unless you have tested backups and a process to grant them temporarily during updates. For most small sites, separate users per site is the safer win.

6. Add a firewall layer

The hardening guide describes three places a firewall can sit:

Whichever you choose, keep it updated and review what it blocks, so that a false positive does not lock editors out.

7. Verify integrity and watch the logs

WP-CLI gives you a quick, scriptable health check. These commands are all in the official command reference:

# Is core current? Are any plugins or themes waiting for updates?
wp core version
wp core check-update
wp plugin list --update=available
wp theme list --update=available

# Have core or WordPress.org plugin files been modified?
wp core verify-checksums
wp plugin verify-checksums --all

# Who has administrator access?
wp user list --role=administrator --fields=ID,user_login,user_email

wp core verify-checksums downloads the MD5 checksums for your installed version from WordPress.org and compares every core file, without loading WordPress. wp plugin verify-checksums --all does the same for plugins hosted on WordPress.org. An unexpected changed file in wp-includes is a strong sign of compromise.

Keep web server access and error logs, and look at them. The hardening guide notes that logs show cross-site scripting, file inclusion and directory traversal attempts, as well as brute-force activity, along with the IP and time of each request. On servers you manage, tools such as OSSEC can aggregate and alert on logs; on managed hosting, ask how long logs are kept and how you can read them.

8. Back up, and test the restore

Backups are a security control because they are how you recover. The handbook's backup page makes three points worth copying into your runbook:

• A full backup has two parts, the database and the files. Backing up the WordPress folder does not back up the database.
• Keep at least three to five recent backups in different locations: one on the server, one in cloud storage and one offline.
• Schedule weekly backups for small, quiet sites and daily backups for busy ones, and run a manual backup now and then to prove the automated process works.

The hardening guide adds that regular snapshots let you rebuild from a point before a compromise and compare with later copies to see how the attacker got in. Encrypt backups, and record a hash of each backup file so you can tell if it was altered.

The checklist

Summary

Security is "risk reduction, not risk elimination", as the official guide puts it. Updated software, strong authentication, a locked-down wp-config.php, least-privilege accounts, a firewall and tested backups cover the attacks that hit most WordPress sites. Put the checklist above into a recurring calendar task, and re-run the WP-CLI checks after every incident or major update.