Most site owners only see one part of the process that results in a new version of WordPress being released that fixes a security vulnerability: a dashboard notification that reads “An updated version of WordPress is available”. That’s intentional, the software is built to “just work”. Everything before that notification happens behind the scenes, often over days or weeks. The process might start with a report about a weakness from a security researcher, proceed through verification, fixing the bug, testing, and subsequent coordination with some of the world’s largest web hosts and service providers. All activity that stays mostly outside of public view.
The WordPress security release process runs through a consistent set of stages: report, verify, triage, patch, test, coordinate, release, and notify. A critical severity fix may ship within hours, while lower severity issues wait for the next scheduled release, but the release and deployment process handles security issues at the speed that enterprise security teams depend on.
As one of the most widely used technologies on the internet, vulnerabilities in WordPress are announced, scrutinised, and discussed publicly. While this can create the impression that WordPress experiences more security issues than alternative platforms, it also reflects one of the fundamental strengths of open-source software: transparency. Potential issues are exposed to continuous review by a global community of contributors, security researchers, agencies, hosting providers, and enterprise users. With the rise in cybersecurity capabilities of frontier AI agents, this transparency is more important than ever.
Where WordPress Vulnerability Reports Come From
Many security issues in WordPress are responsibly reported to the WordPress Security Team via its well-established vulnerability disclosure program on HackerOne. A mixture of human review and AI augmentation results in each report being prioritised and routed to the appropriate development team accordingly.
Verifying and Triaging the Report
Not every submission of a security vulnerability turns out to be exploitable. Once the team confirms an issue is real, they assess how serious it is. Some issues can wait for the next scheduled release. Others need to move immediately.
That assessment happens inside a private workspace, separate from WordPress’s public development tools. This is because tracking an unpatched vulnerability in the open would hand attackers and their AI agents the same information the security team is racing to fix.
Immediate Release or Scheduled Release? How WordPress Decides
Severity determines the release path. The team pushes a critical issue out as an immediate, standalone security release, skipping the normal cadence. The risk of waiting outweighs the disruption of an out-of-cycle update.
A minor issue waits for the next regularly scheduled release instead, bundled alongside other fixes. That’s a risk-management decision. The team weighs exploitability and real-world impact against the cost of pushing an emergency release across millions of sites.
Coordinated Disclosure With Hosts and Security Vendors
The WordPress open source project has a uniquely close relationship with some of the largest web hosts and platform providers in the world, due to its ubiquity and the many members of the WordPress community who work for those companies. WordPress operates a private discussion forum for some of these companies so they can securely discuss upcoming fixes and plan mitigations in advance.
When a more serious vulnerability occurs, the fix doesn’t move straight from ready to public. Major hosting providers, CDNs, and web application firewall vendors are given advance notice to put protective measures in place prior to a security release being made available publicly.
WordPress 7.0.2, released in July 2026, is an example of this process working as intended. The WordPress security team worked closely with web hosts and CDN providers to put mitigation in place across tens of millions of WordPress websites before the release was made publicly available, due to the severity of the issue that was fixed. With the rise of autonomous AI agents that can quickly exploit known issues, this is more important than ever.
Publishing the Advisory: The Announcement Process
Once a fix ships, the team publishes an advisory on the WordPress.org News site. It details what was fixed and how serious the issues were. A CVE – a standardised public identifier that lets security tools, scanners, and enterprise vulnerability-management systems track the issue consistently – may be published for particularly severe issues.
The advisory will also credit the researcher who reported it. Being publicly credited builds a researcher’s reputation, which incentivises them to report privately rather than go public first.
How the Fix Actually Reaches Your Site
Administrators who haven’t turned on automatic updates will see a dashboard prompt to update manually. They’ll also be given a summary screen that summarises what changed.
For sites with automatic background updates turned on (the default for minor and security releases) the fix will be completed without any action needed. The administrator simply gets a confirmation email once it’s done. These automated updates allow a large share of the WordPress ecosystem to gain protection within a matter of hours after a fix ships, removing the need for an individual site owner to notice a notification and act on it before an attacker does.
What This Means for Enterprise WordPress Security Teams
For a single site, this automatic process is usually sufficient. However, Enterprise environments tend to need something more substantial. Staging environments, regression testing, and change-control processes have to run before anything touches production. That’s why many enterprise platforms prefer to disable or tightly control automatic updates.
Enterprise teams need their own patch verification and rollout discipline whenever there is a new WordPress security release. However, the WordPress Security Release process itself is transparent enough about how a fix moves from a researcher’s report to a trusted release, to allow enterprise teams to manage each release with confidence and understanding.
FAQ: WordPress Security Release Process
Mostly through responsible disclosure. Researchers report issues privately, either via WordPress’s HackerOne program or directly to the security team, instead of publishing them immediately.
It depends on severity. The team can patch and release critical issues within days as an immediate security release. Minor issues usually wait for the next regularly scheduled release.
Yes, by default, for minor and security releases. Administrators can disable automatic background updates, and many enterprise environments do this to test changes before deployment.
The team treats critical issues as serious enough to justify an immediate, standalone release outside the normal schedule. Minor issues wait for the next scheduled release alongside other fixes.
The security advisory names the researcher who responsibly disclosed the issue, reinforcing the incentive to report privately rather than publish vulnerabilities publicly.