A security breach in the WordPress context means one of three things: unauthorized access to site files or the database, mass exploitation of a vulnerability across thousands of sites simultaneously, or a supply chain attack where the infection arrives through a trusted update or package. The breaches in this list qualify on at least one count. The worst qualify on all three.

WordPress powers 43% of the internet. That scale makes it the highest-value target in the history of web software. Every breach in this list triggered a permanent change in how WordPress handles security — auto-updates, plugin screening, vulnerability disclosure protocols, and the treatment of third-party libraries all trace back to specific incidents.

These five were selected by three criteria: technical severity, number of sites affected, and lasting consequence for the platform. Not all five made headlines at the time. Some are now more important in hindsight than they were when they happened.

What Counts as a WordPress Security Breach?

A breach is not a vulnerability. A vulnerability is a flaw waiting to be exploited. A breach is when exploitation happens real attacker, real damage, real sites compromised.

Three categories cover most of WordPress history:

Mass exploitation events — a single vulnerability in core, a plugin, or a bundled library, exploited across thousands of sites by automated scanners before most owners know the flaw exists.

Targeted attacks using WordPress as the entry point — a single organization’s site is compromised through WordPress, and the attackers use that access to reach connected systems containing far more sensitive data.

Supply chain attacks — malicious code reaches site owners through channels they were trained to trust: official plugin updates, package repositories, or third-party libraries bundled inside legitimate software.

All five breaches below fall into one or more of these categories.

Breach #1: The TimThumb Mass Compromise (2011)

Sites affected: Over 1.2 million Vulnerability type: Local file inclusion via flawed trusted-domain whitelist – CVE-ID: CVE-2011-4106, Attack method: Automated PHP shell upload across every vulnerable installation

What Happened

TimThumb was a PHP script that did one thing: resize images on the fly. Before WordPress built this capability into core, it was embedded in hundreds of premium and free themes and plugins. Most site owners had no idea it was there.

In August 2011, a security researcher discovered that TimThumb’s trusted-domain whitelist was trivially bypassed. The script allowed loading images from a list of approved domains — flickr.com, picasa.com, blogger.com — but the check was string-based, not domain-validated. An attacker could register blogger.com.attacker.com, pass the check, and use it to deliver a malicious PHP file that TimThumb would download and store on the server.

Once the PHP shell was on disk, the attacker had arbitrary code execution. Every command they ran was trusted by the server.

Why It Spread So Far

TimThumb’s reach came from how it was distributed. It wasn’t a plugin users chose. It was a library bundled inside themes they bought or downloaded — embedded in the package without the user knowing it existed, with no update mechanism of its own. When the patch came, theme developers had to release updates and users had to install them manually. Tens of thousands never did.

Automated scanners hit every site on the web looking for the script path. Sites compromised in the TimThumb wave received backdoors, Blackhat SEO spam injected into page content, and .htaccess redirects sending visitors to malware distribution pages.

A vulnerability in an obscure WordPress add-on script discovered in August 2011 was being used to compromise more than 1.2 million websites — and could be easily used to siphon data out of databases hosted on servers also hosting the compromised websites.

The Lesson

Third-party libraries bundled inside themes and plugins are invisible to most site owners and to most security tools. They don’t appear in plugin update screens. They don’t trigger security alerts. They age silently until an attacker finds them. TimThumb was still found on at least 56,606 websites years after the breach, including government sites.

The security industry’s response to TimThumb was to push automatic updates and plugin/theme scanning both now standard features. That response took years to fully materialize.

Breach #2: The XSS Mega-Bug That Hit Jetpack, Yoast, and Gravity Forms (2015)

Sites affected: Tens of millions collectively Vulnerability type: Cross-Site Scripting (XSS) via the WordPress comment system Attack method: Stored XSS exploitable by unauthenticated visitors

What Happened

In 2015, a critical XSS vulnerability was discovered in WordPress core specifically in how the comment system handled certain character sequences. The flaw allowed an unauthenticated attacker to inject persistent JavaScript into a site’s database through a crafted comment submission.

The downstream damage came not from the core vulnerability alone, but from how many major plugins processed comment data without their own sanitization. Jetpack, Yoast SEO, and Gravity Forms were among the affected. Because each plugin trusted that WordPress core had already sanitized input, and because the core flaw meant that trust was misplaced, the malicious payload survived into plugin-rendered output.

