Keeping WordPress Core Updated Is Good — But Hackers Stopped Caring About Core Years Ago

Let's be real for a second. If you're a WordPress developer and your security pitch to clients is "don't worry, we keep everything updated," you're operating on a foundation of false confidence. And I say that not to be harsh, but because the threat landscape in 2024 has shifted in ways that make that approach genuinely dangerous.

WordPress core is, by most measures, pretty well-secured these days. The security team is responsive, vulnerabilities get patched quickly, and auto-updates have pushed adoption rates to a point where most sites are running reasonably current versions. That's genuinely good news.

The problem is that attackers largely know this too. They've moved on.

Where Attacks Are Actually Coming From

According to data from multiple security firms tracking WordPress incidents over the past two years, the overwhelming majority of successful breaches originate from three places: vulnerable plugins, poorly coded or abandoned themes, and misconfigured server environments. Core vulnerabilities account for a small fraction of real-world incidents — and that fraction keeps shrinking.

Think about what that means practically. You could be running the absolute latest version of WordPress and still be completely exposed if you've got a plugin that hasn't been updated since 2021, a premium theme with hardcoded credentials in its options table, or a server where directory listing is enabled and XML-RPC is wide open.

The attack surface for a typical WordPress site isn't the CMS itself — it's everything orbiting around it.

The Plugin Problem Is Worse Than You Think

Here's something that doesn't get said enough in developer circles: the WordPress plugin repository has a quality problem. Not across the board — there are genuinely excellent, well-maintained plugins out there. But the repository also hosts thousands of plugins that haven't seen a commit in years, have known vulnerabilities sitting in the CVE database, and are still being installed by developers who see a five-star rating from 2019 and assume everything's fine.

The Wordfence Threat Intelligence team regularly publishes disclosures on plugins with active installs in the hundreds of thousands that have critical vulnerabilities — SQL injection, cross-site scripting, authentication bypasses. These aren't obscure edge cases. They're plugins you've probably used.

The developer habit that needs to change here is simple: stop treating install count as a proxy for security. Before installing any plugin on a client site, check its last update date, look it up on WPScan's vulnerability database, and verify it has a named, responsive maintainer. It takes three minutes and can save an enormous amount of pain.

Themes Are the Quiet Risk Nobody Talks About

If plugins are the front door attackers use, themes are the unlocked window around back. Premium themes — especially those purchased from third-party marketplaces rather than directly from developers — are a particularly common vector. Some of them ship with bundled plugins that have their own vulnerabilities. Some include eval() calls in their PHP that can be exploited. And abandoned themes, where the original developer has moved on and stopped releasing updates, are essentially sitting vulnerabilities with no remediation path.

For developers building client sites, the practical recommendation is to keep your theme stack narrow and deliberate. Use themes from developers who have a clear security disclosure process and an active update history. If you're using a premium theme that hasn't been updated in over a year, have a serious conversation with yourself about whether it's worth the exposure.

Server Configuration: The Layer Most Developers Ignore

This is where things get a little uncomfortable, because server configuration often falls into a gray zone between "developer responsibility" and "hosting responsibility" — and that ambiguity is exactly where vulnerabilities hide.

A few specific things that show up repeatedly in post-breach analyses:

XML-RPC left enabled. Unless you have a specific need for it — and most sites don't — XML-RPC is an attack surface that should be disabled. It's been used extensively for brute-force attacks and DDoS amplification.

File permissions set too broadly. wp-config.php should never be world-readable. The uploads directory should never allow PHP execution. These are basics, but they're skipped constantly.

No rate limiting on wp-login.php. Brute-force attacks against the login endpoint are relentless. If you're not rate-limiting at the server level or through a security plugin, you're absorbing that load and that risk for no reason.

Outdated PHP versions. PHP 7.4 reached end-of-life at the end of 2022. If your client's site is still running it — and a surprising number are — you're running an unsupported runtime with no security patches. This one's on us as developers to flag and escalate.

A Security Checklist That Actually Reflects 2024 Threats

Here's a working checklist you can run through on any WordPress project. It's not exhaustive, but it covers the gaps that matter most:

Plugins & Themes

• All plugins updated to current versions
• All plugins checked against WPScan vulnerability database
• No plugins with last update older than 12 months (flag for review)
• Theme sourced from reputable developer with active support
• No bundled plugins in theme that bypass normal update channels

Authentication & Access

• Strong, unique admin credentials (no "admin" username)
• Two-factor authentication enabled for all admin accounts
• Login page rate limiting active
• XML-RPC disabled unless explicitly required
• REST API access restricted where not needed

Server & Configuration

• PHP 8.1 or higher running
• wp-config.php permissions set to 440 or 400
• Uploads directory blocked from PHP execution
• Directory browsing disabled
• Security headers configured (CSP, X-Frame-Options, etc.)

Monitoring & Response

• File integrity monitoring active
• Failed login alerting configured
• Offsite backups running on automated schedule
• Incident response plan documented (yes, even for small sites)

The Mindset Shift That Matters Most

Security isn't a feature you add at the end of a project — it's a discipline you build into every decision along the way. The developers I've seen handle incidents best aren't necessarily the ones with the most sophisticated setups. They're the ones who think adversarially about their own work. They ask: if I wanted to get into this site, where would I start?

Keep updating core. Absolutely. But don't let that be the ceiling of your security thinking. In 2024, the real work happens everywhere else.