WordPress Mass Hacks of 2026: How Monitoring Warns You Early

July 24, 2026 · 7 min read

June and July 2026 were rough for WordPress: first a wave of maximum-severity plugin vulnerabilities, then a hole in core itself, dubbed wp2shell. The pattern is always the same: a patch ships, and within hours automated scanners are crawling the internet for it. Monitoring won't install the update for you, and it won't stop the attack — that's the job of the update and the WAF. But it does something just as important: it collapses "weeks of unnoticed hack" down to minutes.

What happened

wp2shell — a hole in WordPress core

Two vulnerabilities in core — CVE-2026-63030 (route confusion in a batch REST endpoint) and CVE-2026-60137 (SQL injection in WP_Query) — are limited on their own, but together give unauthenticated remote code execution. A stock install is exposed: branches 6.8.x before 6.8.6, 6.9.x before 6.9.5, and 7.0.x before 7.0.2. The patch shipped, exploitation began within hours, and a working proof of concept followed shortly after. Hacked sites turned up with web shells, malicious plugins, and injected JavaScript: fake login forms, visitor redirects to malicious pages, and credential theft.

The plugin wave and WP-SHELLSTORM

It was preceded by June's plugin carnage: six popular plugins scoring a CVSS of 9.8, actively exploited at the same time, plus a premium plugin's supply chain getting compromised to inject a backdoor administrator account. A separate story is the WP-SHELLSTORM operation: a leaked group server held a list of 1.4 million targets and thousands of confirmed compromises through plugin holes, dropping obfuscated web shells into wp-content.

The takeaway that matters for agencies and studios: the number-one cause of a hack is not "hackers" — it's an abandoned component with a known vulnerability. The gap between "an update shipped" and "the site got hacked" usually runs to weeks. In the summer of 2026, it shrank to hours.

The dangerous time gap

Throughout all of it, external monitoring shows a green checkmark. The site loads, returns a 200 OK, and the SSL is valid. A vulnerable plugin version isn't visible from outside (at best, by indirect fingerprinting). Neither is a web shell dropped into uploads — it doesn't change the storefront, it just waits for a request from whoever planted it. All of the damage lives in exactly that gap, between "you're already vulnerable" and "you've already been hacked and don't know it."

The gap can be closed from two sides: warn about a vulnerable component before the hack, and notice the signs of a hack the day it happens. We added both.

What Pingvera does now

An ordinary plugin collects the inside diagnostics: it installs from the admin dashboard, takes a reading once an hour, and sends out only verdicts. Three checks speak directly to this wave.

1. Component-to-vulnerability-database cross-check — ahead of the hack

The plugin sends us an inventory: core, plugin, and theme versions. The server cross-checks it against the WPVulnerability vulnerability database — an open aggregate of CVE, Wordfence, WPScan, and Patchstack data. If your version falls inside a known vulnerable range, a finding is raised:

• A core vulnerability (like wp2shell) — always a critical event with an immediate alert. Core vulnerabilities are rare and dangerous, and fresh ones often don't have a CVSS score yet — we don't wait for one.
• A plugin or theme vulnerability — a critical event when the CVSS is high or critical; less severe findings go into the site health report without an alert, to keep the noise down.

That's the "your version is vulnerable, update it" warning, delivered in the exact window between the patch shipping and the scanners arriving. Update the component, and the finding is gone on the next collection — the event closes automatically.

2. Web shell scan — a sign of a hack that already happened

After a break-in, an attacker drops a web shell, most often straight into wp-content. The plugin looks for the typical artifacts of the 2026 campaigns:

• an executable PHP file inside the uploads directory (wp-content/uploads) — core never puts code there, so the fact alone almost always means it was planted. A critical event;
• files named after known web shells — a critical event;
• signs of obfuscation (eval layered over base64 and similar patterns) in recently modified files — a warning in the report, not an alert: some legitimate packaged plugins do this too, so we don't raise it as an alert.

The scan runs on a strict time and file-count budget so it doesn't load the site. Only file paths go into the notification — never file contents.

3. A new administrator — a quiet marker of compromise

A common signature of a hack (and of that same supply-chain compromise in June) is creating yourself an administrator account. The plugin remembers the set of administrators and reports the appearance of a new one as a separate critical event: "A new administrator appeared — if you didn't create it, you've likely been hacked." This is a one-time notification: it fires the moment the account appears, and then closes.

All of this adds to what was already there: checksum verification of core files, detection of content substitution and redirects to a foreign domain, domain-expiry and SSL monitoring, and external uptime checks.

What's visible from outside, and what only shows up from inside

Which only reinforces the earlier point: no single layer replaces another. External checks are first to notice the site or host going down; inside diagnostics are the only ones that see a vulnerable plugin, a planted shell, or a stranger's administrator account.

Important: we don't touch your server

The connector plugin only collects and sends. There is no inbound channel: Pingvera cannot execute a command on the site, install an update, or delete a file. That's a deliberate architectural choice. Monitoring tells you about the problem fast and accurately — the site owner or their agency is always the one who updates core, cleans the shell, and rotates the passwords. That fast warning is exactly the value that's hard to overstate during a mass campaign: a day's head start on an automated scanner is the difference between "updated in time" and "explaining to the client why their site is selling someone else's products in the search results."

Frequently asked questions

What is wp2shell?

A chain of two vulnerabilities in WordPress core (CVE-2026-63030 and CVE-2026-60137) that together give unauthenticated remote code execution. Affected branches: 6.8.x before 6.8.6, 6.9.x before 6.9.5, and 7.0.x before 7.0.2. Exploitation began within hours of the patch shipping. This is a core vulnerability, not a plugin issue.

Can monitoring protect a site from being hacked?

No — updates and a WAF protect the site, monitoring warns you. It closes the time gap: it reports a vulnerable version before the hack, and catches signs of a hack that already happened the same day, instead of when traffic drops to zero.

How can you tell a site has already been hacked?

Typical artifacts of the 2026 campaigns: an executable PHP file in wp-content/uploads, files named after known web shells, a sudden new administrator, modified core files, a redirect affecting part of the traffic. All of it is visible from inside WordPress, even while the site returns a 200 OK from outside.

Does Pingvera touch the client's server?

No. The plugin collects diagnostics itself and sends out only verdicts. There is no inbound channel — we cannot execute a command, install an update, or delete a file. The site owner always does the cleanup.

Read also: WordPress health from the inside and malicious redirect monitoring.

Vulnerability data by WPVulnerability (aggregates CVE, Wordfence, WPScan, and Patchstack).

Read next: WordPress Health Monitoring: Inside and Outside · The monitoring agent that cannot be told what to do · 200 OK but Hacked: What Uptime Monitoring Misses · Server Monitoring for Web Agencies: What Matters · Check a WordPress site.