WordPress 7.0.3 Core security release: what site owners need to do

WordPress 7.0.3 patches 12 security issues, including a pre-authentication vulnerability on the login screen. Here's what changed, which sites are affected, and what to check after updating.

What WordPress 7.0.3 fixes

WordPress 7.0.3 was released on August 6, 2026 as a security release. It addresses 12 Core vulnerabilities covering cross-site scripting, information disclosure, privilege escalation, server-side request forgery, CSS injection, and account-related issues. They do not all carry the same practical risk, so the most useful way to read the release is by exposure and site configuration.

Pre-authentication XSS on the WordPress login screen

The most notable issue is a reflected cross-site scripting vulnerability on the login screen that does not require authentication, with the potential to lead to PHP code execution. Because the affected surface is publicly reachable on a normal WordPress installation, an attacker does not first need an Administrator, Author, or Contributor account to reach it.

For site owners, that is enough reason not to delay this update unnecessarily.

Server-side request forgery in URL validation

The release also fixes a server-side request forgery issue in WordPress URL validation that could allow requests to link-local network ranges. SSRF vulnerabilities matter because they can potentially allow an application to make requests to internal or otherwise restricted network resources. The actual impact depends on the hosting environment and how the affected functionality is reached.

Multisite privilege escalation

WordPress 7.0.3 fixes a privilege-escalation issue affecting Multisite networks with user registration enabled. Under the affected conditions, a user could create a new site on the network. This is primarily relevant to administrators running public or semi-public Multisite installations rather than ordinary single-site WordPress websites.

Stored XSS affecting contributors and authors

Several other fixes address stored cross-site scripting or CSS injection involving:

• the Post Date block
• the Post Content block
• the emoji settings element
• Quick Edit on sites with a large number of users
• unsafe CSS attributes available to Author-level users

Several of these require at least Contributor-level or Author-level access, which reduces exposure on a simple site with only one trusted administrator but matters more on editorial, membership, community, and multi-author installations.

Information disclosure and account-related issues

The release also addresses:

• comments from password-protected posts being exposed through the Latest Comments block
• notes being exposed in comment feeds
• post slug enumeration
• a bypass in the email-address confirmation flow

These are narrower issues, but collectively they explain why WordPress classified 7.0.3 as a security release rather than a routine maintenance update.

Which WordPress versions are affected?

WordPress 7.0.3 is the current release, but the vulnerabilities are not limited to WordPress 7.0. Security fixes were also released for older affected branches, including WordPress 6.9.6 and 6.8.7, with patched releases continuing back through WordPress 4.7.

WordPress states that version 4.6 and earlier no longer receive security updates. It also reminds users that only the latest WordPress version is actively supported.

So being on an older branch does not necessarily mean you must jump directly to 7.0.3 today. You should at minimum install the corresponding security release for your current branch. If the site is several major versions behind, though, a backported patch should not be treated as a long-term maintenance strategy.

How to update safely

1. Take a fresh backup. Back up both files and database before changing Core, particularly on WooCommerce, membership, or heavily customized sites.
2. Apply the appropriate security release. Update through Dashboard → Updates, WP-CLI, or your normal deployment workflow.
3. Test the frontend. Confirm the homepage and several important public pages load correctly.
4. Test WordPress access. Verify the login screen and wp-admin both work normally.
5. Test business-critical functionality. Check WooCommerce checkout, payments, forms, scheduled actions, REST integrations, and custom code where relevant.
6. Review logs. Look for new PHP or server errors after the update.
7. Clear caches if needed. Purge application, CDN, server, and object caches when stale behavior persists.

For business-critical sites, testing first on staging is normally good practice. With a security release, testing should not become an excuse to leave production unpatched for an extended period.

Check whether automatic updates actually applied

Minor WordPress releases are often installed automatically, but do not assume that happened. Automatic Core updates may have been disabled intentionally, disabled by hosting configuration, or changed after an earlier compatibility problem.

Check the installed WordPress version directly. If the site is still running 7.0.2 or an unpatched older branch, update it rather than relying on the assumption that WordPress handled it automatically.

What if the update fails?

A security update can expose unrelated compatibility problems that were already present in the site. Common symptoms include:

• WordPress stuck in maintenance mode
• a white screen or critical error
• wp-admin becoming inaccessible
• plugins failing because of outdated code
• PHP errors caused by an old theme or plugin

These problems do not necessarily mean the security release itself is faulty. If the site becomes unavailable during the update, WordPress emergency support covers failed updates, critical errors, broken admin access, and other production failures.

Avoid restoring a very old backup immediately unless you understand what you are restoring. A rollback can also restore the vulnerable WordPress version you were trying to replace.

Should you check the site for compromise after updating?

Updating removes the known vulnerable code. It does not remove malware that may already be present. That distinction matters on a site that has been running an outdated release for a long time, already showed suspicious redirects or spam pages, contains unknown administrator accounts, has unexplained modified PHP files, or was previously flagged by a host or security scanner.

In that situation, the update is still necessary, but it should not be treated as proof that the site is clean. Our guide on how to tell if a WordPress site has been hacked covers the first checks to make. If there are actual indicators of compromise, WordPress malware removal should include both cleanup and investigation of the original access path.

WordPress 7.0.2 vs 7.0.3

WordPress 7.0.2 was also a Core security release, but 7.0.3 addresses a separate group of disclosed vulnerabilities. Updating for the 7.0.2 security fixes does not protect a site from the issues corrected in 7.0.3.

You can also read our earlier breakdown of the WordPress 7.0.2 Core security fix.

FAQ

Keep the patch separate from the investigation

For a normal site, the immediate task is straightforward: install the appropriate security release and verify that the website still works. For a site already showing suspicious behavior, there are two separate jobs: patch the vulnerable WordPress version, then determine whether the site was compromised before the patch was installed.

Updating solves the first problem. It does not answer the second.