Ehtisham Siddiqui 12:30 pm on September 1, 2026  

Updates to the WordPress Vulnerability Disclosure Program

Improving the security of WordPress means both finding and fixing vulnerabilities proactively, and making sure the reports we receive through responsible disclosure are focused on issues with meaningful security impact.

As part of the broader work underway through the Core Security Initiative, the security team is investing more in the security release process, working through existing findings, and expanding proactive vulnerability research and tooling. Alongside that work, we’re updating the Vulnerability Disclosure Program guidelines so that our time, and the time of security researchers, is focused on valid vulnerabilities with clear and significant impact.

For any in-scope asset excluding WordPress CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. and GutenbergGutenberg The Gutenberg project is the new Editor Interface for WordPress. The editor improves the process and experience of creating new content, making writing rich content much simpler. It uses ‘blocks’ to add richness rather than shortcodes, custom HTML etc. https://wordpress.org/gutenberg/, issues requiring a role that can only be granted by an administrator will generally no longer be eligible unless they demonstrate a high-severity escalation and security impact. This includes roles like Contributor. The ability for one authenticated role to perform an action normally available to another authenticated role will also generally not be sufficient on its own, unless it leads to a high impact escalation. WordPress Core and Gutenberg will, for now, continue to follow our existing eligibility guidelines. More examples can be found on our program policy page.

We encourage researchers to focus on vulnerabilities with a clear security impact, particularly high-severity issues that can be exploited without authentication or by low-privileged users such as Subscribers.

Responsible disclosure continues to be an important part of WordPress security and issues can be reported here. Combined with the work happening within the project to proactively identify and address vulnerabilities, focusing reports on higher-impact issues will help us spend more time on the findings that make WordPress and its ecosystem meaningfully safer.

Rudy Faile 4:52 pm on August 28, 2026  

The Core Security Initiative

Over the past year, the WordPress project has seen a substantial increase in the volume of incoming security reports. Much of this growth reflects the rapid advancement of frontier AI models and their growing capability to assist with security research: it has never been easier to analyze code for potential vulnerabilities, and reporting volume across the whole WordPress ecosystem has risen accordingly.

This is a good problem to have: more eyes on WordPress makes WordPress safer, but it requires the project to scale how we triage, validate, and resolve what comes in. The topic came up during the security team meeting at WordCamp US last week, and today we’re sharing more about the work underway.

The security team has begun a coordinated effort called the CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. Security Initiative with one goal: a stronger, safer WordPress. It focuses a coordinated effort under three pillars: ABC.

A better release process

Building a tighter, more automated security release process, with improved end-to-end testing, so fixes ship reliably and predictably. The security team is scheduling upcoming security releases as a result.

Breaking the backlog

Bringing on more team members and volunteers to work through the queue of open reports and known issues, with the aim of driving open findings down to zero.

Crush vulnerabilities with AI

Applying AI-assisted scanning and tooling to find vulnerabilities before they can be exploited, complementing the reports received through responsible disclosure.

This work is supported by the WordPress core security team, longtime core contributorsCore Contributors Core contributors are those who have worked on a release of WordPress, by creating the functions or finding and patching bugs. These contributions are done through Trac. https://core.trac.wordpress.org, and contributors sponsored by companies across the WordPress ecosystem.

How you can help

Security research and responsible disclosure remain the front line. If you believe you’ve found a vulnerability in WordPress core, please report it through the official channel at hackerone.com/wordpress and please review the reporting guidelines before submitting, as report quality matters more than ever at this volume.

John Blackbourn 9:28 pm on July 13, 2026  

Hardening GitHub Actions workflows across the WordPress organisation

In recent months several supply chain attacks have successfully exploited weaknesses in GitHubGitHub GitHub is a website that offers online implementation of git repositories that can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged by the repository owner. https://github.com/ Actions workflow files and in published actions across many organisations and repos on GitHub. The effects of these attacks can be considerable due to the highly privileged environment in which workflows run. They can lead to malicious releases being published, backdoors being inserted into packages, and secrets, such as APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. keys, being exfiltrated. Notable instances include TanStack, actions-cool, BitWarden, and an attack that affected Microsoft, DataDog, and CNCF. The tj-actions organisation was attacked in a similar manner last year.

