WordPress Security in 2026: The Complete Hardening Checklist

WordPress powers roughly 43% of all websites on the internet. That single statistic explains everything about why it is disproportionately targeted by attackers. It is not that WordPress is inherently insecure - it is that a platform with this kind of market share becomes the most economically efficient attack surface available. Automated scanners probe millions of WordPress installations daily, hunting for known plugin vulnerabilities, weak credentials, and misconfigured servers. The attacks are not personal; they are industrial.

What follows is a structured hardening checklist covering every meaningful layer of a WordPress deployment. Each item is specific and actionable. Vague advice like "keep things updated" has its place, but it does not help you at 11pm when something has gone wrong.

The 2026 Threat Landscape

Before diving into mitigations, it is worth being precise about what you are actually defending against. The dominant attack vectors in 2026 are not exotic zero-days - they are the same categories that have dominated for years, now executed at greater scale and with more automation.

• Brute force and credential stuffing: Attackers use leaked credential databases from unrelated breaches and try them against /wp-login.php and the REST API at volume. This is not about guessing - it is about testing known username/password pairs at machine speed.

• Plugin and theme vulnerabilities: The WordPress plugin ecosystem is the largest single source of exploitable vulnerabilities. SQL injection, cross-site scripting (XSS), and broken access control flaws in plugins are disclosed weekly. Sites running outdated plugins are scanned and exploited within hours of a public CVE disclosure.

• Supply chain attacks: Threat actors have increasingly targeted plugin developers directly - compromising a developer's account on WordPress.org to push malicious updates to thousands of sites simultaneously. A plugin you trust today may deliver malware tomorrow if its maintainer's credentials are stolen.

• XML-RPC abuse: The XML-RPC endpoint (/xmlrpc.php) enables credential-based amplification attacks. A single HTTP request can test hundreds of username/password combinations, bypassing rate limits that protect the standard login page.

Hosting and Server Configuration

Security starts before WordPress is even installed. Your hosting environment sets the floor for everything above it.

• Use a host that offers server-level firewalling and malware scanning. Shared hosting where one compromised account can read files from adjacent accounts is a structural risk. Managed WordPress hosting or a properly configured VPS with process isolation (such as CloudLinux with CageFS) eliminates this class of lateral movement.

• Enable HTTPS everywhere and enforce it with HSTS. Add a Strict-Transport-Security header with a long max-age and includeSubDomains. This prevents SSL-stripping attacks and cookie hijacking on mixed networks.

• Disable directory listing at the server level. An open directory listing on /wp-content/uploads/ gives attackers a free inventory of your file structure. Add Options -Indexes to your .htaccess or the equivalent Nginx directive.

• Run PHP on a supported, recent version. PHP versions that have reached end-of-life receive no security patches. Running PHP 8.2 or 8.3 is not just a performance decision - it closes vulnerabilities that will never be patched in older branches.

• Restrict outbound connections from the server. A compromised WordPress installation often phones home to a command-and-control server. Allowlisting outbound connections to known services (email providers, CDN APIs) and blocking everything else limits the blast radius of a successful breach.

WordPress Core and Updates

• Enable automatic background updates for minor releases. WordPress minor versions (e.g. 6.x.1, 6.x.2) almost always contain security fixes. Disabling auto-updates to avoid "surprises" trades a small inconvenience for a significant and persistent risk. Define WP_AUTO_UPDATE_CORE as true in wp-config.php if your host has disabled it.

• Remove the WordPress version number from public output. The generator meta tag and RSS feed headers advertise your exact WordPress version. Attackers use this to target known vulnerabilities. Remove the generator tag by hooking into remove_action('wp_head', 'wp_generator').

• Move wp-config.php above the web root. WordPress will automatically find wp-config.php one directory above the installation root. Placing it there means a misconfigured server cannot serve it as plain text.

• Disable the file editor in the admin dashboard. The built-in theme and plugin editor allows arbitrary PHP execution by anyone who gains admin access. Add define('DISALLOW_FILE_EDIT', true); to wp-config.php. If you also want to prevent plugin/theme installation from the dashboard, use DISALLOW_FILE_MODS.

• Set a non-standard database table prefix. The default wp_ prefix makes SQL injection attacks easier to execute. This is best configured at installation time, but migration tools can rename tables on existing sites.

User Accounts and Login Security

• Delete or rename the default "admin" username. The username "admin" is the first credential tested in every brute force campaign. Create a new administrator account with a non-obvious username, then delete the original. This alone eliminates a large percentage of automated attacks.

• Enforce strong passwords and use a password manager. WordPress's built-in password strength indicator is a nudge, not a gate. Use a password manager to generate a unique, 20+ character password for every account. The Signocore Password Generator can produce cryptographically strong passwords in-browser without sending data to a server.

• Implement two-factor authentication (2FA) for all administrator and editor accounts. TOTP-based 2FA (Google Authenticator, Authy, or a hardware key via FIDO2) makes stolen passwords insufficient for account takeover. Consider passkeys as a phishing-resistant alternative - the passkeys glossary entry covers how they work in practice.

• Rate-limit and lock out the login endpoint. Limit failed login attempts per IP and per username. Five failed attempts should trigger a temporary lockout. Apply this to both /wp-login.php and the REST API authentication endpoint.

