WordPress released version 7.0.3 on August 6, 2026, a security-only update addressing 12 vulnerabilities across core code and simultaneously backporting fixes to every supported branch from 4.7 forward, according to Wordify's technical breakdown. The release includes one CVE-rated issue and 11 additional vulnerabilities, most requiring existing user accounts before exploitation becomes possible.
TL;DR: WordPress 7.0.3 patches 12 security vulnerabilities on August 6, 2026, with backported fixes shipping simultaneously to all supported branches from 4.7 through 7.0.
The update marks the third security release in WordPress 7.0's lifecycle and the first to carry a formal CVE designation for a login-screen cross-site scripting flaw rated 8.9 on the CVSS scale. John Blackbourn led the release effort, coordinating 31 file changes totaling 261 code insertions and 86 deletions across core, according to the commit record.
CVE-2026-64638 Targets Login Screen Through Social Engineering
CVE-2026-64638, the sole vulnerability carrying a Common Vulnerabilities and Exposures identifier in the August 6 batch, enables pre-authentication reflected cross-site scripting on the WordPress login screen with a CVSS score of 8.9. The flaw affects every WordPress version from 4.7.0 through 7.0.2, spanning eight years of releases.
Exploitation requires an administrator to follow a crafted link from an attacker-controlled external site. WordPress documentation notes the vulnerability carries potential for escalation to PHP code execution through the plugin and theme editor, though the CVSS vector classification specifies active user interaction as a prerequisite. The fix implements output escaping via esc_html(), esc_url(), and esc_attr() functions in wp-includes/user.php and wp-login.php, addressing long-standing gaps in sanitization routines.
Eleven Additional Vulnerabilities Require Account Access or Target Specific Configurations
The remaining 11 vulnerabilities patched in WordPress 7.0.3 split between authentication-dependent issues and configuration-specific flaws, according to the release notes. Five vulnerabilities require a Contributor-level account or higher before exploitation becomes possible, including four stored cross-site scripting issues in the emoji settings element, Post Content block, Post Date block, and Quick Edit interface on installations managing large user counts.
A CSS injection vulnerability affecting Author-level accounts and above bypasses the safe CSS attribute filter by failing open when internal processing limits are reached. Three information disclosure vulnerabilities expose comment data on password-protected posts through the Latest Comments block, leak editorial notes through comment feeds, and permit post slug enumeration.
Server-side request forgery protection now blocks link-local IP ranges including 169.254.0.0/16, covering cloud metadata endpoints, CGNAT addresses, multicast ranges, TEST-NET allocations, and reserved blocks. A privilege escalation flaw on multisite networks with user registration enabled permits unauthorized site creation, affecting only multi-site configurations rather than single-site installations. The final patch closes an email address confirmation bypass.
Backport Strategy Delivers Branch-Specific Coverage Without Major Version Upgrades
WordPress shipped simultaneous security updates to 23 active branches on August 6, eliminating the need for major version migrations to receive patches. Sites running WordPress 7.0 received all 12 vulnerability fixes in version 7.0.3, while installations on versions 6.9 through 6.2 received 11 patches, and branches 6.1 through 4.7 received between seven and eight fixes depending on feature availability in each release line.
The variation in patch counts reflects feature-specific vulnerabilities rather than incomplete coverage. The four vulnerabilities absent from pre-6.9 releases—editorial notes handling, Post Content block tag processing, script module functionality, and emoji rendering—depend on code introduced in WordPress 6.9 and 7.0. Agencies managing white-label WordPress development projects across multiple client versions can apply in-branch updates without triggering compatibility testing cycles required for major version upgrades.
WordPress documentation emphasizes that only the most recent major version receives active feature support, with backported security patches representing a courtesy extension rather than long-term support commitment. Installations running WordPress 4.6 and earlier no longer receive security updates through any channel.
Immediate Action Items for Agency Operations Teams
Agencies managing client site portfolios face three priority tasks following the August 6 security release. First, verify current WordPress versions across all client installations, including staging and development environments. The version identifier appears at Dashboard → Updates in WordPress admin, with publicly accessible staging servers carrying identical exposure profiles to production sites despite receiving less operational attention.
Second, deploy the appropriate security update for each installation's current branch. Sites configured for automatic background updates typically complete minor security releases within hours of publication, though manual verification remains necessary for installations with automatic updates disabled or blocked by hosting configurations. Similar WordPress security vulnerabilities affecting core versions have demonstrated the narrow window between public disclosure and active exploitation attempts.
Third, audit user account permissions and registration settings. Five of the 12 patched vulnerabilities require Contributor or Author account access before exploitation becomes possible, elevating user account management from administrative housekeeping to security-critical infrastructure. Multisite network administrators should prioritize the privilege escalation patch on networks permitting open user registration.
What This Means for Agency Owners
The August 6 security release demonstrates WordPress's commitment to backward-compatible security maintenance, but agencies relying on older major versions face mounting risk as the platform expands its feature surface. The four vulnerabilities exclusive to WordPress 6.9 and 7.0 illustrate how new block editor capabilities introduce new attack vectors, a pattern likely to accelerate as WordPress deepens its investment in full-site editing and block-based architecture.
Agencies should treat the backport coverage table as a planning document rather than a permanent support guarantee. The 23-branch simultaneous release represents significant engineering effort, and WordPress's explicit statement that backports constitute "a courtesy, not a support commitment" signals potential future contraction of the security update window. Capacity planning models should account for major version upgrade cycles as a recurring operational requirement rather than an optional optimization.
The credential-dependent nature of eight vulnerabilities in this release reinforces the defensive value of least-privilege access controls. Agencies managing large client portfolios can reduce exposure surface by implementing role-based access reviews, time-limited elevated permissions for freelance contributors, and regular audits of dormant user accounts—operational practices that mitigate entire vulnerability classes regardless of patch status.