On August 5, WordPress 7.1 Release Candidate 1 hit the download page with 145 updates across Core and the Editor. The next day, August 6, the security team pushed WordPress 7.0.3 — a mandatory security release with 12 vulnerability fixes, backported all the way to version 4.7. If you run WordPress anywhere, the second one matters more than the first right now.

The login screen XSS is the scary one

The headline fix in 7.0.3 is a pre-authenticated reflected cross-site scripting vulnerability on the login screen. "Pre-authenticated" means nobody needs to be logged in to exploit it. "Reflected XSS" means an attacker crafts a URL that, when visited, executes arbitrary JavaScript in the visitor's browser. And the reporting team at pwn.ai noted it has "potential to lead to PHP code execution," which turns a browser-side vulnerability into a server-side problem.

Let that sink in for a second. A crafted link to your WordPress login page could, under the right circumstances, give an attacker the ability to run code on your server. No credentials needed. No plugin involved. This is a core WordPress vulnerability.

The fix is in 7.0.3. If your site supports automatic background updates, it should already be patched. If you manage updates manually, stop reading and go update now. Seriously.

The other eleven fixes

The login screen XSS gets the attention, but the remaining eleven patches address real problems across different user roles and contexts:

Stored XSS in post content. Contributors and above could inject malicious scripts through the Post Content block, the Post Date block, and via emoji settings in posts. These are not theoretical — if you allow guest authors or have contributor-level users, those accounts were attack vectors.

Multisite privilege escalation. On multisite networks with user registration enabled, a registered user could create a new site they shouldn't have access to. If you run a multisite installation with open registration, this one is critical.

Information disclosure. The Latest Comments block was leaking comments from password-protected posts. Post slugs were enumerable. Comment feed notes were being disclosed. None of these are individually catastrophic, but together they represent a meaningful surface area for reconnaissance.

CSS injection and email bypass. Authors could inject CSS by bypassing the safe attribute filter (reported by Anthropic's security team, interestingly). Separately, the email address confirmation flow could be bypassed entirely.

SSRF in URL validation. A server-side request forgery issue allowed requests to link-local ranges during URL validation. This matters if your WordPress installation sits behind a firewall and trusts its local network — an attacker could use your server to probe internal services.

Every one of these fixes is being backported to branches going back to WordPress 4.7. If you are running anything from 4.7 to 7.0.2, you need this update.

WordPress 7.1 RC1 is the appetizer

While the security team was closing vulnerabilities, the development team shipped 7.1 RC1. It contains 145 changes since Beta 4 — 57 in the block editor, 88 in Core. The final release is scheduled for August 19, 2026.

RC1 introduces the Icons API, which lets themes and plugins register and render SVG icons through a standardized interface instead of inlining raw SVG markup. There are also refinements to the block editor's performance, new hooks for developers, and the usual pile of bug fixes.

The field guide is live on the Make WordPress Core blog if you want the technical breakdown. For most site owners, 7.1 is worth watching but not worth installing on production yet. It is a release candidate, which means it is close to final but not guaranteed stable. Test it on a staging site if you have one. Otherwise, wait for August 19.

What to do right now

Update to 7.0.3. That is the only action item. Go to your dashboard, click Updates, click Update Now. If you manage multiple sites, check that background updates have already run. If you use a hosting provider with managed WordPress, confirm they have applied the patch.

After that, check your multisite configuration if you run one. The privilege escalation fix only applies if you have user registration enabled, but if you do, verify that unauthorized site creation is no longer possible.

Everything else — testing 7.1 RC1, reading the field guide, planning for the August 19 release — can wait until your sites are patched. The login screen XSS is not a "schedule it for next sprint" kind of problem. It is a "fix it before lunch" kind of problem.

Twelve security fixes, one pre-auth RCE-adjacent XSS, and a release candidate all in forty-eight hours. WordPress development is not slowing down. Neither should your update schedule.