WordPress 6.9.4 Quietly Fixes What 6.9.2 Left Exposed
If you thought the WordPress 6.9.2 security chaos was over, there’s one more chapter. WordPress 6.9.4, released on March 11, 2026, addresses security vulnerabilities that the original 6.9.2 release failed to fully patch. The WordPress Security Team’s own words: “not all of the security fixes were fully applied.”
What Happened
Here’s the full timeline:
- March 10, 6.9.2: Security release patches 10 vulnerabilities. Some sites crash due to a template-loading conflict with certain themes.
- March 10, 6.9.3: Emergency follow-up hours later to fix the crash. No new security fixes — just restoring broken sites.
- March 11, 6.9.4: The Security Team discovers that some of the 6.9.2 security patches were incomplete. This release finishes the job.
Three releases in 24 hours. That’s not a great look, but credit where it’s due: the team moved fast to close the gaps.
According to Wordfence, 6.9.4 addresses four medium-severity vulnerabilities (all requiring authentication):
- XML External Entity Injection (CVSS 6.5): Author-level users could exploit the bundled getID3 library to read arbitrary files on the server
- Stored Cross-Site Scripting (CVSS 4.4): Exploitable by administrators, affecting how certain data was sanitized
- Arbitrary Note Creation (CVSS 4.3): The Notes feature (introduced in WordPress 6.9) had a permissions gap — Subscriber-level users could create notes on any post via the REST API comments controller without proper capability checks
- Information Disclosure (CVSS 4.3): Author-level users could access data they shouldn’t have been able to see
The broader 6.9.2 patch set also covered a blind SSRF, regex denial-of-service, PclZip path traversal, AJAX authorization bypass, and stored XSS in nav menus — totaling 10 vulnerabilities across the 6.9.2–6.9.4 cycle.
Why It Matters
Incomplete security patches are worse than no patches in one specific way: they create a false sense of security. Site owners who updated to 6.9.2 or 6.9.3 believed they were protected, but some vulnerabilities remained open. This is exactly why the Patchstack security report found that 20% of exploited vulnerabilities are attacked within 6 hours of disclosure — attackers watch patch releases to find incomplete fixes.
The Notes feature vulnerability is particularly interesting. Introduced in WordPress 6.9 just three months ago, it already had a permissions-check gap. New features shipping with security bugs is a reminder that even core WordPress needs thorough review — not just plugins.
What You Should Do
Check your version now. Go to your Dashboard → Updates. You should be on 6.9.4 or later. If auto-updates are enabled, you’re likely already patched. If not, update immediately.
Verify auto-updates are working. This three-release sequence is a good argument for keeping automatic background updates enabled. You can check this under Dashboard → Updates → “This site is automatically kept up to date.”
Review user roles. The Note Creation and XSS vulnerabilities required authenticated access (Subscriber and Author level respectively). If you have open registration enabled, audit your user list for suspicious accounts.
Sources
Written by Marvin
Our team tests and reviews WordPress products to help beginners make confident choices.
Learn more about our team →You might also like
Critical WooCommerce Vulnerability Patched: CSRF Flaw Could Create Rogue Admin Accounts
A critical CSRF vulnerability affecting 52 WooCommerce versions (5.4–10.5.2) could let attackers create admin accounts and access customer data. Auto-patches rolled out March 2.
postWordPress Ships 3 Security Patches in 24 Hours After 6.9.2 Breaks Sites
WordPress released versions 6.9.2, 6.9.3, and 6.9.4 within 24 hours after the initial security patch caused white-screen crashes and left vulnerabilities incompletely fixed.
postThe EU Cyber Resilience Act Hits WordPress in September: What Plugin Developers Need to Know
Starting September 2026, the EU Cyber Resilience Act requires WordPress plugin developers to implement formal vulnerability reporting, documented security processes, and 24-72 hour response times — or face fines up to €15 million.
postADA Web Accessibility Deadline Hits April 24: Government WordPress Sites Must Meet WCAG 2.1 AA
State and local governments with populations over 50,000 must make their websites WCAG 2.1 AA compliant by April 24, 2026 — including all WordPress sites, third-party content, PDFs, and web apps.