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

• January 2025: Workflow files in the wordpress-develop repository were significantly hardened to remove unsafe expressions, tighten permissions directives, and reduce unnecessary credential persistence, among other changes. The Actionlint workflow file linter was also introduced. See wordpress-develop#8007.
• April 2025: Workflow files in the gutenberg repo were hardened in a similar manner, and Actionlint was introduced into that repo too. See gutenberg#69126.
• June 2025: Twenty unmaintained repos in the WordPress org were archived. Among other benefits, this ceases their Actions workflows.
• April 2026: The Zizmor static analysis tool was introduced into the wordpress-develop repo. See wordpress-develop#9767.
• April 2026: The GitHub Actions Workflow Standards handbook page was introduced, covering what’s expected of workflow files and detailing common issues flagged by Actionlint and Zizmor.
• May 2026: Workflow files were hardened in several repos, primarily to minimally-scope their permissions. See performance#2471, wordpress-playground#3628, two-factor#892, mcp-adapter#179, sqlite-database-integration#404, php-ai-client#235, Learn#3444, and wporg-main-2022#686.
• May 2026: A reusable workflow that’s used by dozens of repos across the WP-CLIWP-CLI WP-CLI is the Command Line Interface for WordPress, used to do administrative and development tasks in a programmatic way. The project page is http://wp-cli.org/ https://make.wordpress.org/cli/ organisation was hardened to remove unsafe behaviour. See wp-cli@bd7290a.
• May 2026: Further hardening of workflows in wordpress-develop that use the potentially risky pull_request_target trigger. See wordpress-develop#11808.
• May 2026: Supply chain and CI/CD workflows were specifically documented as a valid target in the HackerOne bug bounty program policy.
• July 2026: Zizmor has been introduced into the gutenberg repo. See gutenberg#71523.

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.

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.

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