Stored XSS is the most dangerous form because it runs for every user who views the affected content — administrators included. A JavaScript payload that executes in an admin’s session can create new admin accounts, install plugins, or modify site files without any further interaction from the attacker.

Why It Matters More Than the Patch Number Suggests

The XSS wave of 2015 became the case study that changed how WordPress core and plugin developers thought about the division of security responsibility. The orthodox assumption had been: core sanitizes input, plugins trust core. That assumption broke down catastrophically.

After 2015, plugin developers began building independent sanitization layers. Yoast, Gravity Forms, and Jetpack each now maintain their own input validation independent of whatever WordPress core does. That redundancy is now standard practice.

The Lesson

Defense in depth applies to data flow, not just network topology. A plugin that trusts upstream sanitization has a single point of failure. A plugin that validates its own inputs has none.

---

Breach #3: The Panama Papers — A Law Firm, an Unpatched Plugin, and 11.5 million Documents (2016)

Sites affected: 1 (Mossack Fonseca — with global political consequences) Vulnerability type: Remote file inclusion via outdated Revolution Slider plugin Attack method: WordPress used as entry point to pivot into connected mail servers

What Happened

In April 2016, Mossack Fonseca — a Panamanian law firm managing offshore financial arrangements for heads of state, billionaires, and public figures — saw 11.5 million internal documents leaked to journalists. The Panama Papers is the largest data breach in journalism history at the time of its publication, comprising 2.6 terabytes of confidential client records.

The entry point was a WordPress plugin.

Wordfence analyzed Mossack Fonseca’s website at the time of disclosure and found it running Revolution Slider version 2.1.7 — a version with a well-documented remote file inclusion vulnerability, with exploitation instructions published publicly for over a year. All versions of Revolution Slider up to 3.0.95 were vulnerable. The Mossack Fonseca WordPress server’s IP address was on the same network as its mail servers.

The attack chain was lateral: gain access to the WordPress installation via Revolution Slider, read the WP SMTP plugin configuration data stored in the WordPress database in plain text — including the mail server address and login credentials — and use those credentials to access and download email archives from the connected mail server. The bulk of the Panama Papers consisted of those emails.

Mossack Fonseca’s WordPress installation was running a version of WordPress that was more than a year out of date, with a known major security flaw, running a plugin with publicly available exploit instructions, with the mail server on the same network as the web server, and with email credentials stored unencrypted in the WordPress database. Every one of those conditions was individually fixable. None were fixed.

Why This Breach Changed Everything

The Panama Papers brought WordPress security into mainstream business and legal coverage for the first time. Security professionals had been warning about plugin updates for years. Those warnings required a law firm’s offshore clientele list and a Prime Minister’s resignation to land.

The breach is cited in almost every corporate security policy that mentions WordPress. It is the evidence that an unpatched WordPress plugin isn’t just a website risk — it’s a business risk, a legal risk, and a reputational risk that reaches every system connected to the same network.

The Lesson

A WordPress site’s attack surface extends to every system on the same network segment. Credentials stored in the WordPress database are as exposed as the database itself. Separating web servers from internal systems — network segmentation — isn’t optional for organizations with sensitive data.

Breach #4: Really Simple Security — The 2FA Plugin That Bypassed Authentication (2024)

CVE: CVE-2024-10924 CVSS Score: 9.8 (Critical) Sites exposed: 4,000,000+ Vulnerability type: Authentication bypass via improper REST API error handling Attack method: Unauthenticated login as any user, including administrators

What Happened

On November 6, 2024, Wordfence researcher István Márton discovered a critical vulnerability in Really Simple Security — a plugin installed on over four million WordPress sites and designed specifically to harden login security.

The irony is structural. The vulnerability lived inside the plugin’s two-factor authentication feature. When 2FA was enabled, the plugin’s REST API endpoint for handling the 2FA onboarding flow contained a logic flaw in its check_login_and_get_user function. The function returned a WP_REST_Response error object when authentication failed — but the code that called it checked only whether a user object was returned, not whether authentication had actually succeeded. A WP_REST_Response error object satisfied that check.

The result: an unauthenticated attacker could send a crafted REST API request, trigger the error return path, and receive full authentication as any user on the site — including administrators.

The plugin is vulnerable to authentication bypass in versions 9.0.0 to 9.1.1.1. Unauthenticated attackers can log in as any existing user on the site, such as an administrator, when the “Two-Factor Authentication” setting is enabled.

The Scale of the Exposure

