---
title: "WordPress Login XSS: What the 7.0.3 Security Release Fixed"
slug: "wordpress-login-xss-cve-2026-64638"
description: "WordPress 7.0.3 fixed a login XSS vulnerability, CVE-2026-64638. Here's the real risk to admins and how to confirm your site is patched."
date: 2026-09-14
author: "WP Vanguard Team"
category: "Research"
tags: ["wordpress-login-xss-vulnerability", "cve-2026-64638", "wordpress-core", "reflected-xss", "wp-login"]
featured_image: "/images/blog/wordpress-login-xss-cve-2026-64638.jpg"
---

WordPress core had a reflected XSS vulnerability on its login screen until August 6, 2026. That's when WordPress 7.0.3 fixed CVE-2026-64638, a bug in how `wp-login.php` handles a failed login attempt. No plugin required. No theme required. Just core, with the fix backported to every branch back to 4.7.

Most of what lands in our research queue is a plugin flaw. A login-screen bug in core is a different kind of exposure: it reaches every site that hasn't taken the update, not only the sites running one plugin.

## What WordPress 7.0.3 Fixed, and When

WordPress 7.0.3 went out on August 6, 2026. The [official release announcement](https://wordpress.org/news/2026/08/wordpress-7-0-3-release/) names CVE-2026-64638 as the headline fix: "a pre-authentication reflected cross-site scripting (XSS) vulnerability on the login screen with potential to lead to PHP code execution," credited to the research team at pwn.ai. The advisory is tracked as CVE-2026-64638 and GHSA-52p2-r8wf-jcrf.

That release note isn't a one-issue patch. WordPress.org confirms 7.0.3 closed 12 vulnerabilities total: the login XSS plus 11 others covering stored XSS, privilege escalation, information disclosure, CSS injection, an email verification bypass, and server-side request forgery. We're not covering the other 11 here; this post owns the login XSS angle specifically.

[NVD's record for CVE-2026-64638](https://nvd.nist.gov/vuln/detail/CVE-2026-64638) confirms the fix applies to every WordPress version, and that WordPress backported it "as a courtesy to users on older branches...to all branches back to 4.7." Our own vulnerability feed lists that backport reaching 4.7.34. If you're running an old maintained branch instead of the current release line, you still got a patch.

Delivery matters here more than usual. WordPress.org's release notes say sites with automatic background updates "will begin updating shortly" on their own. Background updates have covered every WordPress core security release since 3.7, and this one is no exception. If your host or config has that setting on, you likely didn't have to do anything.

## How the WordPress Login XSS Actually Works

The bug lives in the failed-login flow. When someone submits a bad username to `wp-login.php`, WordPress echoes part of that input back into the error message on the same page. The vulnerable value travels through the `log` parameter, the field name WordPress has always used for the username on that form.

[Hadrian's technical analysis](https://hadrian.io/blog/wordpress-xss2shell-unauthenticated-login-screen-xss-to-php-code-execution-cve-2026-64638) traces the root cause to a mismatch between two sanitization steps. PHP's `strip_tags()` has a documented quirk: a `<` immediately followed by whitespace doesn't register as the start of a tag, so it survives untouched. WordPress's `wp_kses_post()` filter runs afterward and does treat that same sequence as valid markup. A crafted username string passes the first check clean and gets interpreted as HTML by the second. The fix, per Hadrian's writeup, adds `esc_html()` at the point in `wp-includes/user.php` where the failed username gets written into the page, so the value is HTML-encoded before either sanitizer sees it.

NVD's own advisory description confirms this needs "successful social engineering of and explicit interaction by the target victim." Nobody gets hit by loading `wp-login.php` directly. The attack requires a crafted third-party page, an email link, or an ad that gets a victim's browser to submit the malicious `log` value to the target site's login form. That's the "reflected" part of reflected XSS: the payload has to bounce off the victim's own request.

This is also why the underlying CWE classification is CWE-79, plain cross-site scripting, not an authentication bypass or a direct code-execution flaw. The XSS runs in the browser, in the context of whoever's login page it hit.

## What an Attacker Can Realistically Do to an Admin

An XSS that fires on an anonymous visitor's browser is a nuisance. An XSS that fires while a WordPress administrator has an active session is a different problem, because JavaScript running on the site's own origin can call the same REST API the admin's browser is already trusted to use.

Hadrian's writeup describes the escalation path pwn.ai demonstrated against that specific scenario: DOM manipulation of the login page's own JavaScript, a Same Origin Method Execution technique to reach the Application Passwords approval flow, creation of a new Application Password under the admin's account, and use of that credential to upload a plugin and get PHP running on the server. That's a real, published proof-of-concept chain, not a marketing flourish.

Treat it as the typical escalation path this class of bug enables, not a guaranteed outcome. NVD's own summary is careful about that distinction: it says the escalation to something like RCE happens "with conditions outside of the attackers control," meaning it depends on an administrator being logged in at the right moment and clicking the right crafted link. Take away the live admin session and the bug is back to being a reflected XSS that steals cookies or redirects visitors, which is still worth fixing but isn't remote code execution.

That precondition is also why severity numbers for this CVE vary so much across databases. NVD's CVSS 4.0 score is 8.9, driven by a "high" impact rating on the assumption the chain completes. [Patchstack rates the same CVE 7.1](https://patchstack.com/database/wordpress/wordpress/wordpress/vulnerability/wordpress-core-7-0-3-reflected-xss-to-rce-vulnerability), closer to a standard reflected XSS. Our own scan database classifies it as medium severity, CVSS 6.1, weighted for the fact that it needs both a crafted link and a specific victim to click it. None of those numbers is wrong; they're scoring different assumptions about what has to go right for an attacker.

One naming note, since it's easy to mix up: some researchers call this bug XSS2Shell. It has nothing to do with WP2Shell (CVE-2026-63030), the separate core RCE chain we covered in a different context. Same "shell" naming pattern, unrelated bugs.

If you've just moved to WordPress 7.0 and haven't run through the broader upgrade checks yet, our [WordPress 7.0 upgrade security checklist](/blog/wordpress-7-0-upgrade-security-checklist) covers PHP version, plugin inventory, and admin hardening steps that apply regardless of this specific CVE. We also covered [the first AI API key exposure bug in WordPress 7.0](/blog/wordpress-7-0-ai-api-key-attack-surface) a few months earlier: different vulnerability class, same lesson about how much attack surface a major core release adds in its first weeks.

## No Confirmed Exploitation Yet, but Don't Treat That as Safe

CISA's own SSVC data for this CVE, included in the NVD record, lists exploitation status as "none" and marks the bug as not automatable. It's not in the CISA Known Exploited Vulnerabilities catalog as of this writing. That's a genuinely different risk profile from a plugin bug under active mass-scanning the same week it's patched.

It's also not a reason to leave a site unpatched. The technical write-ups explaining exactly how the chain works are already public. A CVE with a documented proof-of-concept and no confirmed campaign yet is a CVE sitting in the window before one starts, not a CVE that's been cleared.

## How to Confirm Your Core Version and Auto-Updates Are On

Check your installed version first:

```bash
wp core version
```

Anything below 7.0.3 on the 7.0 branch, or below the matching patched point release on an older branch (6.9.6, 6.8.7, and so on down to 4.7.34), still has this bug.

Then check for a pending update:

```bash
wp core check-update
```

If that comes back clean and you're already on 7.0.3 or later, you're covered for this CVE specifically. Confirm background updates are actually running rather than just enabled, since a misconfigured cron or a disabled `wp-cron.php` can leave a site silently behind:

```bash
wp cron event list | grep wp_version_check
```

If that event isn't scheduled, your site isn't checking for new versions on its own, and you're relying on someone remembering to run `wp core update` by hand.

For a broader pass across your version, plugins, and exposed configuration, [WP Vanguard's free surface scan](/#scanner) checks what's actually running against our vulnerability database in under a minute.

## References

- [WordPress 7.0.3 Release (wordpress.org/news)](https://wordpress.org/news/2026/08/wordpress-7-0-3-release/)
- [NVD: CVE-2026-64638 Detail](https://nvd.nist.gov/vuln/detail/CVE-2026-64638)
- [Patchstack: WordPress Core 7.0.3 Reflected XSS to RCE Vulnerability](https://patchstack.com/database/wordpress/wordpress/wordpress/vulnerability/wordpress-core-7-0-3-reflected-xss-to-rce-vulnerability)
- [Hadrian: WordPress XSS2Shell Technical Analysis (CVE-2026-64638)](https://hadrian.io/blog/wordpress-xss2shell-unauthenticated-login-screen-xss-to-php-code-execution-cve-2026-64638)