Why WordPress Sites Get Hacked: The Real Attack Vectors

Most WordPress sites aren't hacked by someone targeting you specifically — they're caught in automated sweeps that test millions of sites a day for known weaknesses. Understanding exactly how those sweeps work, and which doors they're trying, is the fastest way to close them before a bot finds yours.

The Uncomfortable Truth About WordPress Hacks

WordPress powers roughly 40% of the web, which makes it a high-value target not because it's inherently insecure, but because the sheer volume means even a tiny percentage of vulnerable sites represents millions of entry points. Attackers build automated scanners that probe for specific, known weaknesses — outdated plugin versions, predictable file paths, weak credentials — and work through lists of URLs at machine speed. Your site doesn't need to be famous to end up on one of those lists. It just needs to exist.

The good news: the vast majority of successful attacks exploit preventable, well-understood weaknesses. Here's exactly what they are.

Attack Vector 1: Vulnerable Plugins and Themes

This is consistently the leading cause of WordPress compromises. When a security researcher discovers a vulnerability in a popular plugin — a SQL injection flaw, a cross-site scripting (XSS) bug, an unauthenticated file upload — it gets disclosed publicly, usually after the plugin author has released a patch. That public disclosure is a starting gun. Automated bots scan for sites still running the vulnerable version, often within hours of the advisory going live.

The risk is highest when:

• Auto-updates are disabled and updates are applied infrequently
• You're running a premium theme or plugin purchased from a third-party "nulled" (pirated) source — these frequently contain backdoors baked in at download
• You have plugins installed but deactivated — they're still on disk and can still be exploited

What to do: Enable auto-updates for plugins and themes in WordPress settings, or at minimum check for updates weekly. Delete — don't just deactivate — plugins you aren't using. Never install nulled software. Check the Wordfence vulnerability database if you want to verify whether a specific plugin version has a known issue.

Attack Vector 2: Weak or Reused Passwords (Credential Stuffing)

Brute-force attacks try thousands of common passwords against /wp-login.php until one works. Credential stuffing is more sophisticated: attackers take email/password combinations leaked from other breached services and try them against WordPress login pages, knowing many people reuse credentials.

A compromised admin account gives an attacker everything — they can install malware, create hidden admin users, redirect traffic, or quietly exfiltrate customer data without triggering any obvious error on your site.

What to do:

1. Use a unique, randomly generated password for your WordPress admin account — at least 20 characters, stored in a password manager.
2. Enable two-factor authentication (2FA) on every admin account. Plugins like WP 2FA or the built-in 2FA in Jetpack work reliably.
3. Limit login attempts using a plugin or your host's firewall. After three to five failures, lock the IP out temporarily.
4. Change the default admin username if you created your site with "admin" — it's the first username every bot tries.

Attack Vector 3: Exposed or Misconfigured wp-config.php and File Permissions

wp-config.php contains your database credentials, authentication keys, and table prefix. If file permissions are set too loosely — say, 777 on directories or 644 on wp-config.php when it should be 440 or 400 — a compromised adjacent site on shared hosting, or a vulnerability elsewhere in your stack, can expose that file directly.

Similarly, if wp-config.php is accessible over HTTP (some misconfigured servers will serve it as plain text rather than executing it), an attacker can pull your database password directly from a browser.

What to do: Set wp-config.php permissions to 440 (owner and group can read; no one else). Move wp-config.php one directory above your web root if your host supports it — WordPress will still find it automatically. Add this block to your .htaccess to deny direct HTTP access:

<Files wp-config.php>
  order allow,deny
  deny from all
</Files>

Attack Vector 4: XML-RPC Abuse

XML-RPC is a remote publishing interface that's enabled by default in WordPress. It's largely a legacy feature — most modern workflows use the REST API instead — but it remains a popular attack surface for two reasons: it allows multiple authentication attempts bundled in a single HTTP request (making brute-force much faster), and it can be used to stage distributed denial-of-service amplification attacks through the system.multicall method.

Unless you use an app that specifically requires XML-RPC (the Jetpack plugin uses it; some mobile publishing apps do too), disabling it closes a door you probably didn't know was open.

What to do: Add this to .htaccess to block external access:

<Files xmlrpc.php>
  order deny,allow
  deny from all
</Files>

Or use a security plugin with an XML-RPC toggle. If you use Jetpack, check whether it still works after disabling — it may route through an alternative.

Attack Vector 5: Insecure Hosting Environments

Your site's security is bounded by its hosting environment. Cheap shared hosting with outdated PHP versions, no PHP-FPM process isolation between accounts, or no Web Application Firewall (WAF) at the server level means a compromise of any site on that server can spread to yours — a "cross-site contamination" attack that has nothing to do with your own code or practices.

PHP 7.4 reached end-of-life in November 2022. If your host is still running it as the default, security patches are no longer being issued for that PHP version itself. PHP 8.1 and 8.2 are the current stable options as of this writing.

What to do: Check your PHP version in Tools → Site Health → Info → Server inside WordPress. If you're below 8.1, ask your host to upgrade — nearly all managed WordPress hosts and modern shared hosts support this through the control panel. If your host doesn't support current PHP versions, it's worth moving.

Attack Vector 6: Abandoned or Forgotten Sites

A staging site left running with no one monitoring it. A microsite built for a campaign three years ago. A development environment accessible at a public URL. These are disproportionately common entry points because they never get updated, nobody watches them for anomalies, and attackers know they're likely to be running old, unpatched software.

What to do: Audit every WordPress install you own. Delete ones you aren't using. Password-protect staging environments at the server level (HTTP auth, not a WordPress login), and keep them updated on the same schedule as your production site.

What Happens After a Successful Hack

Most attacks don't announce themselves. Attackers want persistence — they plant a backdoor, create a hidden admin user, or inject malware into core files and then stay quiet while using your site to send spam, host phishing pages, mine cryptocurrency, or redirect your traffic to other sites. You might not notice for weeks, until Google flags your site or your host suspends your account.

If you suspect your site has already been compromised, the guide at WordPress Site Hacked? Here's How to Clean It Up — Safely walks through the cleanup process in order. Don't skip the "replace core files" step — patching only the visible symptoms without removing backdoors means the attacker can re-enter any time.

Building a Layered Defense: What Actually Matters

No single measure is enough. The sites that stay clean long-term layer several controls:

• Automatic updates for WordPress core, plugins, and themes
• Strong, unique credentials with 2FA on every admin account
• A WAF — either at the hosting level or via a plugin like Wordfence or a DNS-level service like Cloudflare
• Regular off-site backups you've actually tested restoring from
• Uptime and file-change monitoring so you catch anomalies early
• Current PHP version and a host with per-account process isolation

If you want a practical schedule for keeping all of this running without spending hours on it each month, the post on the WordPress maintenance routine that actually prevents emergencies lays out a realistic cadence.

When to Call a Professional

If you've discovered signs of a compromise — unfamiliar admin accounts, strange redirects, Google warnings, a suspended hosting account — stop trying to patch around the edges and get a full cleanup done. Partial cleanups routinely fail because attackers plant multiple backdoors, and missing one means starting over.

If you're not confident your site's current security posture is solid, or you simply don't have time to audit everything above, a free Mend Diagnosis will triage what's actually exposed on your specific site and give you a flat price for any work needed — no card required, no obligation. Most fixes go out the same day.

For ongoing peace of mind, the Mend Care Plan covers managed updates, automated backups, security and uptime monitoring — everything that keeps the attack surface small without you having to think about it each week.