On July 17, 2026, the WordPress team released emergency patches and triggered forced updates worldwide. The reason: a chain of two core vulnerabilities that let an anonymous attacker execute code remotely.

Key points

  • Two chained flaws allowed takeover without any account or user interaction.
  • WordPress powers more than 40% of websites, so this monoculture amplifies every flaw.
  • Less than 72 hours passed between the patch and mass exploitation.
  • Patching is not enough if intrusion already occurred; you also need to look for traces.

What happened with wp2shell?

Two vulnerabilities in WordPress core, CVE-2026-63030 and CVE-2026-60137, allowed an anonymous attacker, with no account and no user interaction, to execute remote code on a standard installation, without requiring any third-party plugin. The chain received a combined CVSS score of 9.8 out of 10.

Technically, the first flaw hijacks the REST API’s batch processing mechanism; the second is a SQL injection in core. Neither is sufficient on its own. Chained together, they turn a simple anonymous web request into full server takeover.

This is the first critical unauthenticated remote code execution vulnerability in WordPress core in a long time, a useful reminder that even the most mature, heavily audited software is never a settled matter.

The timeline, in plain terms:

  • July 17, 2026: public disclosure and patches (WordPress 6.9.5 and 7.0.2). Versions 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1 are vulnerable. Forced automatic updates are enabled.
  • Within hours: working exploit code appears publicly. The window between an available patch and mass exploitation is now measured in hours.
  • July 21, 2026: both vulnerabilities are added to CISA’s Known Exploited Vulnerabilities catalog.
  • Late July: incident response teams document a wave of compromises, including rogue administrator accounts, stealthy backdoors, and malicious plugins disguised as legitimate ones.

Why is a compromised site a business issue?

Because the consequences don’t stay within the webmaster’s scope. Theft of personal information with the obligations that follow, lost revenue, damage to search rankings built over years, a pivot point into your network, and chain liability if your site is used to attack third parties.

1. Theft of personal information, and Law 25 obligations. If your site collects data, contact forms, customer accounts, orders, newsletter sign-ups, a compromise is a confidentiality incident. If a risk of serious harm is established, you must log it, notify the Commission d’accès à l’information (Quebec’s access to information oversight body) and inform the affected individuals. A site breached silently and discovered months later makes your exposure worse: the attacker had ample time to exfiltrate data, and your failure to detect the intrusion will weigh against you when your reasonable security measures are assessed.

2. Business interruption and lost revenue. For an online retailer, a defaced or offline site means zero revenue during remediation. For a service business, it means losing your main acquisition channel.

3. Reputational and search ranking damage. Compromised sites are frequently used to host fraudulent content, phishing pages, or redirects. The result: browser blocklisting, warnings shown to your customers, and a drop in search rankings.

4. A pivot point into your network. A compromised web server can serve as a foothold: credentials stolen and reused elsewhere, attacks launched against your customers from your own domain, or cryptocurrency mining that degrades your services.

5. Chain liability. If your site is used to attack third parties, you move from victim to documented weak link.

What should you check now, even if an agency handles the site?

Five points, to demand with supporting evidence. Confirm the installed version on every site, look for signs of compromise, assume intrusion when in doubt, permanently reduce your exposure, and document the exercise.

  1. Confirm the installed version on every instance: 7.0.2, 6.9.5, 6.8.6, or later. Don’t assume the forced update worked; documented failures have been tied to customizations, caching, or nonstandard hosting setups. Check site by site.
  2. Look for signs of compromise, because patching is not enough if intrusion already occurred: unknown administrator accounts, recently modified PHP files in upload directories, unrecognized plugins, suspicious requests to the batch processing endpoint in server logs.
  3. When in doubt, assume compromise. Reinstalling from a clean source, or restoring a backup predating July 17, is the safest path, followed by rotating passwords and access keys.
  4. Permanently reduce your exposure: restrict anonymous access to the REST API where the site doesn’t need it, put a web application firewall in front of the site, remove unused plugins and themes.
  5. Document the exercise. Verification dates, versions found, and the results of your compromise check are exactly what demonstrates the reasonable diligence expected under Law 25, and by your insurer.

What’s the real lesson from this episode?

That it isn’t about this particular flaw. wp2shell will be replaced by another vulnerability, on WordPress or elsewhere. The question for an executive isn’t “did we patch wp2shell?” but “what would have triggered our response, and how quickly?”

Inventory comes first. Most affected organizations didn’t know how many WordPress sites they operated: the main site, but also the microsite for a past event, the forgotten blog, the test environment left online. You can’t protect what you don’t know you have.

The response window has collapsed. Less than 72 hours passed between the patch and mass exploitation. A quarterly update cycle, still common, mathematically leaves weeks of exposure for every critical flaw. You need a monitoring process and an emergency escalation mechanism, even a minimal one.

Detection matters as much as prevention. The costliest breaches won’t be the ones patched late, they’ll be the ones never detected. Without logging or monitoring, a backdoor can stay active for months.

How does RISS help with this?

At the intersection of technical urgency and business accountability, with an approach calibrated for SMEs: not an oversized enterprise program, but a proportionate, documented, defensible process.

  • External attack surface assessment: inventory of your internet-facing assets, sites, portals, remote access, identifying vulnerable versions and forgotten services.
  • Application penetration testing aligned with the OWASP framework: we validate, with evidence, whether your sites withstand techniques actually used in the wild, beyond automated scanning.
  • Compromise verification: when doubt exists, analysis of intrusion indicators, accounts, and suspicious files, with a factual report usable for your notification obligations.
  • Building a lasting process: monitoring vulnerabilities relevant to your environment, prioritization based on active exploitation, an emergency procedure, integration into your incident register.

FAQ

Our site is just a showcase site, with no form. Are we affected?

Yes, but for a different reason. Without data collection, the Law 25 concern eases; however, a compromised showcase site still serves as a platform for third parties: hosting phishing pages, redirects, sending fraudulent emails from your domain. The consequences are reputational and technical, with your domain ending up on blocklists, which then affects your business email.

Should we leave WordPress?

No, and that would be the wrong conclusion. What made this episode so widespread wasn’t a particular weakness in WordPress but its market share: a flaw in software that powers 40% of the web mechanically produces a huge number of victims. The same monoculture risk exists elsewhere. What matters is how fast you update, how much you reduce your exposed surface, and your ability to detect an intrusion.

How do we know if a backdoor is still active?

Signs you can spot without specialized tools: PHP files with recent modification dates in upload directories, where only images should be; administrator accounts nobody recognizes; plugins present on the site but absent from the official directory. A thorough check compares all core files against a clean installation of the same version, which reveals any tampering.

Sources