On July 17th, Adam Kues, a cybersecurity researcher at Searchlight Cyber, armed with OpenAI’s recently released frontier model GPT 5.6-Sol Ultra and $25 of token credits, uncovered every WordPress developer’s worst nightmare: chaining two vulnerabilities in WordPress versions 6.9 through 7.0.1 allowed unauthenticated users to create an administrator account via SQL injection, allowing said administrator to upload a webshell in the form of a plugin. This exploit was dubbed wp2shell and was the first time in a decade that a critical pre-auth vulnerability was discovered in the WordPress core. Developers are familiar with critical WordPress related exploits, but almost always these came from the platform’s myriad of third party themes and plugins, not due to a security issue with the platform itself.
WordPress version 7.0.2 was released alongside the announcement of this exploit on the 17th, and three days later on the 20th of July, cybersecurity consultant Daniel Card estimated that around 15% of WordPress installs were still vulnerable to wp2shell. Given that there’s an estimated 400+ million active WordPress powered sites, that’s potentially 90 million websites that were vulnerable, endangering not just the servers that shell access is now possible on but also the users of those sites through methods such as ClickFix attacks (which have unfortunately become very common on hacked WordPress sites). Users of Reddit and Twitter quickly began reporting infections, with some more troubling claims arising that wp2shell related administrator accounts had been created before WordPress’s release of 7.0.2 via the auto-update feature.
Then came xss2shell
Two weeks later, on August 6th, WordPress released version 7.0.3 and disclosed another vulnerability in the WordPress core, this time impacting all WordPress versions from 4.7 (released in December 2016) onwards. What had been a once-in-a-decade anomaly had not even turned out to be a once-in-a-month event. This exploit was more involved than its marginally older cousin, requiring a logged-in administrator to click a link with a XSS payload that would steal an Application Password. This Application Password can then be used against the instance’s public API, once again meaning shell access via the uploading of malicious plugins/webshells. pwn.ai, the research group that discovered and disclosed the exploit to the WordPress team called it xss2shell.
Why everyone targets WordPress
In the online content management world, WordPress has been king for the past two decades. It has become cliche in the development world to cite the often repeated w3 statistic that 40% of the internet is powered by WordPress. Yet it is true that almost every web developer at some point in their education or professional career has found themselves at a wp-login.php screen for one reason or another (though hopefully not because of an email with a suspicious GET parameter at the end).
That popularity has served users and developers of WordPress well. The platform boasts a vast ecosystem of third party developers, giving the flexibility to power everything from personal blogs, to fully featured enterprise applications and e-commerce sites via plugins like WooCommerce. It can be run as a headless CMS, giving developers full control over the front-end. The core’s open-source codebase is widely recognised as one of the most mature and battle-hardened in the content management space. It, after all, has to be. Parallel to WordPress’s community of plugin and theme developers, lies a murkier world of cybercriminals, some of which are state-backed, that routinely probe the internet’s growing list of WordPress powered sites with vulnerability scanning bots. Most of these are scatter-shot in nature, running vulnerability scanners from VPSs in data-centres, or using botnets to try and bruteforce login pages. Often this is opportunistic, a cybercriminal gang looking to deploy a webshell to set up a mail spam node, cryptominer or botnet victim. The scale is simply enormous. In Q1 of 2026, the authors of the security plugin WordFence claim their plugin blocked 9.1 billion malicious requests. In that period alone, they reported that almost half a million sites were infected. Earlier this year, in July, SOCRadar uncovered WP Botnet Master, which scanned 272 million sites and stole 2.1 million credentials. But WordPress’s wide adoption and multi-purpose use opens the door to a specific type of big game hunter.
Hobbyist blogs and national governments
On top of the hobbyist blogs and mom-and-pop run ecommerce sites are a different beast of WordPress site. whitehouse.gov runs on WordPress. nasa.gov runs on WordPress. blog.gov.uk runs on WordPress. pmindia.gov.in runs on WordPress. Qatari state funded news network Al-Jazeera runs on WordPress. News Corp owned The Times (of London) runs on WordPress. National governments, federal/state governments, local/municipal governments, politically sensitive NGOs, news organisations, from every corner of the globe, run some parts of their web presence on WordPress. Some of these sites are run through WordPress’s cloud hosted VIP platform which has a specific focus on security, for instance: patches are pushed out to the VIP platform before they go out for general release. However it is just a simple reality that the majority of politically sensitive WordPress hosted sites are not hosted through this platform, nor does being a member of this platform necessarily protect you from the next AI-discovered zero-day exploit.
This is probably one of the reasons that exploit brokers Crowdfense offer the same half-a-million dollar maximum RCE bounty for the WordPress Core as they do for Apache HTTP Server or Microsoft IIS (not even a RCE exploit in PHP which powers WordPress is worth this much, coming in at only $250,000). Being able to compromise WordPress core before the WordPress team is ready to patch, gives hackers the opportunity to potentially infect tens of millions of web servers with the deployment of webshells and/or the ability to deface or gain access to the websites of high profile organisations. Even silently gaining access to these sites can lead to the exfiltration of users’ emails who can then be targeted with sophisticated spear-phishing attempts for other platforms.
Zero-days on tap
The public release of ChatGPT in late 2022 was most people’s first real exposure to a LLM, and while there were mixed opinions about GPT-3.5 and its quality, with some more snarky netizens calling it a semantic parrot and (fairly) pointing out that it couldn’t even count the number of R’s in strawberry, it was clear that something was changing; that we were entering a new world. Almost four years later, not only can the latest LLMs count the number of R’s in strawberry, they have turned finding zero-day exploits in software from something that required countless human hours and a skillset that few had, into something that a few agents can look over in parallel in a few hours if given enough of a token budget. Anthropic’s announcement of Claude Mythos twinned with the launch of Project Glasswing in cooperation with major hardware and software vendors at the start of this year was proof that we were no longer entering this new world, we are now in it. Frontier models only ever seem to get more and more intelligent with every release. OpenAI and Anthropic can’t even keep their latest models from escaping their testing sandboxes and hacking third parties or their rivals. As these increasingly intelligent models become more accessible to the general public, the risk grows of malicious actors using them to find the next wp2shell, and this time not responsibly report it before deploying their botnets to scan 400 million potentially vulnerable sites. If Adam Kues had not been Adam Kues, and instead they were a cybercriminal or hostile state actor with motives that weren’t so altruistic, how could wp2shell played out?
A victim of its own success
This issue is not specifically the fault of WordPress as a platform. Well, the wp2shell exploit was a fault of WordPress (specifically, for shipping version 6.9 whatever that introduced the exploit in the first place). Xss2shell was a fault of WordPress, that vulnerability had been there for almost ten years. But the targeting of the platform isn’t; WordPress is simply a victim of its own success. It is the platform to target if you want saturation, and thus if you are a developer who adopts the platform, you must take into account that your site will be targeted and simply having WordFence, watching your plugins and themes carefully and keeping auto-updates on will not be enough to actually protect you. That is not to say that alternatives necessarily are more secure, Drupal went through three Drupalgeddon’s in the 2010s, many years before any of these specific agentic issues were a concern. Drupal has since, like every major platform, had several security related patches that relate to AI discovered CVEs. On the other hand, perhaps WordPress being open source and as popular as it is drives more interest from security researchers, hardening the codebase by finding exploits before malicious actors do via agentic research.
There is no easy route forward
I think it is here we can say that, as developers, there’s no easy route forwards. There is basic hardening we can do on our end, for example utilising a Web Application Firewall like that offered by Cloudflare should now be considered essential (if it was not already). Perhaps patching can no longer be something that is fully automated and instead requires developers reading each individual non-security related patch note and determining in their own judgement, whether or not the new features being added are worth the security risk of integrating. Platforms should develop fully transparent security researching of their codebases themselves and publically release it. Finally, we should start thinking about when rather than if major platforms like WordPress get hit by a wp2shell moment by a malicious actor, and what policies and procedures we have in place to react to that when it happens.