WordPress Hacking in 2025: Real Attacks & How to Stop Them

What "WordPress hacking" actually looks like in 2025

When a client tells me their site got hacked, I don't ask what attack method was used. I ask what was outdated.

Almost every WordPress hack we clean up traces back to one of four causes: an outdated plugin, a stolen password, a misconfigured host, or a developer who left a backdoor. Real targeted attacks against WordPress sites are rare. The boring causes do almost all the damage.

Here's what the data actually shows, and what to do about it.

The 2025 attack landscape, in numbers

Two reports drive most of the credible threat data: the Wordfence threat intelligence reports and Sucuri's annual hacked website report.

Metric	Estimated value (2025)
Attack attempts blocked per hour (monitored sites)	90,000-100,000
Daily automated probes globally	Tens of millions
Confirmed successful breaches per day	5,000-10,000
Active WordPress sites worldwide	95-110 million

Two reads from this. The attack volume is huge but mostly noise. The successful breach rate is well under 1% of installs per year. The risk concentrates in unmaintained sites, not WordPress itself.

What actually causes a breach

This is the table that matters, from Wordfence's confirmed breach analysis:

Cause	Share of confirmed breaches
Outdated plugin or theme	56%
Weak or stolen password	22%
Compromised hosting	11%
Stolen session token / API key	7%
Zero-day or insider	4%

If you fix the first two categories, you've closed 78% of realistic risk. The exotic stuff almost never comes up.

The 7 attack techniques that matter

Brute force credential attacks

Bots try common usernames and leaked password lists at scale. Account for 30-40% of all attempted intrusions and a significant share of successful breaches on sites without 2FA.

How they work: Automated scripts hit /wp-login.php or XML-RPC with thousands of username and password combinations, often using credentials from past data breaches.

