CVE-2026-64638: XSS2Shell WordPress Login Flaw

Imagine you're logged into your bank account in a browser tab you never closed. If you click a booby-trapped link received by email while that tab stays open, the link can trigger an action on your account using your already-active session, without ever asking for your password again. That's exactly how CVE-2026-64638 works: the flaw only causes damage if an administrator, already logged into their site, clicks a booby-trapped link while that session stays open. This pre-authenticated code injection was found on the WordPress login page (/wp-login.php), and patched on August 6 in versions 7.0.3, 6.9.6 and 6.8.7 depending on the branch, with a CVSS of 8.9.

That score looks high, but it says little about the actual likelihood of exploitation. For nearly all of our clients, only a targeted phishing attempt against an Administrator account that is already logged in can trigger it, which rules out any mass exploitation and explains why no confirmed compromise has been reported to date.

Check Your Versions Now

Start by checking the installed version on every WordPress instance in your fleet, without relying on a sample, since an instance is only truly up to date from 7.0.3, 6.9.6 or 6.8.7 depending on the branch. Automatic minor updates have likely already covered part of the fleet, but they rarely cover all of it, which is why checking each instance individually beats assuming it's protected.

XSS2Shell is a reflected cross-site scripting flaw on the WordPress login page, and it affects every version since 4.7.

Here's what matters most: this flaw never exploits itself alone. It requires three conditions to be met at the same time.

Condition 1: The Login Page Must Be Reachable From the Internet

As long as /wp-login.php isn't publicly exposed, there simply is no attack vector, regardless of the installed version.

Condition 2: An Administrator Must Open a Crafted Page While Already Logged In

Because the parameter in question passes through POST, a simple link isn't enough: the attacker has to design a page that triggers the forged request at the exact moment the admin session is still active.

Condition 3: The Targeted Account Must Be an Administrator

A lower role is still exploitable: an attacker can compromise that account too. But the impact is significantly smaller, since it doesn't allow full site takeover, unlike an Administrator account.

Once these three conditions are laid out, it becomes clear this is primarily targeted phishing rather than automated mass exploitation, especially since no in-the-wild exploitation has been reported to date. That's the point to make when a client gets worried after seeing the CVSS score.

Security researchers have also published a technical chain that turns this reflected XSS, under certain conditions, into full server-side PHP code execution. It all starts with a malformed username, reflected in the login page's error message, which allows injecting DOM elements through a DOM clobbering technique that hijacks the user-profile.js script. From there, the attacker calls the REST API through a JSONP callback to steal an Application Password belonging to the logged-in administrator, before dropping a malicious plugin and executing code on the server.

It's a bit like a visitor slipping a fake badge past the front desk to borrow one left on an employee's desk, then using it to walk straight into the server room.

Remember the first condition: the login page has to be exposed on the internet for the flaw to be reachable. That's precisely what our test confirms, without being able to guarantee that an administrator will fall for the phishing attempt, or remotely verify a given account's exact role: those two other conditions stay contextual, specific to each organization.

At Patrowl, we never settle for the version number alone to judge a flaw, so we send a test request with a harmless payload, a simple marker with no executable code, and we look at what the server's response does with it. If the marker comes back interpreted as HTML, the flaw is confirmed and the site is genuinely reachable; if it comes back escaped, the site is protected.

It's a bit like slipping a note under a door to see if it comes out intact or crumpled on the other side: nothing is forced, we simply observe what the site does with what we send it. That's precisely what lets us tell a client the flaw is genuinely exploitable on their site, not just that they're running a vulnerable version. We apply this same check across EASM assets and the Pentest scope.

Every WordPress asset in your fleet gets one of two statuses in your Patrowl dashboard, and it's worth understanding what sets them apart.

An asset moves to Qualified vulnerability once three things line up: the version is vulnerable, the login page is exposed, and our test confirms the injection actually works. At that point, exploitability stops being a hypothesis, it's verified, and the asset should be patched first.

An asset stays in Warning when the version is vulnerable but exploitation can't be demonstrated in the field, often because Cloudflare or Wordfence neutralize this attack by default. The update is still necessary either way, since the flaw remains, but the urgency is lower since a perimeter protection blocks its immediate access.

When in doubt about a given asset, always trust the Qualified vulnerability menu to establish the list of genuinely affected assets.

Start by updating to 7.0.3, 6.9.6 or 6.8.7 depending on your branch, checking each instance individually rather than trusting a blanket update. Then train your administrators on phishing, since it's the only genuinely exploitable entry point: remind them never to click a link to the admin interface received by email or messaging, to type the URL directly instead, and to close unused sessions. If it's feasible on your end, also restrict access to /wp-login.php to trusted networks, and consider disabling any Application Passwords that aren't in use.

The full vulnerability sheet remains available for clients who want to dig into the technical detail.

A version number alone is never enough to assess a risk with precision, which is why Patrowl combines EASM and continuous Pentest to confirm, asset by asset, what is genuinely exploitable on your side. If you want to check for yourself right now, the CVE-2026-64638 sheet on Patrowl Intel lets you do exactly that.