WordPress security in 2026: AI, wp2shell and the race to patch

WordPress has had an unusual few weeks. On July 17, the team released version 7.0.2 to fix a pair of WordPress Core vulnerabilities that could be chained together into a complete, unauthenticated remote code execution attack. No account needed. No vulnerable plugin. A stock WordPress installation running an affected 6.9.x or 7.0.x version was enough. Searchlight confirmed the full attack had no preconditions and worked on a default install with nothing added. WordPress considered it serious enough to force automatic updates on affected sites.

Patchstack describes the fix as being committed to WordPress trunk around 1.5 hours before the public release, which effectively started the disclosure clock. The first genuine exploitation attempts appeared approximately three hours after that commit, or around 90 minutes after the public release.

The 6 August WordPress 7.0.3 security update arrived three weeks later with twelve more Core vulnerabilities: a pre-authentication XSS on the login screen with a potential path to PHP code execution, stored cross-site scripting in several blocks, privilege escalation, SSRF and a handful of information disclosure issues.

For WordPress Core, which typically logs very few serious vulnerabilities in a given year, that is a bad run. It's also happening at a point when AI-assisted vulnerability research has moved rapidly into the mainstream.

The wp2shell WordPress vulnerability

Most WordPress vulnerabilities are not in WordPress itself. They are in plugins and themes. Patchstack recorded 11,334 new vulnerabilities across the WordPress ecosystem in 2025, a 42% year-on-year increase, but 91% were in plugins and 9% were in themes. There were just six Core vulnerabilities that year, all classified as relatively low priority.

The wp2shell incident broke that pattern.

WordPress 7.0.2 patched two Core vulnerabilities. CVE-2026-60137 was a facilitated SQL injection involving the author__not_in parameter of WP_Query. On its own, the flaw would ordinarily require another code path, such as a plugin or theme, to pass untrusted input before it becomes exploitable; it is not directly reachable through Core alone. CVE-2026-63030 was a logic flaw in the REST API batch processor at /wp-json/batch/v1. The batch-route vulnerability was what made CVE-2026-60137 exploitable through Core as part of the wp2shell chain.

Searchlight Cyber researcher Adam Kues demonstrated that combining the two vulnerabilities allowed a completely unauthenticated attacker to create an administrator account and execute arbitrary PHP code. No plugins. No existing account. No other precondition. The attack worked against a standard WordPress installation running an affected version. The credits reflect how the chain actually came together: the standalone SQL injection in CVE-2026-60137 was credited by WordPress to TF1T, dtro and haongo, while Kues was credited specifically for identifying the REST batch-route confusion and its combination with the SQL injection into a chain that reached administrator access and remote code execution.

Affected versions spanned WordPress 6.9.0 through 6.9.4 and 7.0.0 through 7.0.1. WordPress 6.8.0 through 6.8.5 was vulnerable to the SQL injection but not the complete chain. Earlier versions were not affected.

WordPress forced automatic updates on affected installations, something the team does rarely. The official release announcement cited the severity directly.

The 90-minute window

Ninety minutes is not much time for a team running a standard maintenance schedule.

Patchstack reports that the fix was committed to WordPress trunk around 1.5 hours before the public release of 7.0.2. Anyone monitoring the repository could compare patched and unpatched code from that point and begin working on an exploit. Patchstack observed the first genuine exploitation attempts approximately 90 minutes after the public release, or roughly three hours after the trunk commit.

In the days that followed, Patchstack blocked more than 65,000 exploitation attempts against confirmed vulnerable sites from more than 1,500 unique IPs. These were blocked attempts, not successful compromises. The majority of that activity was SQL injection validation and reconnaissance: automated systems probing for vulnerable installations. Only a small cluster of attempts ran the complete privilege escalation chain. Wiz separately reported successful exploitation resulting in malicious plugin uploads and persistent PHP webshells on compromised servers.

On July 21, four days after the patch, CISA added CVE-2026-63030 to its Known Exploited Vulnerabilities catalogue. Its classification was unambiguous: exploitation active, automatable, technical impact total.

