Hackers are actively exploiting two recently patched WordPress security flaws, putting sites still running older versions at risk of full remote takeover. Cybersecurity firms Patchstack, Hexastrike, and WatchTowr confirmed in-the-wild exploitation on July 20, 2026, three days after WordPress released version 7.0.2 to address the vulnerabilities (TechCrunch).

The security release, published July 17, patched one critical-severity issue and one high-severity issue. One of the patched flaws was an SQL injection vulnerability, a type of attack where hackers slip malicious database commands into a website's input fields (WordPress.org). The critical bug, dubbed WP2Shell, was discovered and reported by Adam Kues of cybersecurity firm Searchlight Cyber. When paired with the second patched vulnerability, WP2Shell enables unauthenticated remote code execution, meaning an attacker can run arbitrary commands on the server with no login credentials (TechCrunch).

Public exploit code for the WP2Shell vulnerability chain appeared on July 19, lowering the technical skill required for attackers to compromise unpatched installations (SecurityAffairs). The combination of published exploit code and active scanning creates a narrow window for site operators still running older versions.

Vulnerable versions span WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1. According to WordPress official statistics, more than 400 million websites run these versions. WordPress enabled forced updates where possible after releasing 7.0.2, though the mechanism's reach depends on hosting environment configurations (TechCrunch).

Cybersecurity consultant Daniel Card sampled approximately 4,200 WordPress websites and estimated that less than 15% remain vulnerable. Extrapolating that percentage to the total WordPress install base, he projected roughly 90 million sites could still be exposed. Cloudflare has begun blocking attacks targeting the vulnerable versions, providing a network-level mitigation layer for sites behind its infrastructure (TechCrunch).

Automattic and WordPress.org did not immediately respond to TechCrunch's request for comment (TechCrunch).

Also in July 2026, the WordPress security team introduced a tool called Zizmor into the Gutenberg repository to tighten permissions directives and reduce attacker risk (make.wordpress.org/security). The timing aligns with broader hardening efforts around the 7.0.2 release cycle, though Zizmor's scope is limited to the Gutenberg codebase rather than the core runtime vulnerabilities under active exploitation. Gutenberg is WordPress's block-based editor system; tightening permissions there reduces certain attack surfaces but does not directly address the SQL injection and remote code execution flaws being exploited in the wild.

The attack chain is straightforward in structure but severe in outcome: an unauthenticated SQL injection vector combined with a second flaw that together yield remote code execution. For a platform powering over 400 million sites on the vulnerable versions alone, the exposure surface is considerable. Card's 15% estimate, drawn from a 4,200-site sample, offers a rough floor on the number of unpatched installations, but the absolute count, 90 million by his projection, is what matters for threat actors scanning the internet for easy targets.

The broader context here is a pattern that has played out repeatedly across content management system security. WordPress's enormous install base makes every patched critical vulnerability a race between site operators updating and attackers weaponizing exploit code. The release of public exploits on July 19, two days after the patch shipped, compresses that race considerably. Forced updates narrow the gap further, but hosting providers that disable automatic updates, custom deployments with pinned versions, and sites behind CDNs that mask the underlying installation all remain exposure points.

For security teams managing WordPress estates, the action items are direct: confirm all instances are on 7.0.2 or later, verify that forced updates applied where expected, and for sites still pending update, enable WAF rules that block the known attack signatures. A WAF, or web application firewall, sits in front of a site and filters incoming traffic for malicious patterns. Cloudflare's mitigations are already live; other WAF and CDN providers may have followed, though the verified reporting only confirms Cloudflare's involvement.