Two Serious WordPress Security Vulnerabilities in Three Weeks: What Should Website Owners Know?
These weren’t just another set of bugs in some random plugin. In the summer of 2026, two serious attack chains were fixed in WordPress’s own software within a short period of time—and in both cases, the end result could have been the execution of code on the server.
On July 17, WordPress 7.0.2 was released, addressing two security issues. When combined, these issues created wp2shell—a chain of attacks that allowed remote code execution without requiring a user account. The issue was so serious that WordPress triggered forced automatic updates on affected sites. See the WordPress 7.0.2 security release.
Less than three weeks later, on August 6, WordPress 7.0.3 was released—this time with 12 security fixes. Among them was a login page vulnerability dubbed “XSS2Shell,” which, under the right conditions, could also lead to code execution on the server. See the WordPress 7.0.3 security release.
Quick Overview
July 17
WordPress 7.0.2 / wp2shell
The attack chain did not require a WordPress account or a vulnerable plugin.
August 6
WordPress 7.0.3 / XSS2Shell
A vulnerability on the login page could have led to a server takeover in the event of a targeted attack.
What should I do?
Update and check the site
Enable auto-update, check the version, and, if necessary, check for any signs of compromise.
wp2shell and XSS2Shell – two different attack scenarios
wp2shell – an attack without an account
- Prerequisite: No account or plugin is required
- User action Not required
- Result: Remote code execution on the server
- Risk: Very High
- Automation Potential: High
wp2shell exploited a combination of two WordPress Core vulnerabilities. The most significant difference from XSS2Shell was that the attacker did not need to perform any administrative actions. According to Searchlight Cyber, the chain worked on a default installation without any plugins. Read the analysis of wp2shell. Patchstack also confirmed actual attack attempts after the fix was released. Read Patchstack’s analysis.
XSS2Shell – requires user interaction
- Prerequisite: Access to the Login Page
- User action Required (e.g., opening a specially crafted page)
- Result: Server takeover in a targeted attack
- Risk: High, more targeted
- Automation Potential: Limited – Requires User Intervention
XSS2Shell began on the login page. A complete server takeover could not be achieved with just a single anonymous request—according to the WordPress advisory, it required a chain of social engineering attacks. See the official advisory. The impact of a successful attack could be as severe as that of wp2shell, but mass automation is more difficult.
WordPress 7.0.3 fixed a total of 12 security issues
XSS2Shell received the most attention, but it wasn’t the only issue fixed in version 7.0.3. The official WordPress security release lists the following fixes:
- A pre-auth reflected XSS vulnerability on the login page, which could lead to the execution of PHP code if a suitable string was used – reported by the pwn.ai team (XSS2Shell).
- Contributor+ stored XSS in posts via the emoji settings element – reported by Asaf Mozes (amosec).
- “Contributor+ Stored XSS” in the Post Content block – reported by N05ec@LZU.
- Contributor+ Stored XSS in Quick Edit on high-traffic sites – reported by Naveen S and Ajmal Moochingal.
- Contributor+ stored XSS in the “Post Date” block – reported by Alex Concha of the WordPress security team.
- The problem of privilege escalation in Multisite when users register on networks – reported by Aikido Security.
- A data leak from the “Latest Comments” block involving comments on password-protected posts—as reported by Ehtisham Siddiqui of the WordPress security team.
- Counting post slugs – reported by HDWSec.
- Leak of comment notes in comment feeds – reported by Elio Gubser.
- Author+ CSS injection via bypassing the secure CSS attribute filter – reported by Anthropic.
- Bypassing the email address verification process – reported by Omar Hasan.
- A vulnerability in SSRF URL validation that allowed queries to be sent to link-local address ranges—reported by Andrew Mohawk along with several other reporters.
These vulnerabilities do not mean that the website was necessarily compromised. For the website owner, it is more important to know whether the version they are using includes these fixes.
Why are these kinds of errors being found faster and faster?
In both cases, AI-based security research played a significant role.
Adam Kues, a researcher at Searchlight Cyber who discovered wp2shell, used GPT-5.6 Sol Ultra along with up to four AI agents to analyze the WordPress source code. According to his description, the complete exploit was ready in just over ten hours, and he estimated the proportional cost of the AI’s computational resources at approximately $25. Read the researcher’s own description.
That doesn’t mean that anyone can discover a new WordPress security vulnerability for $25. The researcher himself spent the next day figuring out the chain of events and reporting it to WordPress.
AI does not necessarily cause more security vulnerabilities. It makes it much faster to find existing vulnerabilities and link them together—and shortens the time between when a vulnerability is disclosed and when it is exploited on a large scale.
Patchstack has also described how AI has increased both the number of bugs found and the number of reports requiring review. Read Patchstack’s overview.
For this reason, when it comes to WordPress security, it is not only updates that are becoming increasingly important, but also how quickly critical updates are addressed.
Should I panic?
No—there’s no need to panic. But you shouldn’t put off security updates for weeks on end. It depends on where you are right now:
- WordPress has been updated. The risk is significantly lower. Continue with your regular maintenance.
- The updates haven’t been applied yet. Apply them as soon as possible and verify which WordPress version the site is actually running.
- There’s already suspicious activity on the site. Simply updating isn’t enough—check your logs, users, and files.
Updates are part of normal WordPress maintenance. The problem arises when critical security patches are not installed or it is unclear whether the vulnerable version has already been exploited.
Was my WordPress site vulnerable to wp2shell or XSS2shell?
WordPress versions 6.9.0–6.9.4 and 7.0.0–7.0.1 were primarily affected by the full wp2shell attack chain. If a site was running one of these versions around July 17, 2026, and was accessible via the internet, it’s worth checking for signs of compromise in addition to updating the software.
The XSS2Shell vulnerability was fixed in WordPress 7.0.3, and the same fix was also applied to older branches that receive security updates. The risk depended more on whether administrators were logged in and could fall victim to targeted social engineering—not on whether a bot could take over the site with a single request.
If you don’t know the exact version or whether the forced/automatic update was successful, treat the site as potentially vulnerable until the version has been verified..
What should a WordPress website owner do now?
Right away
- Make sure you are running WordPress version 7.0.3 or later (or a patched version of the corresponding branch).
- Turn on automatic security updates for Core.
- Check in the admin panel to make sure the version has actually been updated.
Check
- If the site was vulnerable during the wp2shell incident: unknown admins, application passwords, new plugins, unexpected PHP files.
wp-config.php,.htaccessand server logs.- Verify that the website can actually be restored from a backup.
Going forward
- Don’t rely solely on security plugins for security—updates to Core and plugins matter more.
- For business-critical websites, test major updates in a test environment first.
- Don’t check for security updates only once a month—attack attempts begin quickly after a critical vulnerability is discovered.
When the website was running on a vulnerable version for some time
Simply updating WordPress may not be enough. A security update patches the vulnerability but does not remove any potential compromise that occurred prior to the update. It’s worth checking at least the administrator accounts, application passwords, modified plugins and files, the integrity of WordPress Core, and, if possible, the server logs.
If you don’t have someone who regularly monitors WordPress updates, vulnerabilities, and backups, take a closer look at our WordPress maintenance service.
Is WordPress less secure now?
WordPress itself didn’t suddenly become more vulnerable overnight—what has changed is the pace at which security vulnerabilities are discovered and exploited. wp2shell demonstrated just how far an anonymous attack can go; XSS2Shell, in turn, showed that even a vulnerability on the login page can lead to a server takeover in the case of a targeted attack.
The problem isn’t just how many security vulnerabilities are found, but how quickly time passes from the discovery of a vulnerability to its practical exploitation. AI tools speed up the analysis of large codebases—this helps find and fix vulnerabilities sooner, but it also shortens the time the owner has to deploy a security patch. Therefore, it’s no longer worth waiting weeks for critical security updates.
Could your WordPress site be affected?
If your WordPress site has been running on an outdated version in recent weeks, or if you’re not sure whether security updates were installed on time, we can check your WordPress version, file integrity, administrator accounts, and any signs of compromise.
