WordPress runs 43% of the web. That market share makes it the most targeted platform for automated attacks, plugin-based exploits, and brute-force attempts. Most WordPress site owners know this at some level — they've installed a security plugin, turned on automatic updates, and considered the problem solved.
It isn't solved. Here are the eight gaps we find most consistently when we audit client sites for our WordPress care and rescue service.
1. Outdated Plugins with Known CVEs
Automatic updates are enabled for WordPress core by default, but not for plugins. Many site owners — and some agencies — update plugins manually on an irregular schedule. The window between a public CVE announcement and a live exploit in the wild can be 24–48 hours. We've seen sites compromised from a plugin that had a patch available for three weeks.
Fix: Enable automatic plugin updates for plugins with a strong update track record, and subscribe to WPVulnerability DB alerts for every plugin installed on your site.
2. Admin Username "admin"
This one still appears regularly on sites that were set up before 2014 and never migrated. WordPress's default admin username is "admin" — which means automated attacks already have half the credentials they need. Brute-forcing a known username is significantly easier than guessing both username and password.
Fix: Create a new administrator account with a non-obvious username, assign all content to it, and delete the "admin" account.
3. No Two-Factor Authentication on Admin Accounts
Password strength is irrelevant if credentials have been reused elsewhere and appear in a breach database. 2FA ensures that even a correct password isn't enough to log in. Wordfence, WP 2FA, and Google Authenticator all provide reliable implementations.
4. XML-RPC Enabled
XML-RPC is a WordPress API that allows remote publishing. In 2026, virtually no sites need it — but it remains enabled by default and is a common vector for brute-force amplification attacks. One request to xmlrpc.php can attempt thousands of username/password combinations via the multicall method.
Fix: Disable XML-RPC via your .htaccess or server config, or use the Disable XML-RPC plugin if you don't have server access.
5. wp-config.php Not Protected
wp-config.php contains your database credentials, security keys, and database prefix. If it's readable via a directory traversal vulnerability or misconfigured server, an attacker gains full database access. Protect it by moving it one directory above the webroot (WordPress will find it automatically) or restricting access via server rules.
6. No Web Application Firewall (WAF)
A WAF inspects incoming requests before they hit WordPress and blocks common attack patterns — SQL injection, cross-site scripting, known exploit signatures. Cloudflare's free plan includes basic WAF rules. Wordfence Premium, Sucuri, or a server-level WAF provide more comprehensive coverage.
7. Weak Database Prefix
WordPress uses the table prefix "wp_" by default. SQL injection attacks often target this prefix specifically. Changing it to something random (e.g., "x7k2_") doesn't prevent SQL injection, but it does break automated exploit scripts that assume the default prefix.
8. No File Integrity Monitoring
Malware on WordPress sites often persists for weeks or months because site owners don't know it's there. File integrity monitoring compares your site's files against known-clean versions and alerts you when core files are modified. Wordfence's scan feature does this; so does the Sucuri Security plugin.
If Your Site Has Been Compromised
Our WordPress emergency service includes malware removal within 24 hours. We remove the infection, identify the entry point, close the gap, and implement the hardening measures above. We've handled everything from simple plugin exploits to full server-level compromises — if your site is behaving strangely, contact us before the infection spreads to your backups.