WordPress Security Vulnerability: What WP2Shell Tells Us About the Future of Website Security

24 August 2026

A Digital Dispatch by Sian Jamieson, Partnership Lead

AI Wordpress

In July, something pretty significant happened in the WordPress world. WordPress released an urgent security update addressing two vulnerabilities which, when combined, could allow an attacker to take control of a vulnerable website without needing a username or password.

That alone would be a big story. But the bit that really caught our attention was how the vulnerability chain was discovered.

Security researcher Adam Kues at Searchlight Cyber used OpenAI’s GPT-5.6 Sol Ultra to analyse the WordPress core codebase. In around ten hours, and at an estimated cost of just $25 of his subscription allowance, the AI helped uncover an exploit chain capable of turning two vulnerabilities into something considerably more serious.

Welcome to WP2Shell.

And while WordPress has patched the vulnerabilities, the bigger story isn’t really about one security incident. It’s about what happens when AI dramatically speeds up the process of finding vulnerabilities in software, for the people protecting it and the people trying to exploit it.

What was the WP2Shell WordPress security vulnerability?

WP2Shell is the name given to an exploit chain involving two vulnerabilities in WordPress Core:

CVE-2026-63030 involved the WordPress REST API batch endpoint. Under particular circumstances, requests could be processed differently from the way they had been validated.

CVE-2026-60137 involved the way a parameter within WP_Query was sanitised, creating the potential for SQL injection.

On their own, the vulnerabilities had different implications.

Combined, however, they could allow an unauthenticated attacker to achieve remote code execution (RCE) on affected WordPress installations.

In plain English?

Someone could potentially take control of a vulnerable WordPress website without first needing to log in.

And unlike many WordPress security stories, this wasn’t about a dodgy plugin downloaded from somewhere questionable.

The vulnerabilities existed within WordPress Core itself, with versions 6.9.0–6.9.4 and 7.0.0–7.0.1 theoretically exploitable.

WordPress responded on 17 July with security releases 6.9.5 and 7.0.2. Given the severity of the issue, WordPress also enabled forced automatic updates for affected installations.

Here’s where the story gets particularly interesting: AI found it

Kues wasn’t simply asking ChatGPT, “Can you find a bug in WordPress?” He created a much more controlled experiment.

The WordPress source code was provided without its Git history, preventing the model from simply comparing versions and spotting where previous security patches had been made. The model was instructed to investigate the code itself and search for a route from an unauthenticated user to remote code execution.

Multiple AI agents were used to investigate different possibilities. Within several hours, the model had identified an SQL injection vulnerability. Kues then pushed it further: could that vulnerability ultimately lead to remote code execution? Around four hours later, it had constructed the much more complicated exploit chain that became WP2Shell. The total exercise took roughly ten hours.

Kues estimated that it consumed around $25 worth of his subscription allowance. That’s quite a leap in what AI-assisted security research can accomplish.

AI is changing the economics of finding security vulnerabilities

Finding serious software vulnerabilities has traditionally required highly specialised expertise and potentially days, weeks or months of painstaking investigation. That expertise hasn’t suddenly become irrelevant.

Kues still had to define the research problem, verify what the AI produced, test its findings and responsibly disclose the vulnerabilities. AI didn’t magically press a button and fix everything.

But it dramatically accelerated part of the process, and that’s important.

AI systems can examine enormous codebases, pursue multiple lines of investigation and connect seemingly unrelated weaknesses far faster than would previously have been practical.

For security researchers, that’s incredibly powerful. Unfortunately, the same thing is potentially true for attackers.

Once AI can help identify, combine and potentially reproduce vulnerabilities at speed, the time between a vulnerability becoming known and someone attempting to exploit it could get much shorter.

And with WP2Shell, that wasn’t just theoretical. Within days of disclosure, public proof-of-concept code was available and active exploitation was being observed.

So why do we still think WordPress is one of the safest choices?

A vulnerability being discovered in WordPress doesn’t mean WordPress suddenly became unsafe. In fact, we’d argue that WP2Shell demonstrates something important about the security of mature open-source software.

WordPress is used on an enormous scale, its source code is publicly available and scrutinised by developers, researchers and security specialists around the world.

That means vulnerabilities will be found.

But that’s only half of the security story. The other half is what happens when they’re discovered.

With WP2Shell, the vulnerabilities were responsibly disclosed. WordPress developed patches, released security updates and, because of the seriousness of the issue, pushed automatic updates to affected websites.

The openness of WordPress means researchers can actively investigate it. The size of its community means there are many highly skilled people looking for problems. And its update infrastructure means security fixes can be distributed across an enormous ecosystem very quickly.

Security isn’t really about being able to promise that software will never contain a vulnerability, no responsible developer can promise that. It’s about how quickly vulnerabilities can be identified, communicated, fixed and deployed.

And WP2Shell is actually a pretty interesting example of that system working.

What did Pooka do when WP2Shell happened?

At Pooka, we have mechanisms in place to roll out security updates to multiple sites concurrently. This meant that when the security fixes became available, we were able to instantaneously protect our clients websites.

This is the type of work that we perform quickly and quietly for all of our clients, leaving them to think about the content of the site, with peace of mind about the underlying technicalities.

Your website shouldn’t rely on somebody remembering to update it

For many organisations, particularly charities and small teams, website maintenance understandably isn’t at the top of the Monday morning list. Keeping an eye on WordPress security releases probably isn’t how they want to spend their afternoon.

And it shouldn’t have to be. A website shouldn’t be something that gets built, launched and then left alone. It’s a living piece of software.

WordPress Core changes, plugins change, PHP changes, browsers change, security threats change and, as WP2Shell demonstrates, the technology being used to discover vulnerabilities is changing too.

That’s why we think there’s real value in keeping your hosting, maintenance and ongoing support with people who understand your website.

Hosting isn’t just somewhere your website lives

When we talk about Pooka’s Fully Managed Hosting, the server is only part of it. The more important bit is the ‘Managed’.

The same development team that understands how your website was built, continues looking after it. That means maintaining WordPress Core and plugins, monitoring security, keeping backups, responding to problems and understanding how changes to one part of the website could affect another.

And when something like WP2Shell happens, there is somebody whose job is to understand:

Does this affect our websites?
What do we need to do?
Has the fix been applied?
Do we need to investigate anything else?

That’s very different from simply paying for some server space.

Why keeping your developer around matters

There’s another important distinction here, updates themselves aren’t particularly exciting, you can click an update button.

Knowing when to update, what to check afterwards and what an update could affect is where experience becomes valuable.

Modern WordPress websites can include ecommerce, CRM integrations, membership systems, event booking, payment processing, bespoke functionality and connections to other platforms.

An update that protects one part of that ecosystem shouldn’t inadvertently break another. When the development team responsible for building and supporting your website is also maintaining it, they already understand those relationships.

They’re not approaching your website as a stranger when something goes wrong.

For us, that’s part of the relationship we want to have with clients. We don’t really see launch day as goodbye. It’s the beginning of looking after what we’ve built together, protecting it, and then developing it further as your needs grow.

The bigger lesson from this particular WordPress security vulnerability

WP2Shell was patched. There will be other critical vulnerabilities discovered soon after. In WordPress, plugins, server technology… And of course, on other platforms entirely.

That’s not pessimism. That’s simply the reality of maintaining software connected to the internet. What matters is whether somebody is paying attention when it happens.

For organisations, particularly those without an internal web or IT team, good hosting shouldn’t just mean that your website is online. It should mean somebody is looking after it. Monitoring it, updating it and backing it up.

And importantly knowing what to do when the digital world throws the next WP2Shell at us.