WordPress powers over 40% of websites on the internet, which makes it the most targeted CMS in existence. Default WordPress installations ship with several insecure configurations, and the plugin ecosystem continuously introduces third-party code with vulnerabilities that attackers exploit within hours of a CVE being published. This checklist covers the 20 security steps that close the most common WordPress attack vectors in 2026 — in priority order.

Authentication and Login Security

1. Change the default "admin" username

The username admin is targeted by every WordPress brute-force tool in existence. Create a new administrator account with a unique username, transfer content ownership to it, and delete the original admin account. An attacker who already knows the username has solved half the brute-force problem before making a single request.

2. Enforce strong, unique passwords for all user accounts

Every WordPress account — not just administrators — should use a password that is at least 20 characters and unique across all services. The WordPress user table, if exposed via SQL injection, gives attackers hashed passwords for every account on the site. Use a password manager and enforce strong passwords via the WordPress password policy settings.

3. Enable two-factor authentication on all admin accounts

2FA stops credential-stuffing and brute-force attacks even when a password is compromised. Install a reputable 2FA plugin and require it for all users with Editor role or above. Time-based one-time passwords (TOTP) via an authenticator app are the most practical option for small teams.

4. Limit login attempts and add CAPTCHA to wp-login.php

By default, WordPress allows unlimited login attempts. Install a plugin that enforces account lockout after 5 to 10 failed attempts or adds CAPTCHA to the login form. Without rate limiting, automated tools can test millions of password combinations overnight against a single WordPress login page.

5. Restrict /wp-admin access by IP address

If your administrators always work from known IP addresses, block access to the /wp-admin/ directory at the server level for all other IPs. This eliminates remote brute-force attempts on the admin panel from the wider internet, regardless of whether login protection plugins are active.

File and Configuration Security

6. Disable xmlrpc.php

XML-RPC is a legacy remote API that allows brute-force attacks at far higher speed than wp-login.php, because a single XML-RPC request can test hundreds of username and password combinations simultaneously. Unless you use a mobile app or service that specifically requires XML-RPC, block it entirely. A deny rule in your server configuration or a dedicated security plugin achieves this in one step. Exposed xmlrpc.php is among the first endpoints attackers probe on any WordPress installation.

7. Protect wp-config.php from direct access

The wp-config.php file contains your database host, credentials, authentication keys, and salts. It must never be accessible via HTTP. Move it one directory above the web root if your host allows it, or add a server rule blocking direct requests to it. A misconfigured server can expose this file as plaintext, handing an attacker full database access instantly.

8. Disable the Theme and Plugin File Editor in wp-admin

WordPress allows administrators to edit theme and plugin PHP files directly from the wp-admin dashboard. If an admin account is compromised, an attacker can inject malicious code into any PHP file via the browser. Disable this entirely by adding define('DISALLOW_FILE_EDIT', true); to wp-config.php. There is no reason to leave this enabled on a production site.

9. Set correct file permissions

WordPress files should be set to 644 (readable by all, writable only by the owner) and directories to 755. The wp-config.php file specifically should be 600. Files set to 777 are a critical misconfiguration that allows any process running on the server to write to them — including a compromised plugin or a malicious script placed by another site on a shared host.

10. Remove backup files and sensitive files from the web root

Files like wp-config.php.bak, wp-config.php.old, .sql database dumps, and .zip archives left in the web root are accessible to anyone who guesses or discovers the file name. Automated scanners probe for these file names against every WordPress installation they find. Audit your web root and delete all backup or temporary files.

Updates and Plugin Hygiene

11. Keep WordPress core updated

Security releases for WordPress core are published regularly and should be applied within 24 hours of release. Enable automatic background updates for minor security versions at minimum. Running an outdated WordPress core is one of the most common and avoidable causes of site compromise.

12. Update all plugins and themes immediately on release

Plugin vulnerabilities are the leading cause of WordPress compromises. The window between a CVE being published for a popular plugin and mass exploitation begins can be under 24 hours. Enable auto-updates for plugins with a strong security track record, and review release notes for others before applying.

13. Delete unused plugins and themes

Deactivated plugins still have their files on disk and can still be targeted by path traversal, local file inclusion, or unauthenticated endpoint vulnerabilities — deactivation does not prevent file-level attacks. Delete, not just deactivate, every plugin and theme you do not actively use.

14. Vet plugins before installation

Check each plugin's active install count, last updated date, and whether it has open security issues in the WPScan vulnerability database or the WordPress.org security advisories. Plugins that have not been updated in over two years should be treated as high risk, since they likely contain unpatched vulnerabilities against current PHP and WordPress versions.

