WordPress 7.0 released yesterday — May 20, 2026. It was supposed to ship on April 9. The six-week delay came from a critical architectural flaw in the real-time collaboration system that forced the core team to rebuild a database table from scratch. That same feature was then quietly removed from the release entirely on May 8 by Matt Mullenweg. So, the version that actually shipped is smaller than the one that was advertised — but the security picture is clearer and more important than most coverage has acknowledged.

This post covers every security-relevant change in WordPress 7.0, the chaotic three-release patch cycle that preceded it, and what the PHP 7.4 minimum requirement actually means for sites that haven’t upgraded their server environment.

The Pre-Launch Security Storm: What Happened in March

Before 7.0 even reached release candidates, the WordPress Security Team shipped three separate releases in under 24 hours — an event that exposed both legitimate vulnerabilities and real process failures.

WordPress 6.9.2: Ten Vulnerabilities Patched, Sites Broken

On March 10, 2026, WordPress 6.9.2 dropped as a security-only release. It patched ten distinct vulnerabilities, all requiring authentication to exploit. The most serious were a blind SSRF (server-side request forgery), a stored XSS via the data-wp-bind directive, a stored XSS in nav menus, and an authorization bypass on the Notes feature.

Also patched: a PclZip path traversal, an XXE vulnerability in the getID3 library, a PoP-chain weakness in the HTML API and Block Registry, a regex DoS in numeric character references, an XSS allowing override of client-side admin templates, and an AJAX query-attachments authorization bypass.

CVSS severity ratings ranged from 4.3 to 6.5 — medium severity, requiring attacker permissions from subscriber level up to administrator. These aren’t emergency-patch-at-2am vulnerabilities, but they are real and they needed fixing.

Within hours of 6.9.2 going out, site owners started reporting blank screens. Themes using a legacy library triggered a template loading bug introduced by the update. WordPress pulled the release from the download page.

WordPress 6.9.3: The Hotfix That Wasn’t Enough

By 22:40 UTC the same day, 6.9.3 was released with the theme compatibility fix included. Sites came back online. Problem solved — except it wasn’t.

On March 11, WordPress 6.9.4 shipped after the security team discovered that three of the original patches were incomplete. If you updated to 6.9.2 and then stopped at 6.9.3, you were running a site with an incomplete patch set.

WordPress 6.9.4: The Only Version That Actually Finished the Job

On March 11, 2026, WordPress 6.9.4 was released to the public. This is a security release that includes additional fixes that were not fully applied to the earlier 6.9.2 security release and 6.9.3 bug fix release.

The three vulnerabilities that needed completing:

CVE-2026-3907 — PclZip Path Traversal A path traversal vulnerability in PclZip allows attackers to write files outside the intended directory during archive extraction. In practice, a malicious ZIP file upload could place executable code in locations that WordPress never intended to be writable. Sites using import plugins, theme uploaders, or any feature handling ZIP files face the highest exposure from this flaw. Reported independently by Francesco Carlucci and kaminuma.

CVE-2026-3906 — Notes Authorization Bypass This vulnerability allows a lower-privileged user to access or modify Notes functionality reserved for higher roles. Authorization bypass flaws require no advanced technical skills to exploit. An authenticated attacker with a basic account could potentially perform actions well beyond their assigned permissions. Reported by kaminuma.

CVE-2026-3908 — XXE in getID3 XML External Entity (XXE) injection in the getID3 library affects how WordPress processes media file metadata. The getID3 library extracts information from audio and video files. In a successful attack, this could expose server-side files or internal network resources. The WordPress security team worked with the maintainer of the external getID3 library, James Heinrich, to coordinate a fix to getID3. A new version of getID3 is now available.

If you’re still running 6.9.2 or 6.9.3, update immediately. Neither version has all ten patches fully applied.

What WordPress 7.0 Actually Changed for Security

1. PHP 7.2 and 7.3 Support Is Gone

This is the most consequential security change in 7.0, and it’s been underreported.

WordPress 7.0 officially sets the minimum supported version to PHP 7.4. The update also removes support for PHP 7.2 and PHP 7.3.

That’s not a formality. PHP 7.2 reached end-of-life in November 2019. PHP 7.3 reached end-of-life in December 2021. Both have been receiving zero security updates for years. Sites still running either version have been accumulating unpatched PHP-level vulnerabilities since those dates — vulnerabilities that exist independently of anything WordPress core patches.