The really Simple Security plugin existed specifically because site owners had already decided to improve their security posture — they were using a security plugin, and many of them specifically chose it for the 2FA feature. Those users had their attack surface expanded, not reduced, by that decision.

WordPress.org enabled automatic forced updates for this plugin — a mechanism used only for the most critical vulnerabilities. The patch shipped in version 9.1.2. Sites with auto-updates received it without manual intervention.

Proof-of-concept code demonstrating this exploit was published publicly, meaning any attacker with a Nuclei template and a list of WordPress URLs could scan and exploit vulnerable sites at scale.

The Lesson

A security plugin’s code is not reviewed more rigorously than any other plugin’s code just because its function is security-related. 76% of vulnerabilities found in premium plugin components were exploitable at the point of disclosure. The category of the plugin provides no security guarantee. The quality of its code does.

Reviewing a plugin’s update history and disclosed vulnerability record before trusting it with authentication logic is not optional for high-stakes deployments.

Breach #5: The npm Supply Chain Attack — 390,000 WordPress Credentials Stolen (2024)

Sites affected: Credentials stolen from 390,000 WordPress accounts Vulnerability type: Malicious npm package posing as XML-RPC implementation Attack method: Dependency poisoning — legitimate-seeming package, malicious payload delivered via updates

What Happened

In late 2024, Datadog Security Labs and Checkmarx researchers independently identified a malicious npm package called wsa-toolkit that had been live in the npm registry since October 2023. The package presented itself as an XML-RPC implementation — a category of tool that WordPress developers commonly use for integrations.

For over a year, the package functioned as advertised. Over that period it received 16 updates — each one building credibility through demonstrated legitimacy. Then a later version introduced malicious code.

The payload ran on a timer. Every 12 hours, the malicious version would collect SSH keys, bash command history, and stored credentials from the infected environment and exfiltrate them to attacker-controlled infrastructure via Dropbox and File.io. Login credentials for approximately 390,000 WordPress accounts were stolen. Dozens of compromised systems were found mining Monero cryptocurrency.

The attack succeeded because it was patient. A package that works correctly for over a year, shipping 16 updates, earns trust from developers and from automated package audit tools. The malicious payload didn’t arrive in the original install — it arrived in an update. Developers who would have audited a new dependency they were installing did not audit an update to a dependency they’d trusted for a year.

Why Supply Chain Attacks Are Different

Every other breach in this list exploited a vulnerability in software the victim was knowingly running. This one exploited the update mechanism — the behavior site owners were trained to rely on.

Supply chain attacks are growing in frequency across the WordPress ecosystem. In June 2025, Groundhogg distributed malware to paying customers through its own official plugin update system. A year earlier, the npm attack showed the same technique applied at the developer toolchain layer, upstream of the WordPress site itself.

The combination of these vectors — plugin updates, dependency updates, and third-party library updates — means the update button itself can no longer be treated as unconditionally safe. It remains the right call to keep software updated. The threat model now includes the possibility that the update is the attack.

The Lesson

Credential hygiene across every tool in the development chain matters as much as the WordPress site itself. WordPress admin credentials stored in an environment that runs untrusted npm packages are compromised the moment the npm package becomes malicious. Treat development environments as part of the attack surface.

What are Common Vulnerabilities Across All Five Breaches

Looking at these five events together, four failure modes appear in every case:

Outdated software. Mossack Fonseca’s WordPress installation and Revolution Slider were both over a year out of date. TimThumb persisted for years past the availability of a patch. In both cases, the exploit was known and the patch existed. The update was never applied.

Third-party code with no visibility. TimThumb was invisible in theme packages. The npm package was invisible in development toolchains. Neither appeared in standard plugin audit screens. Both delivered the breach.

Trust without verification. The XSS wave of 2015 happened because plugins trusted WordPress core’s sanitization. The npm attack succeeded because developers trusted a package that had previously been legitimate. The Really Simple Security breach happened because site owners trusted a security plugin’s authentication logic. In each case, the trust was reasonable but unverified.

Network and credential sprawl. Mossack Fonseca stored email credentials in the WordPress database and put the mail server on the same network as the web server. One compromised WordPress site meant every connected system was reachable. Lateral movement after initial access turned a medium-severity web compromise into a geopolitical event.

Preventive Measures That Address These Specific security Issues

Update within hours of high-severity disclosures, not on a maintenance schedule

