XSS2Shell: WordPress Flaw Actively Exploited – Update to 7.0.3 Now

Published on 13 August 2026

A single click on a crafted link can be enough to hand a WordPress website over to attackers. The vulnerability that became known as XSS2Shell in the WordPress core is already being actively exploited, according to an official warning from the Canadian Centre for Cyber Security. It carries the identifier CVE-2026-64638, is rated "high" with a CVSS score of 8.9, and affects not just a single plugin but the WordPress core itself. Every WordPress installation prior to version 7.0.3 is affected. If you run a WordPress site, you should act now.

What happened?

Security researchers at the vendor pwn.ai discovered a vulnerability on 26 July 2026 that they dubbed XSS2Shell. The name already describes the attack chain: from a cross-site scripting flaw (XSS for short, the injection of foreign JavaScript code into a website) all the way to the "shell" – that is, the execution of the attacker's own program code on the server.

The starting point is the login page wp-login.php – the page administrators use to sign in. It is reachable from the outside without a WordPress account. And that is precisely where the problem lies: an attacker can lure a person via a crafted link on a third-party website into opening that link. Malicious JavaScript is then executed in the so-called origin of the WordPress site – that is, as if the code came directly from the trusted website itself. This is known as a reflected XSS, because the login page "reflects" the manipulated input back to the browser.

If it stops there, the damage is limited. It becomes dangerous when an administrator is logged in at the moment of the click. In that case, the researchers were able to demonstrate an entire chain in the lab: the injected code grabs an application password (a special access token for programming interfaces), uses it to execute privileged WordPress functions, uploads a manipulated plugin archive, and finally brings PHP code to execution on the server – in the context of the web server process. This is the path to a complete server takeover.

Important context: no clickless server takeover

As dramatic as the headlines may sound: this is not a flaw through which a server can be taken over without any action from the victim and without authentication. In its security advisory, the WordPress maker explicitly clarifies that escalation to code execution requires additional conditions:

"Via a specially crafted attacker-hosted third-party page, it is possible to escalate this to an RCE vulnerability under conditions outside the attacker's control. This requires successful social engineering of and explicit interaction by the target victim." – WordPress Security Advisory GHSA-52p2-r8wf-jcrf

The telemetry provider Imperva also emphasises this distinction:

"An important distinction is that CVE-2026-64638 should not be described as an unauthenticated RCE without interaction." – Imperva Threat Research

That does not, however, reduce the urgency: the first step of the chain requires no account, the flaw sits in the core, and the website is reachable over the network. This is why the patch is an urgent matter for every publicly accessible WordPress instance.

The technical background – explained clearly

The root cause is a so-called parser differential: two of WordPress's filter functions judge the same malformed HTML markup differently. Specifically, a username submitted during a failed login first passes through the function wp_strip_all_tags() or PHP's internal strip_tags(), and then through wp_kses_post(). Because both filters categorise certain malformed markup differently, attacker-controlled elements in the login response can take effect as real DOM elements – and the already-loaded WordPress JavaScript brings them to execution within the same origin. In short: a flaw in sanitising input opens the door.

Who is affected?

Every WordPress installation prior to version 7.0.3 is affected, or prior to the respective patched version of the release branch in use. Because this concerns the WordPress core, it makes no difference which plugins or themes are in use.

For a sense of scale: according to W3Techs, WordPress ran on 41.0% of all websites worldwide as of 12 August 2026, and on 59.0% of all websites with a known content management system. This figure describes the reach of the platform – not the number of vulnerable or already compromised installations.

That the flaw is actually being attacked is well documented: the Canadian Centre for Cyber Security published warning AV26-792 on 10 August 2026 and stated, citing open-source reports, that CVE-2026-64638 is being exploited in the wild. Imperva reported on the same day about automated targeting against more than 11,000 distinct websites in 67 countries and hundreds of thousands of requests. Important: these are attack attempts and vendor telemetry – not a verified count of successful takeovers or compromised records.

How to check whether you are affected

1. Inventory all WordPress instances. Capture not only your main site, but also staging systems, microsites, campaign pages and old, forgotten subdomains – including installations run by agencies or hosting providers.
2. Check the core version that is actually running. In the backend you'll find it under Dashboard > Updates. If WP-CLI (WordPress's command-line management) is available, wp core version reports the version. If the backend is locked, the administrator or hosting provider can check the file wp-includes/version.php or the hosting patch log.
3. Compare against the official patch list. Any version that predates the patched version of its branch urgently needs updating. WordPress 4.6 or older receives no fix and must be migrated to a supported version.
4. Verify the update succeeded. Don't blindly rely on automatic updates – check the version level, timestamp and, where applicable, the update log. Create a verified, restorable backup of files and database before every update.
5. Check logs for anomalies. Examine login, web server, WAF and REST logs for unusual POST requests to wp-login.php, suspicious REST calls and plugin upload events. One investigation indicator described by pwn.ai is login POSTs in which the username field contains a URL-encoded less-than sign – this is a lead for analysis, not standalone proof of a compromise.
6. Check administrative and file traces. Look for unknown administrators, unexplained application passwords, new or recently modified plugins, and unusual files under wp-content/plugins/. If you suspect something: secure access, preserve logs and evidence, and bring in qualified incident response support as well as your hosting provider.