Sites still running on PHP 7.2 or 7.3 will be unable to update to the 7.0 branch. They also lose access to all future WordPress security releases. This is a hard stop.

For better performance and compatibility, the WordPress core team strongly recommends using PHP 8.3 or higher for modern 2026 workflows.

How to check your version: Go to Tools → Site Health in your WordPress dashboard. The Info tab, under Server, shows your exact PHP version. No plugin needed.

Sites on PHP 7.4 will technically function but won’t access new features, security improvements, or modern WordPress APIs. PHP 7.4 itself hit end-of-life in November 2022. Running it in 2026 means running a language version with known, unpatched CVEs at the PHP level — separate from anything WordPress does.

The target is PHP 8.3. It’s not optional for sites that handle user data, payments, or sensitive content.

2. AI Credential Management Gets a Security Gate

WordPress 7.0 ships the Abilities API — a framework for integrating AI services directly into the block editor. WordPress 7.0 natively supports three AI providers at launch: OpenAI, Anthropic (Claude), and Google Gemini.

This introduces a new attack surface: stored API credentials. A compromised WordPress admin account that has stored OpenAI or Anthropic credentials gives an attacker access to both your WordPress site and your AI API billing account.

AI Experiments 1.0 is targeting a plugin release alongside core, with admin approval required before plugins can use stored AI credentials.

The approval gate prevents plugins from silently consuming stored API keys without explicit admin consent. It’s a meaningful control — one that would otherwise be trivially bypassed by a malicious or compromised plugin.

What this doesn’t protect: credential storage itself. API keys stored in the WordPress database are only as secure as your database. Enforce database access controls and encrypt credentials at rest if your hosting environment supports it.

3. OPCache Visibility in Site Health

WordPress 7.0 adds OPCache status to Site Health → Info → Server. This is useful for confirming the PHP-level cache is running, which matters disproportionately for pages WordPress can’t cache, like cart and checkout in WooCommerce.

OPCache is a performance feature, but it has security relevance: it reduces repeated disk reads of PHP files, which also reduces the exposure window for attacks that attempt to inject code into PHP files on disk. The Site Health addition makes OPCache status visible to administrators without requiring server-level access — useful for auditing shared hosting environments where server configuration is opaque.

4. Ten Security Patches Shipped in Beta 4

WordPress 7.0 Beta 4 includes 10 security patches, along with more than 49 updates and fixes since the Beta 3 release. These patches were applied to 6.9 as well via the 6.9.2 release cycle. Sites on 6.9.4 already have them. Sites upgrading to 7.0 from anything older than 6.9.4 need the full 7.0 update.

5. What Got Cut: Real-Time Collaboration

Real-time co-editing was the headline feature of WordPress 7.0 since it was announced. It was also the reason the release was delayed from April 9 to May 20 — a critical architectural flaw in the collaboration system required rebuilding a database table from scratch.

Then, on May 8, Mullenweg removed the feature from the release entirely.

The security relevance: real-time collaboration introduces WebSocket connections, shared session state, and concurrent write access to post content. Getting those controls wrong creates authorization bypass vulnerabilities — exactly the class of flaw that hit the Notes feature in 6.9.2 and required three patch releases to fully close.

Cutting the feature was the right call. A rushed real-time collaboration system would have shipped with the same categories of authorization and data-access risks that plagued Notes. The core team’s willingness to pull a headline feature rather than ship it with known architectural issues is a meaningful signal about how they’re approaching security in the 7.0 era.

What Didn’t Change: The Gaps That Still Require Plugins

Native 2FA Still Doesn’t Exist

WordPress 7.0 does not include two-factor authentication. As of April 2026, passkey support in WordPress is still plugin-only. There is no core toggle. 2FA and passkeys require a plugin — WP 2FA covers both in the free tier.

No Native WAF

WordPress 7.0 ships no firewall capability. All WAF functionality requires either a security plugin (Wordfence runs inside PHP) or a cloud-based service (Cloudflare, Sucuri) that sits in front of your server.

Plugin Vulnerabilities Still Dominate

The Security Team decided to package a new beta release (7.0 beta 4) to keep everyone protected from the patched vulnerabilities, including the dedicated members of the community focusing their time and effort on testing the upcoming release. But core patches don’t touch plugins. 90% of WordPress vulnerabilities originate in plugins and themes. WordPress 7.0 doesn’t change that ratio. Eleven thousand plugin vulnerabilities were disclosed in 2025. Core is not where your risk lives.

The Backporting Problem: Which Old Versions Still Get Patches?