The median time from vulnerability disclosure to active exploitation was five hours in 2025. A monthly update schedule leaves a 700+ hour window open for every critical flaw disclosed in that period. Subscribe to vulnerability feeds from Patchstack, Wordfence, and WPScan. For CVSS 9.0+ vulnerabilities, treat the update as urgent — same-day, not next-maintenance-window.

Audit your dependency chain, not just your plugin list

TimThumb and the npm attack both lived outside the WordPress plugin screen. Run a file-system-level audit of your theme directories and custom development environments. Tools like Semgrep and npm audit surface dependencies that plugin dashboards miss. The attack surface is everything on the server and in the build chain, not just what WordPress lists.

Segment networks and never store credentials in the WordPress database

Mossack Fonseca’s breach scaled from a compromised WordPress site to a geopolitical scandal because the web server, mail server, and client document portal all shared network access. A compromised WordPress installation should have zero reachability to internal mail systems, databases containing non-WordPress data, or administrative infrastructure. This is basic network segmentation, and it is routinely absent on shared hosting plans.

Treat security plugins as code, not as trust

CVE-2024-10924 came from a security plugin. A security plugin’s authentication and firewall features are only as trustworthy as the quality of its code. Check how quickly each plugin’s developer has historically patched disclosed vulnerabilities. Patchstack and WPScan both publish this data. A plugin that took three months to patch a prior CVE will likely take three months to patch the next one.

Enable two-factor authentication — from a different plugin than the one that stores your credentials

The irony of CVE-2024-10924 is that site owners who enabled 2FA specifically for security were the ones exposed. Using WP 2FA or the Two Factor plugin alongside a separate security hardening plugin distributes the risk — a flaw in one doesn’t compromise the other.

Monitor file integrity, not just traffic

TimThumb attacks injected backdoors into server files. The npm supply chain attack modified files in the development chain. Neither generates suspicious traffic patterns before the infection is established. A scanner that checks file hashes against known-good baselines — not one that looks at network requests — catches these methods.

Frequently Asked Questions

What is the biggest WordPress security breach in history?

By data volume, the Panama Papers breach — which began through an unpatched WordPress Revolution Slider plugin at Mossack Fonseca — leaked 2.6 terabytes and 11.5 million documents in 2016. By number of sites directly exposed to compromise, the Really Simple Security vulnerability (CVE-2024-10924, 2024) affected over four million installations with a CVSS score of 9.8.

Have major websites been hacked through WordPress?

Yes. The Panama Papers breach at Mossack Fonseca is the most consequential documented example — it brought down a Prime Minister and implicated heads of state across multiple countries. The entry point was an unpatched WordPress plugin, Revolution Slider, running on the firm’s public website.

What was the TimThumb vulnerability?

TimThumb was a PHP image-resizing script bundled inside hundreds of WordPress themes and plugins. In 2011, a flaw in its trusted-domain whitelist allowed attackers to upload arbitrary PHP files to any server running the script. Over 1.2 million sites were compromised before widespread patching occurred.

What is the most common way WordPress sites get hacked?

Historically: unpatched plugins and themes. The pattern repeats across every breach in this list. The Panama Papers breach, the TimThumb mass compromise, and the XSS wave of 2015 all began with code that had available patches. The patches were never applied.

How do supply chain attacks affect WordPress sites?

Supply chain attacks deliver malicious code through channels the victim already trusts — official plugin update mechanisms, npm package registries used by developers, or third-party libraries bundled in themes. The 2024 npm attack stole credentials from 390,000 WordPress accounts by delivering a malicious payload through updates to a package that had previously been legitimate and functional.

How can I tell if my WordPress site has been compromised?

Indicators include: unexpected admin user accounts, files in wp-content/mu-plugins you didn’t place there, modified core files with timestamps that don’t match your last update, unexplained .htaccess changes, and visitor redirects to unrelated domains. Server-level file integrity monitoring catches modifications that network-based scanners miss.

Breach Timeline

Year	Breach	Entry Point	Scale
2011	TimThumb mass compromise	Bundled PHP library in themes/plugins	1.2M+ sites
2015	XSS wave (Jetpack, Yoast, Gravity Forms)	WordPress core comment system	Tens of millions of sites
2016	Panama Papers / Mossack Fonseca	Unpatched Revolution Slider plugin	1 firm, global political consequences
2024	Really Simple Security auth bypass	2FA REST API logic flaw (CVE-2024-10924)	4M+ sites exposed
2024	npm supply chain credential theft	Malicious package posing as XML-RPC tool	390,000 credentials stolen