What you need to do now

The good news: there is a patch. WordPress released security version 7.0.3 on 6 August 2026, which closes the flaw. In addition, backports are available for all branches under security maintenance at the time, going back to version 4.7 – specifically versions 6.9.6, 6.8.7, 6.7.6, 6.6.6, 6.5.9, 6.4.9, 6.3.9, 6.2.10, 6.1.11, 6.0.13, 5.9.14, 5.8.14, 5.7.16, 5.6.18, 5.5.19, 5.4.20, 5.3.22, 5.2.25, 5.1.23, 5.0.26, 4.9.30, 4.8.29 and 4.7.34. For version 4.6 and older there is no fix.

1. Update the WordPress core immediately – to the patched version of your branch, preferably to the latest supported version. This is the only true remedy against the underlying XSS flaw.
2. Verify the update and secure a backup. After updating, check the running version and ensure a tested recovery path. Keep plugins, themes and the PHP version up to date afterwards as well – but that does not replace the core patch.
3. Disable application passwords, provided they are not needed for any essential integration. This removes an important escalation step from the demonstrated attack chain.
4. Harden file changes. If you roll out plugins and themes via a controlled deployment process, consider DISALLOW_FILE_MODS in wp-config.php, and block direct PHP execution server-side from unnecessary writable directories. Check compatibility and operational workflow beforehand.
5. Limit and secure admin privileges. Restrict administrator rights to necessary people, deploy multi-factor authentication for admin accounts, and instruct administrators not to open unknown links in a browser profile with an active WordPress admin session. This active interaction is exactly what the full RCE path requires.
6. WAF rules only as a supplement. Temporary rules in a web application firewall or reverse proxy can block or log conspicuous, malformed login requests – they must be tested and do not replace the patch.

An important note from the University of Toronto: a strict Content Security Policy (a browser protection rule against foreign code) did not help in testing:

"A nonce-based Content Security Policy with strict-dynamic was tested against the demonstrated path and did not prevent exploitation; CSP is not a compensating control." – University of Toronto Information Security

GDPR: what you must consider legally

An unpatched vulnerability is not yet a reportable data breach. However, if your investigation shows that a successful compromise could have affected personal data, you must review Articles 33 and 34 GDPR.

• Art. 33 GDPR: The competent supervisory authority must be notified without undue delay and, where feasible, within 72 hours of becoming aware – unless the breach is unlikely to result in a risk to the rights and freedoms of natural persons. All data breaches must be documented.
• Art. 34 GDPR: Where there is likely to be a high risk, the affected individuals must in principle also be notified without undue delay.

For the case-by-case decision, document the nature and scope of the data that may have been leaked, whether it was encrypted, what access traces exist, and what measures you took. Involve data protection officers, the competent supervisory authority and, where appropriate, legal counsel early on.

German practice shows that supervisory authorities do penalise inadequate security measures: in 2019 the German Federal Commissioner for Data Protection (BfDI) fined 1&1 Telecom €9.55 million for inadequate authentication measures, and in 2025 fined Vodafone €30 million for security shortcomings in the authentication process. Neither case concerns WordPress, and they do not allow a fine forecast for SMEs – but they do demonstrate the relevance of Art. 32 GDPR (appropriate technical and organisational security). BfDI head Prof. Dr Louisa Specht-Riemenschneider sums it up:

"Without IT investment, security incidents and also sanctions from the data protection supervisory authority loom. So here's my call: invest rather than risk!" – Prof. Dr Louisa Specht-Riemenschneider, BfDI

Conclusion

XSS2Shell (CVE-2026-64638) is a serious flaw in the WordPress core that is already being actively attacked. It is not a clickless, accountless server takeover – full code execution presupposes a logged-in administrator, their active interaction, and further technical prerequisites. That is precisely why you should avoid panic but act without delay.

The priority is clear: update every WordPress presence to a patched version immediately, verify the update status, secure your admin accounts with multi-factor authentication, and disable application passwords you don't need. Check your logs for suspicious login requests and plugin uploads. And document your approach – so that if a data leak does emerge later, you are prepared for the GDPR deadlines. With a market share of over 40 percent, anyone running a WordPress site belongs to the potential target group of the automated attack waves. A prompt update is the best and only true remedy.