In many instances, these attacks exploit misconfigured workflows that unnecessarily grant higher than necessary permissions, use the pull_request_target trigger in an unsafe manner, or don’t make use of dependency pinning.

The WordPress project isn’t immune to these attacks, but fortunately it’s so far not directly been affected due to several rounds of hardening applied to workflow files over the last 18 months. This work remains ongoing.

What’s already been done

Several of these changes tightened the permissions directives. Ensuring each workflow runs with the lowest permissions required for each job reduces the risk of an attacker being able to exploit an exposed token or otherwise elevate their permission beyond what is minimally necessary.

What’s being worked on

While great progress has been made to date, there’s still a large amount of work remaining. The current long-term plan is for workflow file scanning with Actionlint and Zizmor to be implemented and enforced at the organisation level instead of in each repository. This ensures that every repository consistently follows secure best practices within Actions-related files. The Security Team is still discussing the best way to accomplish this and how to codify the resulting policy.

You can expect to see more pull requests to be opened in repos across the WordPress organisation in the coming weeks as a part of the continued efforts to harden workflow files by addressing any issues flagged by Actionlint and Zizmor.

Note: If a security hardening pull request is opened by someone who has the “Owner” role on the WordPress organisation on GitHub, it’s within their remit to self-merge the pull request if they deem it necessary, or for another owner of the organisation to do so.

Wider security policy work

As a result of the ongoing efforts to clarify the requirements for a repository to be a part of the WordPress organisation, the Security Team is discussing the best way to facilitate security vulnerability reports for all repos in a sustainable way. As a result the team hopes to standardise on a security policy that will apply to all repos under the organisation, and this may well manifest as a central SECURITY.md file and a corresponding HackerOne policy. Stay tuned for more info on these policies soon.

Once that work is complete, the team will look at implementing further organisation-wide repo security policies such as requiring immutable releases, secret scanning, and requiring rulesets to be in place.

While the Security Team has no immediate plans to enforce policies for the secure configuration of Node and npm, it’s likely that this will be done once the wordpress-develop and gutenberg repos are updated to use at least Node v24. See gutenberg#72973. Stay tuned for more guidance on Node and npm configuration in the coming weeks.

Want to get involved?

For the most part, securing GitHub Actions workflow files is hardening work that’s performed in public, not in private, and any contributor can help out. If you’re interested in helping out please leave a comment here or post a message in the #core-build-test-tools channel in WordPress SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/.

Props to @desrosj for peer review and everyone who has contributed to this work over the last 18 months.

Jonathan Desrosiers 8:18 am on February 1, 2026
Tags: make.wordpress.org/ai,   

X-post: AI Guidelines for WordPress

X-comment from +make.wordpress.org/ai: Comment on AI Guidelines for WordPress

Jonathan Desrosiers 11:29 am on June 28, 2025
Tags: make.wordpress.org/core,   

X-post: Proposal: Clarifying Core’s Database Support Policy

X-comment from +make.wordpress.org/core: Comment on Proposal: Clarifying Core's Database Support Policy

Isotta Peira 1:06 pm on June 23, 2025
Tags: ,   

X-post: The Incident Response Team is looking for new members

X-comment from +make.wordpress.org/community: Comment on The Incident Response Team is looking for new members

John Blackbourn 6:02 pm on June 18, 2025  

Security updates will cease for WordPress versions 4.1 through 4.6

The WordPress Security Team will cease providing updates for WordPress versions 4.1 – 4.6 in July 2025.

Officially only the latest version of WordPress is supported. The Security Team historically has a practice of backporting security fixes, as necessary, as a courtesy to sites on older versions in the expectation the sites will be automatically updated.

Background

Since December 2022 these courtesy backports have been applied when necessary to versions of WordPress back to 4.1. Versions 4.1 – 4.6 have now reached levels of usage where the benefit of providing these updates is outweighed by the significant effort involved in maintaining not only the branches themselves, but also the tooling and infrastructure for performing the backporting, building, testing, and releasing that’s required in order to continue having confidence in backporting to these branches.