• Block or password-protect XML-RPC entirely. Unless you have a specific integration that requires it (Jetpack being the main exception), block access to xmlrpc.php at the server level. An Nginx deny all rule or an Apache .htaccess block is more reliable than a plugin-based filter. You can generate the relevant .htaccess rules with the Signocore .htaccess Generator.

• Audit user roles and remove stale accounts. Former employees, old client accounts, and test users accumulate over time. Every active account is a potential attack vector. Conduct a quarterly audit and remove any account that does not have an active, identifiable owner.

Plugins and Themes

Plugins are the most common breach vector in WordPress. This is not a reason to avoid them - it is a reason to be disciplined about how you manage them.

• Remove every inactive plugin and theme. Inactive code still executes in some contexts, still appears in directory listings, and still contains vulnerabilities. The only safe inactive plugin is a deleted one. Keep a maximum of one inactive theme (for troubleshooting), delete all others.

• Subscribe to vulnerability disclosure feeds. The WPScan vulnerability database and Wordfence's vulnerability intelligence feed publish new disclosures daily. Set up alerts for every plugin you have installed. Knowing about a vulnerability within hours of disclosure - rather than weeks - is the difference between patching before exploitation and cleaning up after it.

• Vet plugins before installation. Check the plugin's last update date, active installation count, support forum responsiveness, and whether it has had past security disclosures. A plugin with 200 active installs and no updates in two years is a liability, regardless of how useful it looks.

• Purchase premium plugins from reputable sources only. Nulled (pirated) premium plugins are one of the primary vectors for supply chain malware. The "free" version of a paid plugin from a third-party site almost certainly contains a backdoor.

Files, Permissions, and the Database

• Set correct file permissions across the installation. Directories should be 755, files should be 644, and wp-config.php should be 440 or 400. Permissions set to 777 on any directory are an open invitation. Use the Chmod Calculator to verify the correct numeric values for your setup.

• Disable PHP execution in the uploads directory. The /wp-content/uploads/ directory is writable by WordPress and therefore a target for uploading malicious PHP files. Block execution with a server-level rule or an .htaccess file inside the directory containing deny from all for PHP file types.

• Use a dedicated database user with minimal privileges. The WordPress database user needs only SELECT, INSERT, UPDATE, DELETE, and CREATE (for plugin installations). It should not have DROP, FILE, or GRANT privileges. This limits what an attacker can do with a SQL injection vulnerability.

• Schedule and verify encrypted off-site backups. A backup that lives on the same server as the site it protects is not a backup - it is a copy. Store encrypted backups in a separate cloud provider (S3, Backblaze B2, or similar) on a daily schedule, with at least 30 days of retention. Test restoration quarterly.

Monitoring and Incident Detection

• Enable server-level access and error logging and review them. Logs you never read provide no protection. Set up log aggregation and alerting for patterns like repeated 403s on admin endpoints, large numbers of 404s (which indicate scanning), and unexpected PHP errors in production.

• Deploy file integrity monitoring. Core WordPress files do not change between updates. Any modification to a core file is a signal of compromise. File integrity monitoring tools hash every file at a known-good state and alert when changes occur outside of update events.

• Configure a Web Application Firewall (WAF) at the edge. A WAF positioned in front of your server - either via a CDN service or a dedicated provider - can block known exploit signatures before they reach WordPress. This is particularly effective against plugin vulnerability exploits that follow predictable patterns.

What Security Plugins Can and Cannot Do

Security plugins handle a useful subset of the above - login protection, file integrity monitoring, and basic firewall rules - and they lower the barrier for site owners who cannot configure these things at the server level. That is genuinely valuable.

What they cannot do is compensate for a compromised hosting environment, a weak password, an unpatched plugin with a known CVE, or a supply chain attack that arrives as a legitimate update. A security plugin installed on top of a poorly configured server is like a deadbolt on a door with no frame. The plugin operates within WordPress, which means anything that bypasses or compromises WordPress also bypasses the plugin.

The more reliable approach is layered: server-level controls handle what they handle best, application-level plugins handle what they handle best, and neither is treated as a substitute for the other.

Where to Start if You Are Starting from Zero

With 20+ items on this list, the question of prioritisation is legitimate. Not everything is equal in terms of risk reduction per unit of effort.

Fix these first - they address the highest-probability attack vectors with the least implementation complexity:

1. Delete the "admin" username and set a strong, unique password for all accounts.

2. Enable 2FA for every administrator account.

3. Block or disable XML-RPC at the server level.

4. Update all plugins, themes, and WordPress core immediately, then enable automatic minor-release updates.

5. Delete every inactive plugin and theme.

6. Verify that off-site backups exist, are running on schedule, and that you can restore from them.

These six steps eliminate the vast majority of successful attacks against WordPress sites. The remaining items on the checklist build depth - they matter, but they matter most once the fundamentals are locked down.

Security is not a state you achieve; it is a posture you maintain. Automated attackers do not take weekends off, and neither should your monitoring. The sites that get compromised are almost never the ones that were specifically targeted - they are the ones that were simply the easiest target when the scanner came around. Remove yourself from that category, and you have done most of the work.