Ninety minutes is not a meaningful window for most teams running conventional maintenance schedules. Weekly or monthly update cycles are common for routine maintenance, and that cadence is reasonable for non-security work. For an actively exploitable WordPress security vulnerability that attackers are already scanning for, it is not.

Patchstack's 2025 data puts the weighted median time to mass exploitation at five hours for vulnerabilities attracting significant attack traffic, with roughly half of high-impact vulnerabilities seeing attempts within 24 hours. The wp2shell timeline was faster than that median, but not an outlier in kind.

The WordPress 7.0.3 vulnerabilities

The 6 August 7.0.3 security update covers a wider range of risk levels than the July release. The headline CVE, CVE-2026-64638, is pre-authentication reflected XSS on the login screen with a potential path to PHP code execution. Which, after wp2shell, is the kind of language that can make a release look more alarming than it is.

Unlike CVE-2026-63030, which an anonymous attacker could fire at any exposed WordPress installation, the 7.0.3 XSS vulnerability requires an attacker to persuade an administrator to click a crafted link. The XSS then operates within that administrator's browser session. That is still a real attack, and for a high-value target it deserves to be taken seriously. But the conditions required are meaningfully different from a pre-auth RCE requiring no victim interaction.

The other eleven vulnerabilities cover stored XSS in the Post Date block, Post Content block, emoji settings, and Quick Edit on large-user sites; privilege escalation on Multisite installations with user registration enabled; three information disclosure issues affecting comments on password-protected posts, post slug enumeration, and disclosure of notes in comment feeds; a CSS injection bypass; an account security issue in email confirmation flows; and an SSRF vulnerability in URL validation.

Seven of the twelve fixes have been backported to affected WordPress branches as far back as version 4.7. WordPress 4.6 and earlier no longer receive security updates. The fact that seven of the twelve fixes reach that far back gives some indication of how long parts of this code have been in production.

As of 7 August 2026, neither WordPress nor Patchstack is reporting mass exploitation of the WordPress 7.0.3 vulnerabilities comparable with wp2shell. The risk is real, and updating is the right response. The urgency is different.

How AI fits into this

The July vulnerability was not just a serious security incident. It was also a concrete example of what AI-assisted security research can now produce.

Kues used GPT-5.6 Sol Ultra to work through the WordPress Core codebase, directing the model to combine the batch-route confusion, the SQL injection flaw and a complex privilege-escalation chain. It produced a working exploit in just over ten hours. Kues then spent the following day understanding what the model had actually done before he could prepare a responsible disclosure. On cost: he was using a $200 subscription and estimated the experiment consumed roughly half of his weekly usage allowance, which he calculated at a pro-rata cost of around $25. That is not a direct compute bill, but it gives a reasonable sense of what this kind of AI-assisted security research can now cost. For context, Kues noted that exploit brokers advertise and pay up to $500,000 for this class of WordPress RCE.

Kues selected the target, framed the research prompt and steered the model through subsequent stages. The ten hours covers what it took to generate the chain. Understanding what the model had actually produced, and preparing a responsible disclosure, took another day on top of that.

It wasn't scanning for a single bad line of PHP. It was holding multiple components in view at once, tracing how a flaw in one mechanism could combine with a flaw in another to produce something neither could achieve on its own. That is the kind of work that used to take a specialist a long time.

Two of the WordPress 7.0.3 credits are worth noting: one vulnerability is officially attributed to Anthropic, and another to pwn.ai, an autonomous AI security testing platform.

The broader pattern in vulnerability research

Wordfence runs a bug bounty programme for WordPress vulnerabilities and began tracking whether researchers reported using AI in their submissions from late November 2025. At the start of its full tracking period, approximately 16% of submissions involved some form of AI assistance. By March and April 2026, that figure had reached approximately 66%.

Over the same period, the total volume of vulnerability submissions to Wordfence increased by 453%. That growth has been significant enough that Wordfence has itself introduced a multi-agent AI pipeline to help triage the volume of incoming reports.

