WordPress Core Security Initiative Narrows Bug Bounty

The WordPress Core Security Initiative launched on August 28. Three days later, the security team narrowed its bug bounty.

The WordPress security team announced the Core Security Initiative on August 28. Security reports have climbed sharply over the past year, and the team credits frontier AI models for most of that rise. Those models have made it far easier to read code and spot WordPress vulnerabilities.

Three days later, on September 1, the team changed the rules of its bug bounty.

A whole category of reports no longer qualifies.

Methodology: This piece draws on two posts published by the WordPress security team. For supplementary research, we checked Help Net Security’s May 2026 report. It is based on an automated vulnerability pipeline built by researchers at TrendAI and CHT Security. The explanation of why certain report types were dropped is our own reading, not a rationale WordPress stated. 

What WordPress announced on August 28

Rudy Faile wrote the announcement. He says more eyes on WordPress make it safer, but that the project now has to scale how it handles what arrives. On the cause he is direct:

It has never been easier to analyze code for potential vulnerabilities, and reporting volume across the whole WordPress ecosystem has risen accordingly.

He adds that the topic came up days earlier at the security team meeting during WordCamp US. The initiative has one goal, a stronger and safer WordPress and three pillars.

• The first pillar is a better release process. The team wants tighter automation and better end-to-end testing. The idea is to ship fixes on time and without surprises. It has already started scheduling security releases.
• The second pillar is breaking the backlog. More team members and volunteers will work through the open reports and known issues. The team wants that queue at zero.
• The third pillar puts AI to work on defense. The team will scan code with AI tooling to find WordPress vulnerabilities before attackers do.

Faile called the rise in reports a good problem to have, and asked researchers to read the reporting guidelines before submitting anything. Three days later, the team showed what that request meant in practice.

What changed on September 1

Contributor Ehtisham Siddiqui wrote the follow-up. It updates who gets credit on the project’s HackerOne program.

The change applies to in-scope assets outside WordPress core and Gutenberg. If a bug only works when an administrator has already granted you a role, it usually will not qualify anymore. The post names Contributor as an example. The exception is a bug that escalates into something that is highly severe.

The team also dropped most role-overlap reports. Showing that one logged-in role can do something another role can do is no longer enough on its own.

Instead, the team asks researchers to focus on bugs that a stranger can actually reach. That means high-severity flaws needing no login or needing nothing more than a Subscriber account. Core and Gutenberg keep the old rules for now.

In short, the program now wants fewer reports and better ones, and the reason for that sits outside WordPress.

Why did the WordPress Core Security initiative narrow its scope?

AI has changed what one person can produce in an afternoon. Writing, code, analysis, research summaries: All of it now arrives faster than anyone can read it. Every field dealing in volume is learning the same lesson. More output is not the same as more value. Somebody still has to sort one from the other.

Security research works exactly this way, except the stakes are higher and the sorting is slower. Here is how that played out for WordPress Core Security.

1. Finding flaws got cheap

Help Net Security reported in May on a system built by researchers at TrendAI and CHT Security. It reads plugin code automatically, then tests whatever looks weak. Pointed at WordPress plugins, it found more than 300 serious flaws nobody had reported before and it did so in 72 hours. Steven Yu of TrendAI put the cost at about twenty dollars each.

Those findings went to plugin authors, not to WordPress. But the method works on anything, for anyone.

2. The problem is what the volume contains

Automated scanning is good at surfacing issues that are technically real and practically minor. A person still has to read each one to tell the difference.

3. Why these two types got cut

Every WordPress site gives people permission levels. Subscriber sits at the bottom, and many sites hand one to anybody who signs up. Contributor sits higher, and an administrator has to grant it on purpose.

A bug that needs a Contributor account is a bug an outsider cannot reach. Role-overlap bugs, where one role does a job meant for another, point to untidy permissions rather than a broken lock.

So the program now accepts flaws that an outsider could actually exploit, and turns away the rest. That changes what is worth sending in.

How to report a WordPress vulnerability

The project still wants your reports. It wants a narrower set of them.

If you believe you have found a vulnerability in WordPress core, report it through the official channel at hackerone.com/wordpress. Read the reporting guidelines before you submit. At this volume, a clear and well-scoped report counts for more than it used to.