A critical WordPress Core security chain is being attacked at internet scale, placing unpatched sites at risk of administrator takeover and remote code execution.
The campaign centers on two flaws disclosed on July 17, 2026: CVE-2026-60137, a SQL injection issue in WordPress query handling, and CVE-2026-63030, a REST API route-confusion bug. Security researchers call the combined chain wp2shell. An attacker does not need a password, a vulnerable plugin, a compromised theme, or a click from an administrator.
WordPress released emergency fixes in versions 7.0.2, 6.9.5, and 6.8.6. The project took the unusual step of forcing automatic updates across affected installations. That response reflected the severity of the threat and the size of the exposed ecosystem.
Attackers moved faster than many site owners. Patchstack saw the first real exploit attempts about 90 minutes after the public release. Wordfence later reported blocking more than 11 million attempts aimed at the chain. Those figures represent blocked requests, not 11 million confirmed breaches, but they show how fast a public patch can become a global attack map.
WordPress is used by 41.2% of all websites measured by W3Techs as of July 31, 2026. The vulnerable branches reached tens of millions of installations. That scale turns one Core flaw into a threat for publishers, stores, local governments, membership sites, agencies, and small businesses at the same moment.
The incident follows the same machine-speed pattern seen in the recent autonomous AI cyberattack: discovery, adaptation, and exploitation now unfold faster than traditional patch cycles were built to handle.
The Wp2shell Chain Bypasses The Usual WordPress Weak Point
Most large WordPress incidents begin in a plugin or theme. Wp2shell is different. The vulnerable code sits inside WordPress Core.
The first flaw affects the way WordPress handles an author-exclusion query. Under certain conditions, attacker-controlled input can reach a database query without the expected sanitization. That creates a path for an unauthenticated SQL injection.
The second flaw affects the REST API batch endpoint. A mismatch between request validation and request execution can let hostile input reach a handler under rules meant for a different request. Chaining the two weaknesses can expose database information, support creation of a rogue administrator account, and lead to code execution through normal administrator features.
The chain matters since it removes several barriers that often slow a WordPress attack. The attacker does not need to guess credentials. The site does not need a rare extension. The administrator does not need to open a malicious attachment. A public-facing site on an affected version can be enough.
| WordPress Branch | Exposure | Patched Version | Required Action |
|---|---|---|---|
| 7.0 through 7.0.1 | Full wp2shell chain | 7.0.2 | Update and inspect the site |
| 6.9 through 6.9.4 | Full wp2shell chain | 6.9.5 | Update and inspect the site |
| 6.8 through 6.8.5 | SQL injection flaw only | 6.8.6 | Update and review logs |
| Earlier than 6.8 | Not affected by these two CVEs | Move to a supported branch | Check for separate known flaws |
| WordPress 7.1 beta | Both flaws in early beta builds | 7.1 beta 2 or newer | Update test environments |
The full remote-code-execution path affects WordPress 6.9 and 7.0 branches. Version 6.8 lacks the route-confusion weakness but still carries the SQL injection bug. Older branches are not affected by this chain, though running obsolete WordPress software creates separate security exposure.
Attackers Needed Only Ninety Minutes
The exploitation timeline may be the most disturbing part of the incident.
WordPress released the fix on July 17. Security teams could compare the patched code with the vulnerable version and infer what had changed. Patchstack recorded attack traffic about 90 minutes after the release, roughly three hours after the corrective code first appeared in the public development repository.
That gap gave defenders almost no breathing room.
Within days, Patchstack had blocked more than 65,000 attempts from over 1,500 source IP addresses. The traffic came from many cloud and virtual-server networks rather than one obvious botnet. That pattern suggests a mix of researchers, mass scanners, criminal operators, and existing malware crews adding the new technique to automated systems.
Wordfence’s larger customer network recorded more than 11 million attempts by July 29. The company said the figure came from customers protected by its premium firewall rule, a fraction of its total user base. The real internet-wide volume is likely higher.
The official WordPress security release urged immediate updates and enabled forced background patching. Site owners should still confirm the patch completed. Automatic updates can fail through file-permission problems, disabled update settings, hosting controls, custom deployment systems, or a site that was already compromised.
Millions Of Sites Sit Behind One Shared Codebase
WordPress became the dominant content-management system through open access, low deployment costs, a vast extension market, and support from nearly every major hosting company. The same reach creates a concentrated target.
W3Techs measured WordPress on 41.2% of all websites and 59.1% of sites using a known content-management system on July 31. WordPress said tens of millions of installations moved to version 7.0 during its first week. Version 6.9 remained widely deployed across hosted and self-managed environments.
That does not mean every WordPress site was vulnerable on July 17. Sites on older branches lacked the full chain, many hosts patched clients automatically, and forced updates moved a large share of installations to fixed builds. The exposed population was still measured in millions during the earliest attack window.
A small business may see one website. Attackers see a standardized fleet. The same request can be sent across domain lists, hosting ranges, search-engine indexes, and previously scanned WordPress targets. Automation lets a criminal crew test thousands of sites before a human administrator reads the release notice.
The economics strongly favor the attacker. One working exploit can be reused. One compromised site can host spam, redirect visitors, steal checkout data, spread malware, create phishing pages, or become part of a larger botnet.
A New Administrator Account Is The Red Flag
The public attack chain can end with a newly created administrator account. That makes the WordPress user list one of the first places owners should inspect after patching.
An unknown administrator may use a generic name that blends into maintenance work. Attackers can create accounts that resemble hosting support, backup tools, security services, or a former employee. Email addresses may use familiar WordPress language to avoid attention.
A rogue account is not the only sign. Attackers with administrator access can upload a malicious plugin, change theme files, schedule hidden tasks, alter database records, inject redirect code, or add server-side backdoors outside the WordPress dashboard.
| Compromise Signal | Why It Matters | Response |
| Unknown administrator user | May mark successful account creation | Disable the account and preserve evidence |
| New or unfamiliar plugin | Can carry a web shell or persistent access | Quarantine files and compare against clean copies |
| Modified Core files | Suggests post-exploitation tampering | Replace Core with verified files |
| Unexpected scheduled tasks | Can restore malware after cleanup | Inspect WordPress cron and server cron |
| Redirects or injected scripts | May send visitors to scams or malware | Take the site offline for controlled cleanup |
| New database users or changed credentials | Signals deeper server access | Rotate database, hosting, SSH, and SFTP secrets |
Deleting one suspicious account is not a complete cleanup. An intruder may have placed several access paths across the database, file system, hosting panel, or scheduled-task layer.
Patching Stops The Entry Point, Not An Existing Intruder
Updating to WordPress 7.0.2, 6.9.5, or 6.8.6 closes the known Core weaknesses. It does not remove malware installed before the update.
A site that remained exposed after July 17 should be treated as potentially compromised, especially if logs show traffic targeting the REST API batch route or unusual author-query parameters. Administrators should review users, plugins, themes, Core file integrity, recently changed files, scheduled tasks, access logs, and hosting credentials.
The strongest recovery path begins from a known-clean backup created before the first suspicious activity. Restoring a backup without patching simply reopens the same door. Restoring after patching can still leave stolen credentials valid, so secrets tied to WordPress, the database, SFTP, SSH, hosting accounts, email, payment services, and API integrations need rotation.
The Wordfence wp2shell analysis reported over 11 million blocked attempts and described the chain as the first critical unauthenticated remote-code-execution flaw in WordPress Core in nearly a decade. Its core advice is simple: firewall protection can reduce exposure, but patching remains the real fix.
Forced Updates Reduced The Damage
WordPress’s forced-update decision deserves attention. Open-source projects often rely on administrators or hosting companies to apply patches. That model breaks down when exploitation begins within hours.
Forced minor-version updates let the WordPress project move fixed code across a huge install base without waiting for every owner. Managed hosts can apply the same patch centrally across thousands of customers. Those systems probably prevented a far larger compromise wave.
The response has limits. Some organizations disable automatic updates for testing or compliance reasons. Some sites run custom deployment pipelines. Some servers lack correct file ownership. Some agencies maintain abandoned sites no one actively monitors. Those installations become the long tail attackers keep scanning after the headline fades.
Security teams should verify versions from the server or command line rather than trusting an old dashboard screenshot. They should check every production, staging, development, and forgotten subdomain installation. A patched main site does not protect an abandoned copy under a testing directory.
CISA Put Both Flaws On The Exploited List
On July 21, the U.S. Cybersecurity and Infrastructure Security Agency added both WordPress flaws to its Known Exploited Vulnerabilities catalog. Inclusion means CISA found evidence of exploitation outside controlled research.
Federal civilian agencies received remediation deadlines, but private organizations should read the catalog as a priority signal. CISA’s list is built for weaknesses attackers are using now, not theoretical bugs that may matter later.
The listing confirms that the response window has closed. This is no longer a question of whether criminals will weaponize wp2shell. They already have.
The Plugin Problem Has Not Gone Away
Wp2shell is unusual since it lives in Core, but the wider WordPress threat remains dominated by extensions.
Wordfence counted 223 newly disclosed vulnerabilities across 175 plugins and six themes during the week of July 20 through July 26. The week before brought 75 disclosures across Core and 68 plugins. A fully patched Core installation can still fall through an outdated plugin, abandoned theme, exposed backup, weak credential, or compromised hosting account.
Site owners need one inventory covering Core, plugins, themes, server software, PHP, the database, and third-party integrations. A plugin that is installed but inactive can still leave vulnerable files on the server. An old staging copy can expose the same customer records as the production site.
Security does not end at the WordPress update screen. The update screen is one layer in a larger operating process.
The WordPress Attack Window Has Collapsed
The old patch cycle assumed administrators had days or weeks to test and deploy a fix. Wp2shell cut that period to about 90 minutes.
Attackers now monitor public code changes, compare versions automatically, generate test cases, and launch broad scans through rented cloud infrastructure. AI coding systems can shorten the time needed to interpret a patch and produce exploit logic. Defensive teams use the same tools for detection and triage, creating a race measured in minutes.
The right response is operational rather than reactive. Security updates need automated deployment where possible, verified backups, file-integrity monitoring, least-privilege access, central logs, and a tested incident plan. Owners who wait for visible damage may discover the attacker has been present for days.
Wp2shell shows what happens when a flaw in shared internet infrastructure meets industrialized exploitation. WordPress moved fast, security vendors blocked millions of attempts, and forced updates reduced the exposed population. Unpatched sites remain valuable targets. The deciding factor is no longer whether a patch exists. It is whether the patch reached every copy before the scanners did.