More AI-assisted discovery means more reports, more patches and more public disclosure, which gives automated scanners cleaner, faster targets to work from. The 65,000 blocked attempts Patchstack observed came from conventional scanning and exploitation infrastructure, not AI agents. AI helped produce a working exploit chain during the research phase; the subsequent attack traffic was separate, running on the kind of automated infrastructure that moves quickly once a vulnerability is public and understood.

The UK's National Cyber Security Centre addressed this directly. In a blog post published on May 1, 2026, NCSC CTO Ollie Whitehouse described AI's "ability to exploit technical debt at scale and at pace" and recommended that organisations prepare to install updates faster, more frequently and at greater scale. His expectation is that years of accumulated insecure code, across commercial, proprietary and open-source software alike, will be uncovered much more quickly than before.

Does this mean WordPress has become less secure?

Historically, WordPress Core has been relatively stable from a security standpoint. The sharp increase in Core releases this summer is unusual, but it is arriving at the same time that AI is lowering the cost and time required to analyse large codebases. Software that was hard to audit thoroughly before becomes considerably more auditable when a capable model can work through it in hours.

AI-assisted research is clearly contributing to more WordPress security vulnerabilities being found and reported in 2026. Whether that reflects accumulated flaws being surfaced faster, a genuine deterioration in software quality, or some combination of both, the available figures don't say. The NCSC's framing leans toward the former, but it doesn't settle the question. It is also happening against a wider backdrop in which WordPress's market share has begun to decline after years of remarkable stability.

Getting there means a period where disclosure volume climbs, exploitation windows shrink, and teams are running maintenance schedules that weren't built for either.

Patchstack's 2025 pentesting studies found that hosting-level WAFs blocked only 12% of WordPress-specific vulnerability attacks in one test, and 26% in a broader one. Those figures come from a specific research context and shouldn't be read as a universal rate across all WAF deployments, but they do suggest the margin for delay in patching is thinner than many teams assume.

Keeping up with WordPress maintenance

Sites running unsupported or end-of-life WordPress versions cannot receive new security fixes. If a vulnerability is found through AI-assisted analysis in a codebase that goes back to version 4.7, a site running an unsupported branch has no patch coming. The NCSC specifically identifies legacy software that cannot be patched as a problem in the expected vulnerability patch wave.

Automatic Core updates deserve reconsideration where teams have disabled them. The usual concern is that an automatic update could break something. That is a real risk, and staging environments and proper testing workflows exist partly to manage it. For security updates specifically, though, the calculation has shifted. A 90-minute exploitation window leaves little room for a manual response cycle.

Plugin and theme hygiene remains important. Patchstack's 2025 figures put 91% of WordPress vulnerabilities in plugins, 9% in themes, and just six in Core. Plugins and themes remain where the overwhelming majority of disclosed WordPress security vulnerabilities are found.

In Patchstack's 2025 dataset, 46% of vulnerabilities had not received a developer fix by the time of public disclosure. For those, the options are virtual patching or mitigation at the network level, removing the affected component, or waiting for a developer fix. Knowing exactly which plugins and versions are running on a site is the prerequisite for making any of those calls. Reliable access to those updates matters too, which is one reason the WordPress and WP Engine dispute had implications beyond industry politics.

Ad-hoc update schedules and processes that rely on someone remembering to check were always imperfect. When exploitation can begin within hours of a patch going public, they leave too much room for error.

Where vulnerability research is heading

Once a working exploit exists, conventional infrastructure can scan for vulnerable sites and attempt exploitation at scale within hours. The wp2shell campaign showed that clearly enough.

The gap between source code and working exploit has shortened considerably. A researcher with access to a capable model and some domain knowledge can now produce security research that would previously have required a significant investment of specialist time. There is little sign of that changing; Wordfence expects human researchers to be increasingly AI-assisted as a matter of course.

Know exactly which plugins, themes and Core version are running on each site, apply security updates as soon as they are available, and don't let Core releases queue behind a monthly maintenance window.

If you're managing sites for clients, or running anything that handles sensitive data or transactions, it's worth checking whether security updates are actually reaching production as fast as they should be.

If you'd like to talk through what that looks like for your setup, we're happy to help.