Is WordPress Actually Insecure? What 80+ Billion Blocked Attacks and Plugin Statistics Tell Us

WordPress powers over 43% of all websites on the internet. That dominance makes it an unmatched publishing engine, but it also paints an enormous target on its back. Browse any web development forum and you’ll find the same lingering debate: is WordPress inherently broken from a security standpoint, or is it getting a bad rap?

Looking past the speculation and straight at vulnerability databases and firewall metrics reveals an unmistakable reality: WordPress core is exceptionally resilient – the real security minefield lies in the third-party ecosystem and basic site maintenance.

The Core Myth vs. The Plugin Problem

The assumption that core WordPress code is full of holes does not match vulnerability records. Tracking from databases like WPScan shows a heavily skewed breakdown of security flaws:

• Plugins: ~93% of all cataloged vulnerabilities
• Themes: ~7% of all cataloged vulnerabilities
• WordPress Core: ~1% of all cataloged vulnerabilities

In one six-month tracking window documenting 602 ecosystem vulnerabilities, exactly 3 were tied to core code – the other 599 originated entirely within third-party extensions. Annual data from Wordfence confirms the pattern, showing that 96% of nearly 8,000 recorded vulnerabilites in a single year came directly from plugins.

Why the massive difference?

WordPress core is monitored by a dedicated team of more than 50 top-tier security researchers and engineers who perform peer reviews and backport fixes automatically. The plugin directory meanwhile, contains over 60,000 add-ons built by developers with drastically varying security standards. Many become abandoned or under-maintained, leaving backdoors wide open.

The 86-Billion Brute Force Wave

Exploiting complex code vulnerabilities is only part of the story. The primary method threat actors use to breach sites is brute-force credential stuffing.

In a six-month stretch, Wordfence’s firewall blocked over 86 billion password attack attempts. The volume scaled from 8.2 billion blocked attempts in January to 18.5 billion in June alone.

Wordfence Blocked Password Attackts (Sample 6-Month Trajectory)

January: 8.2 Billion

June: 18.5 Billion

Total (6 Months): 86+ Billion Blocked Attacks

Changing the default /wp-login.php URL offers little protection on its own. Attacks against legacy xmlrpc.php endpoints happen at virtually the same rate. Because XML-RPC supports system.multicall , an automated script can test hundreds of credentials in a single HTTP request, completely sidestepping standard login rate limiters.

Anatomy of an Exploit: What Attackers Look For

When attackers do target extension code, specific vulnerability types dominate the landscape:

• Cross-Site Scripting (XSS) – 52% of plugin flaws: Improperly sanitized inputs let malicious scripts run in a victim’s browser, hijacking sessions or injecting spam.
• Cross-Site Request Forgery (CSRF): Deceives logged-in administrators into executing unwanted, backend actions without their knowledge.
• SQL Injection (SQLi): Bypasses authorization to read or alter the underlying database.
• Arbitrary File Uploads / Local Files Inclusion (LFI): Allows unauthenticated attackers to upload raw PHP files and achieve full server takeover via Remote Code Execution (RCE).

While roughly half of documented flaws land in the “Medium” severity tier, 17% quality as Critical Risk, requiring zero authentication to trigger a compromise.

Neglect is the Real Vulnerability

Sophisticated zero-days rarely cause everyday site compromises. Plain neglect does:

• Outdated Software: 61% of hacked sites run outdated core files, plugins, or themes at the moment of breach.
• Dormant Plugins: Deactivating a plugin doesn’t remove its files. Attackers can target vulnerable, unindexed PHP files sitting quietly in inactive directories.
• Weak Authentication: Reused, simple passwords paired with an absence of multi-factor authentication allow credential-stuffing  bots to walk right through the front door.

Practical Blueprint to Harden WordPress

Securing a WordPress site comes down down to closing the entry points bots and automated scripts actually target:

1. Secure Authentication
   • Turn on Two-Factor Authentication (2FA) for all administrative roles; this single measure stops virtually all credential-stuffing campaigns.
   • Limit login attempts using a firewall or rate-limiting rule to curb repetitive guessing attacks.
2. Eliminate Legacy Vectors
   • Disable XML-RPC if mobile app posting or Jetpack isn’t required.
   • Add define('DISALLOW_FILE_EDIT', true); to wp-config.php to prevent attackers from editing theme and plugin files via the dashboard if an account is compromised.
3. Tighten Directory Rules
   • Set folder permission to 755, standard files to 644 , and lock down wp-config.php to 600 or 640 .
   • Disable directory indexing with Options -Indexes (Apache) or autoindex off; (Nginx).
   • Block direct PHP execution inside the /wp-content/uploads/ directory so uploaded media payloads cannot run.
4. Maintain Extension Hygiene
   • Audit the plugin list monthly. Completely delete inactive extensions rather than just deactivating them.
   • Deploy an application firewall (such as Wordfence, Cloudflare, or Sucuri) to inspect incoming payloads and filter out malicious exploitation requests before they execute.