WordPress has historically backported security fixes to older versions as a courtesy, but that courtesy is shrinking.

The 6.9.2 security patches were backported to versions as far back as 4.7. But that policy has limits, and each major release cycle narrows the list of supported branches. If you’re running a significantly outdated WordPress version, don’t rely on backports as a substitute for upgrading.

The only version with full patch coverage for the 6.9.x security issues is 6.9.4. For 7.0, the patches are baked in.

Your 7.0 Security Upgrade Checklist

Before updating to 7.0:

1. Check your PHP version at Tools → Site Health → Info → Server. If you’re below PHP 7.4, update PHP first — WordPress 7.0 won’t install on older versions. Target PHP 8.3.
2. Take a complete backup — files and database. “My host backs up automatically” is not a recovery plan. Know that you can actually restore.
3. Test on staging first. WordPress 7.0 merges Gutenberg plugin versions 22.0 through 22.6 into core. Plugins that extend the block editor are most likely to have compatibility issues.
4. Check that your critical plugins have confirmed 7.0 compatibility. Forms, ecommerce, memberships, and page builders are the highest-risk categories.
5. Only then update your live site — and ideally not on a Friday afternoon.

After updating:

6. Verify your PHP version in Site Health post-update.
7. If you use AI integrations, review which plugins have access to stored API credentials under the new Abilities API. Revoke access for any plugin you don’t actively use.
8. Confirm your 2FA plugin is still active. Security plugins have the highest rate of post-major-update conflicts.
9. Run a malware scan. Major updates occasionally clear file-modification monitoring caches, making it a good time to baseline your file integrity state.

CVE Summary: Issues Fixed in the 7.0 Cycle

CVE	Vulnerability	CVSS	Fixed In
CVE-2026-3907	PclZip path traversal (file write outside directory)	Medium	6.9.4 / 7.0
CVE-2026-3906	Notes feature authorization bypass	Medium	6.9.4 / 7.0
CVE-2026-3908	XXE injection in getID3 media library	Medium	6.9.4 / 7.0
—	Blind SSRF in core	Medium	6.9.2 / 7.0
—	Stored XSS via data-wp-bind directive	Medium	6.9.2 / 7.0
—	Stored XSS in nav menus	Medium	6.9.2 / 7.0
—	PoP-chain in HTML API and Block Registry	Medium	6.9.2 / 7.0
—	Regex DoS in numeric character references	Low	6.9.2 / 7.0
—	XSS override of client-side admin templates	Medium	6.9.2 / 7.0
—	AJAX query-attachments authorization bypass	Medium	6.9.2 / 7.0

All ten vulnerabilities required authentication to exploit. None were rated critical (CVSS 9+). The PclZip path traversal, Notes authorization bypass, and getID3 XXE were incompletely patched in 6.9.2 and 6.9.3, and only fully fixed in 6.9.4 and 7.0.

Frequently Asked Questions

What security features does WordPress 7.0 add?

WordPress 7.0 drops PHP 7.2 and 7.3 support (forcing sites off end-of-life PHP), adds AI credential management with an admin approval gate via the Abilities API, includes OPCache visibility in Site Health, and ships the security patches from the 6.9.2 through 6.9.4 cycle baked into the release.

Does WordPress 7.0 include two-factor authentication?

No. 2FA and passkeys remain plugin-only in WordPress 7.0. WP 2FA by Melapress provides both in its free tier.

Is WordPress 7.0 safe to install?

Yes — after testing on staging. Beta 4 shipped 10 security patches, and the final release went through four release candidates. Test critical plugins for compatibility before updating production, particularly anything that extends the block editor.

What happened with WordPress 7.0 real-time collaboration?

Real-time co-editing was pulled from the release on May 8 by Matt Mullenweg, six weeks after the release was delayed specifically to fix collaboration architecture issues. It is not in WordPress 7.0. No replacement release date has been announced.

What PHP version does WordPress 7.0 require?

The minimum is PHP 7.4, but PHP 7.4 reached end-of-life in November 2022 and has unpatched CVEs. The core team recommends PHP 8.3 for performance and security. Sites on PHP 7.2 or 7.3 cannot update to WordPress 7.0.

Which versions have the full security patch set from the March 2026 cycle? Only WordPress 6.9.4 and 7.0. Three of the ten vulnerabilities patched in 6.9.2 were incompletely applied and only fully fixed in 6.9.4. Sites on 6.9.2 or 6.9.3 should update immediately.