WordPress 7.0.3: login-screen XSS chains to PHP execution

The most-visited unauthenticated page on your WordPress site is the login screen, and until August 6 it would reflect attacker-controlled HTML back at whoever loaded it. CVE-2026-64638 is a pre-auth cross-site scripting flaw in wp-login.php that chains all the way to PHP code execution on the server. It carries a CVSS of 8.9, it is the highest-severity item in WordPress 7.0.3, and it affects every install from 6.4 through 7.0.2.

What actually happened

The researcher writeup from pwn.ai lays out the chain, and it's a good lesson in how small parsing inconsistencies compound.

An unauthenticated POST to /wp-login.php puts encoded HTML brackets in the log parameter. WordPress runs the username through sanitize_user() and wp_strip_all_tags(), but tag-like strings containing whitespace survive that pass — and get treated as valid HTML later. That gives an attacker a DOM element on the login page.

From there it uses user-profile.js, which WordPress enqueues on the login screen by default for password resets. Missing inputs resolve to undefined, an equality check passes that shouldn't, and the injected element clobbers the ajaxurl variable. That steers WordPress's own JavaScript at an attacker-chosen same-origin request. The finish is a Same Origin Method Execution technique that harvests an Application Password, then uses that credential over the REST API to upload a plugin ZIP containing PHP.

Two things to be precise about. The XSS alone needs no authentication and no interaction beyond a failed login. The full chain to code execution requires a logged-in single-site administrator to load the crafted URL, plus some specific deployment conditions. And as of now there are no reports of exploitation in the wild.

The other detail worth your attention: pwn.ai reproduced this with an autonomous multi-agent system, building on Paulos Yibelo's 2022 SOME research. AI agents are now finding real chained bugs in the most-deployed CMS on the internet.

Why this matters for your business

WordPress 7.0.3 fixed 12 vulnerabilities — XSS at several privilege levels, multisite privilege escalation, information disclosure, SSRF. Auto-updates roll it out, and backports go through the 4.7 branch. That is not the same as your site being patched.

We say this every time because every time we audit a small-business site, at least one of these is true: auto-updates are off because a plugin broke once in 2023, the site runs a managed host that batches updates on its own schedule, or nobody has logged into /wp-admin since the redesign. Go confirm the version string yourself. It takes thirty seconds.

Then fix the thing behind the thing: this chain ends at plugin upload because an administrator account had that power in a browser session. Cut the admin count to the people who need it, put DISALLOW_FILE_EDIT in wp-config.php, and audit your Application Passwords — most sites have stale ones from an integration nobody uses anymore.

Sources: WordPress 7.0.3 release note, pwn.ai / Hadrian technical writeup, The Hacker News.