What stops them: 2FA on every admin account (blocks 99.9% per Google's research). Limit login attempts. Disable XML-RPC if you don't use it. A real WAF in front of your site.

Plugin exploits

The single biggest cause of WordPress breaches. Attackers scan for known vulnerable plugin versions and hit them at scale.

How they work: A plugin gets a CVE published. Within 48 hours, exploit code circulates. Sites still running the old version get compromised, often before the owner has even read the disclosure.

What stops them: Auto-update minor releases. Patch critical vulnerabilities within 24 hours. Subscribe to the WPScan vulnerability feed for early warning. Audit plugins quarterly and remove anything not actively used.

SQL injection (SQLi)

Attacker injects malicious SQL through unsanitized form inputs or URL parameters.

How they work: A vulnerable plugin uses raw user input in a database query. Attacker sends payloads like UNION SELECT user_pass FROM wp_users to extract credentials.

What stops them: Updated plugins (almost always a plugin issue, not core WP). A WAF that filters SQLi patterns. Developer discipline on $wpdb->prepare() for any custom code.

Cross-site scripting (XSS)

Attacker stores malicious JavaScript in a comment, form, or theme option that runs in visitors' browsers.

How they work: Unsanitized input ends up rendered without escaping. Common targets: comment forms, search bars, contact forms, user profile fields.

What stops them: WordPress core sanitization functions (esc_html, esc_attr, etc.) used correctly in themes and plugins. Content Security Policy headers. A WAF with XSS filtering rules.

File inclusion attacks (RFI / LFI)

Bad path handling lets an attacker load arbitrary files.

How they work: Vulnerable code uses user input in include() or require() calls. Attacker passes paths like ../../../wp-config.php to read sensitive files, or remote URLs to execute hostile code.

What stops them: Updated plugins and themes. Disabling allow_url_include in PHP. A WAF that filters path traversal patterns.

Theme vulnerabilities

Same pattern as plugins: outdated or abandoned theme code becomes an attack vector.

How they work: Old themes ship with insecure AJAX endpoints, file upload handlers, or option storage. Attackers exploit these like plugin vulnerabilities.

What stops them: Use themes from reputable vendors with active maintenance. Avoid free themes from unfamiliar sources. Update themes when patches ship. Delete inactive themes (don't just deactivate).

Zero-day exploits

The dramatic ones, but rare. A vulnerability gets exploited in the wild before a patch exists.

How they work: Attacker discovers (or buys) a previously unknown bug in a popular plugin. Exploits it across thousands of sites in a window of hours or days before the vendor ships a fix.

What stops them: A real WAF (especially cloud-based with virtual patching, like Sucuri or Cloudflare). Fast incident response. Backups you can actually restore from.

The 7 defences that actually move the needle

1. Strong credentials with 2FA enforced

16+ character passwords from a manager. 2FA on every admin and editor account. No "the founder doesn't like clicking codes" exceptions.

The math: Google's 2019 research showed even SMS-based 2FA blocks 100% of automated bots, 99% of bulk phishing, and 90% of targeted attacks. App-based 2FA does even better.

2. Patch within 24 hours of critical disclosures

Auto-updates on for minor releases. Active monitoring for major releases. Subscribe to vulnerability feeds so you hear about issues at disclosure, not after exploitation.

Wordfence data: 50%+ of hacked WordPress sites were running outdated software at the time of compromise.

3. A real WAF, not just a plugin firewall

Cloudflare (₹0-1,650/month or $0-20) or Sucuri Firewall (₹16,500/year or $199) sits at the edge and filters before requests reach WordPress. A plugin firewall blocks the same stuff but only after PHP has loaded, wasting server resources and missing low-level attacks.

For sites with revenue at stake, the investment pays back in performance alone.

4. Hardened file permissions and config

• wp-config.php: 400 or 440
• Directories: 755
• Files: 644
• define('DISALLOW_FILE_EDIT', true); in wp-config.php to disable theme/plugin editor
• Block direct PHP execution in /wp-content/uploads/

These are five-minute changes that close real attack paths.

5. SSL configured properly

Free SSL via Let's Encrypt. Force HTTPS at the server level (not via plugin). Enable HSTS. Run SSL Labs and aim for an A grade. A misconfigured SSL setup gives users false confidence without the actual encryption benefits.

6. Activity logging with alerts

Log every action that matters (admin role changes, plugin file edits, new admin users, failed login spikes) and route alerts to email or Slack. WP Activity Log is the standard tool. Most sites only check logs after they've been hacked. Reverse that.

7. Daily backups, monthly restore drills

The setup that actually works: daily incremental backups via the host, weekly full backups to a separate cloud (S3, Backblaze, Google Drive), monthly test restore to staging.

A backup you've never tested is a guess, not a backup. We've seen too many "we have backups" turn into "the backups are corrupted" during real recovery.

Mitigation success rates by attack type

Technique	Frequency	Mitigation success
Brute force	30-40% of attempts	95-99% with 2FA
Plugin exploits	40%+ of breaches	90-95% with timely patching
SQL injection	15-20% of major CVEs	90-95% with updates plus WAF
XSS	15-25% of intrusions	85-95% with sanitization
Theme exploits	10-15% of CVEs	85-90% with vetted themes
File inclusion	5-10% of CVEs	90% with WAF and sanitization
Zero-day	Rare	Variable; WAF plus fast response

Where layered security still falls short

Honest section. Even a well-defended site can fail if:

• The host gets compromised at the server level. Your application security doesn't protect you from a breached hypervisor or a rogue admin at the data centre.
• A trusted developer goes rogue. Insider access bypasses most external defences.
• Supply chain attacks ship malicious code in a legitimate plugin update. Rare but real. Staged updates on staging environments help here.
• The attacker is patient and skilled. State-level adversaries and well-funded targeted attacks can crack most commercial defences. If you're a journalist, activist, or politically exposed person, you need professional security beyond what plugins offer.

Practical roadmap: the first 30 days

Week 1: Audit and baseline

• Inventory plugins and themes; remove anything unused for 90+ days
• Update WordPress core, all plugins, all themes
• List all admin and editor users; remove inactive ones
• Run a Sucuri SiteCheck or WPScan to confirm no existing compromise

Week 2: Layer defences

• Enrol every admin and editor in 2FA
• Set up Cloudflare or Sucuri at the edge
• Configure SSL, run SSL Labs test, fix any issues

Week 3: Backups and monitoring

• Daily off-site backups via UpdraftPlus or Solid Backups
• Test restore on a staging environment
• WP Activity Log with email alerts for sensitive events

Week 4: Documentation and process

• One-page incident response plan with passwords reset, isolation steps, and contact list
• Quarterly audit on the calendar
• Training for any team members with admin access

For deeper coverage, see our 7 key WordPress security strategies and the 5 security plugins worth installing in 2025.

What's coming in 2025-2026

• Auto-updates becoming default for more plugins and themes
• AI-driven detection at the WAF layer (Cloudflare, Sucuri, Wordfence all shipping ML models)
• Tighter plugin repo controls with faster pulls of vulnerable plugins
• Built-in security in Full Site Editing: WordPress core moving more guardrails into the platform itself

The platform is doing its part. The weak link remains operations.

FAQ

How fast should I patch a critical WordPress vulnerability? Within 24 hours of disclosure. The window between public CVE and active exploitation has dropped to under 48 hours for popular plugins. Auto-updates for minor releases are safe to enable. Major release reviews can happen on staging.

Is hiding the WordPress login URL real security? Mostly theatre. A determined scanner finds your custom login URL in minutes. It cuts brute force noise but doesn't stop a real attacker. Use 2FA and a WAF instead.

Should I disable XML-RPC? If you don't use the WordPress mobile app, Jetpack, or pingbacks, yes. It's a common brute force and DDoS amplification target. Disable it via plugin or in your .htaccess file.

What's the difference between a plugin firewall and a cloud WAF? A plugin firewall (Wordfence, AIOWPS) runs inside WordPress and filters requests after PHP has loaded. A cloud WAF (Cloudflare, Sucuri) blocks requests at the edge before they reach your server. Cloud WAFs are faster, catch more attack types, and protect against DDoS. Use both ideally.

How do I know if my WordPress site has been hacked? Run a Sucuri SiteCheck scan. Check Search Console for suspicious indexed pages. Search Google for site:yoursite.com viagra (common SEO spam marker). Watch for unexpected admin users, file changes, or sudden traffic shifts. If anything looks off, assume compromise and start a clean restore.

Need help with WordPress security?

We've audited and secured WordPress sites for clients across India, the US and UK since 2007. If you want a professional security audit or ongoing managed security, get in touch or see our WordPress development service for ongoing maintenance plans.