Security Headers and HTTPS

15. Enforce HTTPS with a server-level 301 redirect

All HTTP traffic should redirect to HTTPS via a server-level 301 redirect — not just an application-level redirect — so that all resources, not just page requests, are served securely. Check for mixed content warnings after enabling HTTPS to ensure images, scripts, and stylesheets are also loading over HTTPS.

16. Enable HSTS with at least a one-year max-age

HTTP Strict Transport Security prevents SSL stripping attacks by instructing browsers to always connect to your domain over HTTPS, even when the user types http:// manually. Add Strict-Transport-Security: max-age=31536000; includeSubDomains to all HTTPS responses. After confirming your HTTPS setup is stable, submit your domain to the HSTS preload list for maximum protection.

17. Add the essential security response headers

WordPress does not add security headers by default. Add these via your web server configuration or a plugin: X-Frame-Options: SAMEORIGIN prevents clickjacking; X-Content-Type-Options: nosniff prevents MIME-type sniffing attacks; a Content Security Policy appropriate for your site limits the damage of any XSS vulnerability. All three are single-line configuration changes.

Version Disclosure, Backups, and Monitoring

18. Remove the WordPress version number from page source

By default, WordPress inserts its version number into HTML source via a <meta name="generator"> tag and into RSS feed links. This tells attackers which known CVEs apply to your installation without them needing to do any probing. Remove it by adding remove_action('wp_head', 'wp_generator'); to your active theme's functions.php.

19. Implement automated offsite backups with tested restores

Backups are your last line of defense against ransomware, destructive attacks, and database corruption. Back up both the WordPress database and all files daily to an offsite location — not the same server. Test the restore process on a staging environment monthly. Backups that have never been tested are not reliable backups.

20. Monitor for file changes and set up uptime alerts

Deploy a file integrity monitoring solution that alerts you when PHP files are created or modified outside the expected update process. A new PHP file appearing in your uploads directory or an unexpected modification to a theme file is a near-certain indicator of compromise. Combine this with uptime monitoring so you know within minutes if your site goes down or returns unexpected content.

How Shieldome Checks This

Shieldome detects WordPress sites automatically during scanning by identifying wp-login.php, wp-admin/, and WordPress-specific HTTP response patterns. Once a WordPress installation is identified, Shieldome runs platform-specific checks:

All findings are organized by OWASP category with severity ratings and step-by-step remediation instructions tailored to WordPress and common server configurations.

Frequently Asked Questions

How often should I run a security scan on my WordPress site?

Run a full scan after every significant plugin or theme update, and on a fixed weekly schedule. Many vulnerabilities are introduced by updates rather than pre-existing — the window between a vulnerable plugin update being published and active exploitation can be under 48 hours. Weekly scanning ensures new attack surfaces are detected before attackers find them.

Is a WordPress security plugin enough to fully secure my site?

No. Security plugins add important layers — login protection, file integrity monitoring, and WAF rules at the application level — but they cannot patch vulnerabilities in other plugins, enforce correct server-level configurations, fix insecure file permissions, or detect misconfigurations in HTTP response headers. They are one defense layer, not a complete solution.

Does managed WordPress hosting handle security for me?

Managed hosts handle server-level hardening, apply WordPress core updates, and provide infrastructure-level protection. However, plugin vulnerabilities, misconfigured security headers, weak admin passwords, exposed configuration files, and application-logic issues remain the site owner's responsibility on every hosting plan without exception.

What is the most common way WordPress sites get compromised in 2026?

Plugin vulnerabilities remain the leading cause, followed by weak or reused admin credentials, and outdated WordPress core. Attackers continuously scan the internet for sites running known-vulnerable plugin versions using automated tools that query WordPress metadata. A vulnerable plugin with a public CVE can be exploited within hours of the disclosure.

Should I change wp-login.php to a custom URL?

Changing the login URL adds a layer of obscurity that reduces automated brute-force traffic from bots targeting the standard path. It is a useful supplement but not a replacement for rate limiting, 2FA, and strong passwords. Determined attackers targeting your domain specifically can locate the custom URL through sitemap, robots.txt, or source code analysis.

How do I check if xmlrpc.php is exposed on my site?

Request https://yoursite.com/xmlrpc.php in a browser. If it returns an XML response containing the phrase "XML-RPC server accepts POST requests only," the endpoint is exposed and functional. A Shieldome scan will detect this automatically alongside all other WordPress-specific issues in a single report.

Shieldome automatically scans WordPress sites for exposed xmlrpc.php, version disclosure, backup file exposure, missing security headers, and 20+ additional platform-specific issues. Create a free account and run your first WordPress security scan today.