WordPress Security Team Turns AI Tools Inward to Hunt Core Bugs Before Reports
After clearing a massive report backlog, the WordPress Security Team is pointing its AI triage tooling at the core codebase itself.
The WordPress Security Team has cut its unreviewed bug report queue from 359 to double digits and is now testing AI tooling that searches WordPress core for vulnerabilities before anyone reports them. Automattic Head of Security Rudy Faile described the change on the Making WordPress Secure blog: the same agentic system built to triage incoming reports is being pointed at the codebase.
From triage to proactive discovery
The team received more than 3,000 security reports this year—more than the previous twelve years combined. Much of the increase comes from AI-assisted research. In response, the Core Security Initiative formalized three priorities: tighter, more automated releases; clearing the backlog; and using AI to find issues first.
The triage system already reads reports, attempts secure reproduction, and posts a summary plus severity recommendation. Human researchers still make the final call. The untriaged queue dropped sharply after the team tightened program scope on 1 September and deployed the tooling. Nearly 3,000 reports have been closed this year.
Faile wrote that reacting is no longer enough. The same tooling, running on open-weight models with purpose-built harnesses, is now hunting for vulnerabilities in core. Anything it surfaces goes through the same release process as researcher reports. The team is still benchmarking and testing; no public launch date has been given.
Independent scanning and human gates
WordPress also enrolled in Anthropic’s OSS Scanner, which runs periodic scans with Anthropic’s models. Early results have already contributed to fixes; Anthropic has been credited in multiple recent security releases, including 7.1.4. The scanner and the team’s own tooling are complementary: one provides an independent source of findings, while the other focuses on WordPress-specific surfaces and integrates into existing workflows.
The 7.1.4 release on 28 October 2026 patched 22 vulnerabilities, including an upgrade-window race condition. Team members, not the new hunting tooling, found the majority of those issues. Four security releases shipped in 41 days between mid-September and late October. Seventy-three percent of the 109 steps in a security release now have some automation. Backports that once ran by hand across up to 25 branches are being scripted.
What this means for site owners
More eyes and more frequent security releases are the practical outcome. Sites that stay current receive fixes faster. The team has also said it wants to pay higher bounties for critical and high-impact findings from external researchers rather than reduce them.
- Confirm automatic background updates are enabled for core.
- Verify you are on the latest branch release, 7.1.4 or the equivalent for your branch.
- Review plugin and theme update status on the same cadence.
- Use controlled agentic access—scoped keys, dry runs, and snapshots—if you manage multiple sites or automate routine checks.
The shift does not remove the need for human judgment or responsible disclosure. It shortens the window between discovery and fix by adding an internal discovery path that still routes through the same release process.
Sites that treat updates as a routine automation rather than a manual event absorb these changes with less friction. The operational recommendation is unchanged: stay current, keep scopes tight, and keep a human in the loop on anything that can change production.
