The WordPress login screen let anyone inject code

WordPress released version 7.0.3 on 6 August, fixing a vulnerability on the login screen. The flaw carries the number CVE-2026-64638, and lets an attacker run their own code in the browser of anyone who opens a specially crafted link. NVD has set the severity at 8.9 out of 10 under CVSS 4.0. According to NVD the flaw affects all versions of WordPress, and the fix has been shipped to every branch still receiving security updates, back to 4.7. None of the sources report exploitation in attacks.

What happens technically

The vulnerability sits in the username field on wp-login.php, in the parameter named log. The finders at pwn.ai describe how the content passes two filters that disagree about what an HTML tag is. The first filter, wp_strip_all_tags, builds on the PHP function strip_tags, which only treats an angle bracket as the start of a tag when the next character is a letter. If the attacker puts a space between the bracket and the tag name, the string survives as plain text. The second filter, wp_kses_post, reads more generously, and accepts the same string as a valid and permitted tag. The result is that the attacker places their own HTML elements on a page shown before anyone has signed in.

The elements alone are not the goal. pwn.ai shows how they are used to steer WordPress's own user profile script, so that the site's own JavaScript sends a request to an endpoint the attacker chooses. From there the finders describe a five-step chain, where a click inside a signed-in administrator's session approves an application password, the password is used against the REST interface, and a plugin archive containing PHP code is uploaded. NVD stresses that escalation to code execution requires the victim to be socially engineered into acting, and that conditions outside the attacker's control must line up. The vulnerability on the login screen itself, by contrast, requires no sign-in at all.

What this means for you if you run a WordPress site

Berigo's assessment is that the important part here is not the XSS flaw itself, but how short the route is from there to control of your site. The chain pwn.ai describes ends with PHP code running on the server. A server running the attacker's code also reaches the database behind the site. If you set the site up once and have left it alone since, yours is exactly the kind that gets left behind on old code.

The preconditions soften your risk, but they do not remove it. Escalation requires, according to NVD, that an administrator is lured into acting. If you are that administrator yourself, this is the kind of precondition that tends to be met on a busy day. The security release on 6 August fixed twelve weaknesses in total. The update is worth taking regardless of how likely this particular chain looks to you.

Berigo recommends

• Update to WordPress 7.0.3, or to the fixed release in the branch your site runs on.
• Check that automatic background updates are actually enabled, and that they have run.
• Review the application passwords that exist on the site, and remove the ones nobody recognises.
• Limit who may upload plugins, and close off uploads in production where that is workable.
• Put the site on the list of things someone is named as responsible for updating.