Over the past year and a half, an intensive engineering overhaul has been transforming how WordPress protects its development infrastructure from supply chain risks. The initiative targets the automated pipelines that verify and deploy code before it ever reaches production websites.
The WordPress Security Team has spent 18 months reinforcing these continuous integration and continuous delivery (CI/CD) environments. According to team representative John Blackbourn, they aim to enforce these rigorous security standards across every single repository within the WordPress GitHub organization.
Details of this campaign were published on the Make WordPress Security blog by Blackbourn – a core committer sponsored by Human Made. While supply chain attacks targeting automated workflows have disrupted the tech industry, WordPress has remained unaffected due to multiple rounds of proactive workflow hardening.
GitHub Actions functions as the core automation layer driving the WordPress development infrastructure. When contributors open a pull request, these workflows run software tests, check code quality, and handle publishing or deployment. Compromising these pipelines allows attackers to inject malicious code, steal credentials, or plant backdoors without altering source code.
Recent industry exploits have targeted exactly these vulnerabilities, hitting platforms like TanStack and BitWarden. Similar structural weaknesses were also weaponized in separate incidents impacting Microsoft, DataDog, and the CNCF.
The public update catalogs systematic changes dating back to January 2025, when the main wordpress-develop repository was overhauled to eliminate unsafe configurations, tighten permissions, and reduce credential exposure. The gutenberg repository followed in April 2025, with workflow hardening since expanding to at least eight other repos, including performance, wordpress-playground, two-factor, and php-ai-client.
Two automated static analysis tools now scan workflow files for defects. The team introduced Actionlint in January 2025, followed by Zizmor, a specialized scanner added to wordpress-develop in April 2026 and to gutenberg this month. A formal GitHub Actions Workflow Standards handbook page was also published in April 2026.
According to Blackbourn, the long-term objective is to implement and enforce this scanning at the organization level rather than within individual repositories. The Security Team is currently finalizing the methods to achieve this systemic shift.
In May 2026, the project expanded its HackerOne bug bounty program to explicitly cover supply chain and CI/CD workflows. This adjustment allows security researchers to earn monetary rewards for reporting vulnerabilities in build automation, rather than exclusively focusing on WordPress core.
To accelerate defenses, GitHub organization owners are now authorized to self-merge security hardening updates when necessary. This protocol allows the team to deploy vital fixes rapidly without waiting for individual repository maintainers who may be temporarily unavailable.
This technical initiative aligns with a broader governance push led by Jonathan Desrosiers, a Bluehost-sponsored core committer, whose efforts since June 2025 define hosting prerequisites within the WordPress organization. The team is moving toward a mandatory, standardized SECURITY.md file for all repositories, paired with a corresponding HackerOne policy.
Further organization-wide policies remain on the radar – including secret scanning, required rulesets, and immutable releases. Security configurations for Node and npm are also planned, though the team will defer enforcement until wordpress-develop and gutenberg migrate to at least Node v24.
These infrastructure upgrades follow a turbulent period for supply chain security across the wider ecosystem. Recent incidents include a 13-year backdoor campaign affecting 44 plugins discovered by Austin Ginder – with the plugins team counting 56 – alongside multiple plugin ownership takeovers and the OptinMonster CDN attack.
Contributors who wish to assist with the ongoing hardening work can participate directly. The team welcomes feedback via comments on Blackbourn’s post or through direct engagement in the #core-build-test-tools channel on WordPress Slack.