Well below 1% of sites are running WordPress 4.1 – 4.6 as of June 2025. Conversely, backporting security updates to older versions of WordPress takes a substantial amount of time and effort that compounds when each new major version is released. The effect of this imbalance means that during a security release the security team spends most of the time preparing backports for a minority of WordPress installations. By dropping support for these older versions, the team can continue to focus on the latest versions of WordPress which are used by the overwhelming majority of WordPress websites.

Process

Versions older than 4.7 will display a non-dismissible notice in the admin dashboard informing users that an update is available. In the final updates for these WordPress versions, these notices will be made more prominent and inform the administrator that their version of WordPress is no longer receiving security updates.

The text strings and translations for these messages already exist in all branches and won’t change.

TracTrac Trac is the place where contributors create issues for bugs or feature requests much like GitHub.https://core.trac.wordpress.org/. ticket

Changes to the trunk branch and the affected branches can be tracked in this Core Trac ticket.

Thanks to @desrosj for reviewing this post prior to publishing

Ehtisham Siddiqui 1:28 am on March 5, 2025  

First major release of 2025: WordPress 6.8

WordPress 6.8 will be the first major releaseMajor Release A set of releases or versions having the same major version number may be collectively referred to as “X.Y” -- for example version 5.2.x to refer to versions 5.2, 5.2.1, and all other versions in the 5.2. (five dot two dot) branch of that software. Major Releases often are the introduction of new major features and functionality. this year. The BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 version of this release cycle was published earlier today. With this, we’re inviting security researchers to help us make WordPress 6.8 as secure as possible!

As is our tradition, between the release of WordPress 6.8 Beta 1 and the final Release CandidateRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. (RCRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge.), we are offering double bounties for valid security vulnerabilities found in the new code. WordPress 6.8 Beta 1 contains over 370 enhancements and 520 bug fixes – more details are in the release post and testing guidelines for key features are here.

Full schedule of the 6.8 release cycle is here, with Release Candidate 3 set to be released on April 8.

Think you have found a security issue? Please reach out via HackerOne and we will take a look.

Ehtisham Siddiqui 5:38 am on June 4, 2024  

WordPress 6.6 is coming!

WordPress 6.6 will be the next major releaseMajor Release A set of releases or versions having the same major version number may be collectively referred to as “X.Y” -- for example version 5.2.x to refer to versions 5.2, 5.2.1, and all other versions in the 5.2. (five dot two dot) branch of that software. Major Releases often are the introduction of new major features and functionality..

With its BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 set to be released on June 4th, 2024, it is about time we start inviting security researchers to look into new bugs!

Any security issue that is found after the release of WordPress 6.6 Beta 1 and before the final RCRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. is out, will be eligible for double the bounties. The security issue should be in the new code that is introduced in 6.6.

Full schedule of WordPress 6.6 Beta/RC releases is here. If you believe you have found a valid bug, please reach out to us via HackerOne. Please go through the program policy before submitting a report.

Ehtisham Siddiqui 4:13 pm on February 12, 2024  

Welcoming 2024 with WordPress 6.5 Beta 1

It’s start of a new year, and WordPress 6.5 is almost ready – the first major releaseMajor Release A set of releases or versions having the same major version number may be collectively referred to as “X.Y” -- for example version 5.2.x to refer to versions 5.2, 5.2.1, and all other versions in the 5.2. (five dot two dot) branch of that software. Major Releases often are the introduction of new major features and functionality. of 2024!

The BetaBeta A pre-release of software that is given out to a large group of users to trial under real conditions. Beta versions have gone through alpha testing in-house and are generally fairly close in look, feel and function to the final product; however, design changes often occur as part of the process. 1 is set to be launched tomorrow, February 13, 2024. Like previous major releases, we’re inviting security researchers to try and find security issues between Beta 1 and the final release candidateRelease Candidate A beta version of software with the potential to be a final product, which is ready to release unless significant bugs emerge. that target the new code. Valid submissions will be eligible for double the bounties.

Several new features and improvements are planned for WordPress 6.5. As an example, here’s a summary of the improvements we’re going to see in the Editor, where one likely spends most of their time.

Full release schedule is here.

How to report security issues?
WordPress security team accepts security issues through our HackerOne program. The general eligibility criteria for reports is mentioned in the program policy and must be followed.

As a reminder, reports that highlight issues in the new code will be eligible for double bounties.