WordPress 6.9.2 was released on March 10, 2026. It is a security release that addresses 10 security issues, and the WordPress Security Team recommends that you update your sites immediately.
Security fixes in this release
The official announcement lists the following issues, all responsibly reported:
- A blind SSRF issue
- A PoP chain weakness in the HTML API and Block Registry
- A regex denial of service weakness in numeric character references
- A stored XSS in nav menus
- An authorization bypass in the AJAX query attachments action
- A stored XSS via the data-wp-bind directive
- An XSS that allows overriding client side templates in the admin area
- A PclZip path traversal issue
- An authorization bypass on the Notes feature
- An XXE in the external getID3 library
The Security Team worked with the maintainer of getID3 to coordinate a fix in that library as well. As a courtesy, the fixes were backported to all branches eligible for security fixes, back to 4.7 at the time of release, but only the most recent version of WordPress is actively supported.
A fast follow: 6.9.3
After 6.9.2 shipped, some sites reported a blank front end. WordPress 6.9.3 was released the same day to fix it. If you have not updated yet, go straight to the latest 6.9 release so you get the security fixes and the bug fix together.
Which sites need WordPress 6.9.2 first
Several of these issues involve logged in roles, the media library and admin screens, so sites with many editors or contributors have the most to gain from updating quickly. For sites on automatic background updates, the update should arrive on its own, but it is still worth confirming the version in the dashboard.
Blind SSRF. A server side request forgery issue can let an attacker use your server to send requests it should not make, even without seeing the response. Closing it matters most for sites on cloud hosting or private networks. We apply the update on sites we manage as soon as it is available and check that features which fetch remote content, like embeds and feeds, still work.
PoP chain in the HTML API and Block Registry. A PoP chain is a building block attackers combine with a separate flaw, often PHP object injection in a plugin, to run their own code. Fixing it in core removes a piece of that chain even if a plugin on your site has a weakness of its own. Because the fix touches the Block Registry, we test custom blocks on staging after updating.
Regex denial of service in numeric character references. This weakness let specially crafted text tie up the server while WordPress processed it, which can slow a site down or stall it. Sites that accept text from the public, through comments or forms, gain the most. After updating, we confirm that content with special characters and symbols still displays correctly.
Stored XSS in nav menus. Navigation menus appear on nearly every page, so script stored in a menu could reach every visitor and every administrator. On sites where several people can edit menus, we review who has that access, and we check that menus still render correctly on desktop and mobile after the update.
Authorization bypass in the AJAX query attachments action. This is the request that lists items in your media library, and the bypass could show media details to users who should not see them. That matters for membership sites and intranets that keep private files in the library. After updating, we browse the media library as different roles to confirm each person sees only what they should.
Stored XSS via the data-wp-bind directive. The data-wp-bind directive is part of the Interactivity API behind interactive blocks such as Navigation and Search. This fix keeps stored script out of content that uses those blocks. We test the interactive parts of your site, including menus, search and any custom interactive blocks we built, once the update is in place.
XSS overriding client side templates in the admin area. Script that runs in an administrator's browser is one of the quickest paths to a full site takeover, and this issue could let an attacker override templates the admin builds in the browser. Updating closes it for every logged in user. Afterward, we test the admin screens your team uses most, along with any custom admin screens we built.
PclZip path traversal. PclZip handles zip files, such as plugin and theme uploads, and a path traversal flaw could let a crafted zip file write files outside the folder it belongs in. We update right away, confirm plugin and theme installs still work, and limit zip upload rights on client sites to the people who truly need them.
Authorization bypass on Notes. Notes arrived in 6.9, and teams use them for editorial feedback that can include unpublished plans. This fix keeps users from getting around the permission checks on notes. After the update, we test Notes with each editorial role on staging to confirm people see and change only what they should.
XXE in the getID3 library. getID3 reads details from audio and video files, and an XML external entity flaw could let a crafted file make the server read or request data it should not. The Security Team coordinated the fix with the library's maintainer. Sites that accept media uploads from members or contributors should update first, and we test audio and video uploads afterward.
Want WordPress 6.9.2 and every release after it handled for you? Our support and maintenance plans cover tested core, theme and plugin updates, uptime monitoring and help when something breaks. Questions about your site? Contact us and we will take a look.
