- WordPress 7.0.3 is a security release patching 12 vulnerabilities affecting versions 4.7 through 7.0.2.
- The most severe bug is a pre-authentication reflected cross-site scripting (XSS) flaw on the login page (CVE-2026-64638) that requires no user account to trigger.
- Four separate stored XSS vulnerabilities were patched that affect Contributor-level accounts in settings, blocks, and Quick Edit.
- Additional fixes include a multisite privilege escalation, information disclosures in password-protected posts, a CSS injection bug, an email bypass, and a server-side request forgery (SSRF) fix.
A site running an unpatched version of WordPress right now is sitting on a published list of exactly how to break into it. That’s the uncomfortable reality every time WordPress ships a security release: the official 7.0.3 release notes spell out, issue by issue, what’s wrong and who found it, which means anyone running an automated scanner now has the same information your hosting provider does.
7.0.3 is a security release, not a feature update, and it patches 12 distinct issues across WordPress core. Every version from 4.7 through 7.0.2 is affected, which in practice means almost every WordPress site still running default settings. Here’s what’s actually in it, which parts matter most for a small business site, and how to update without turning a five-minute patch into an afternoon of troubleshooting.
CVE-2026-64638 Login Page XSS Mechanics
CVE-2026-64638 is a reflected cross-site scripting flaw on the login screen that doesn’t require any authentication to trigger, and that WordPress’s own advisory notes carries the potential to escalate into PHP code execution. A pre-auth vulnerability means an attacker doesn’t need a username, a password, or an account on your site at all. They just need a visitor to click a crafted link that points at your own login page.
Reflected XSS means the malicious code travels inside the URL itself rather than being stored anywhere on your server, so it only fires when someone actually clicks the booby-trapped link; it’s not something a vulnerability scanner will find sitting dormant on your site. That’s exactly why it tends to show up in phishing emails and fake “your account needs verification” messages that link back to a real domain’s real login page, since the link looks legitimate right up until the script runs in the visitor’s browser.
Contributor-Level Stored XSS Vulnerabilities
WordPress patched four distinct stored XSS vulnerabilities that all share a common thread: they’re exploitable by an account with Contributor-level access, one of WordPress’s lowest permission tiers. One lives in the emoji settings element, one in the Post Content block, one in the Post Date block, and one in Quick Edit specifically on sites with a large number of registered users.
This matters more than the low-privilege label suggests. Any site that accepts guest post submissions, runs a multi-author blog, or lets freelance writers log in to draft their own posts is handing out Contributor access as a matter of course, and a stored XSS bug means that script sits embedded in the page and fires on every visitor who loads it, not just the one person who clicked a link. If your site has ever given a guest writer, intern, or outside contractor their own login, this vulnerability applies directly to your WordPress installation.
Multisite Privilege Escalation and Information Disclosure Flaws
WordPress multisite networks with open user registration enabled face a closed privilege escalation path in version 7.0.3 that could have let a regular registered user gain elevated permissions they were never granted. The rest of the release covers a cluster of smaller information-disclosure issues: a bug in the Latest Comments block that could expose comments on password-protected posts to visitors who never entered the password, a way to enumerate post slugs that weren’t meant to be guessable, and a flaw letting comment feed notes leak information they shouldn’t.
None of those three are as severe as the login XSS, but they’re the kind of thing that matters for a site using password-protected posts for client previews, early-access content, or internal documentation, since the whole point of that password layer is defeated if the content leaks through a sidebar widget instead.
CSS Injection, Email Bypass, and SSRF Fixes
The remaining fixes include a CSS injection bug that bypassed WordPress’s “safe CSS” filter for Author-level accounts, a flaw in the email confirmation flow that could be bypassed under certain conditions, and a server-side request forgery (SSRF) issue in how WordPress validates URLs. SSRF bugs are worth taking seriously even when they sound abstract: they can let an attacker trick your server into making requests to internal addresses or services it shouldn’t be able to reach, which is a different kind of problem than a script running in someone’s browser. It’s the server itself being tricked, not the visitor.
Taken together, this is a release where no single fix is catastrophic on its own, but the combination (unauthenticated XSS on the most exposed page on your site, several ways for a low-privilege account to do more than it should, and a server-side trust issue) adds up to a release you don’t want to sit on for weeks.
Administrator Guide for Safe WordPress Updates
The update itself is simple: WordPress will usually prompt you in the Dashboard, or you can trigger it manually under Updates. The operational steps to slow down for involve everything around the update, rather than the update execution itself.
Take a real backup first, not just a database export. A full-site backup that includes your files, uploads, and active theme matters here specifically because several of these fixes touch blocks and content rendering (Post Content block, Post Date block, Quick Edit), and a plugin or custom block that was quietly relying on old, buggy behavior can occasionally break in small, easy-to-miss ways after a core patch. If you are evaluating infrastructure changes or looking for WordPress-specific hosting tools that support a staging environment, running the update there first and clicking through your site’s key pages before touching the live version costs a few extra minutes and catches most of those surprises before a visitor does.
After updating, go back through your user list if your site has Contributor or Author accounts you haven’t reviewed in a while. An old guest-writer account that still has active access is exactly the kind of thing these fixes are designed to make less dangerous, but it’s worth confirming nobody still has access who shouldn’t.
Immediate Patching Against Automated Vulnerability Scanners
The timing dynamic with any public security release is the same every time: the moment the fix ships, the vulnerability details become public knowledge, and that’s also the moment automated scanners start probing the internet for sites that haven’t patched yet. There’s no quiet window where you’re safe because nobody knows yet. Everybody who wants to know, already does, the second the release notes go live.
For a small business site, the realistic risk isn’t a targeted attacker who specifically wants your business. It’s a bot that doesn’t care whose site it is, scanning thousands of domains a day for exactly this fingerprint, and WordPress still runs a large enough share of the web that a single unpatched version number is worth writing a scanner for. Treating a security release like a routine update you’ll get to this week is how sites that have never been a specific target still end up compromised anyway, simply because they were the easiest unlocked door on the street.
If you manage multiple WordPress sites across different hosting accounts, this release is also a good prompt to check whether auto-updates for minor/security releases are actually turned on everywhere, not just on the site you think about most. The sites people forget about are usually the ones still running 7.0.1 six months from now.