Historically, Patchstack has aimed to keep its bug bounty program focused on vulnerabilities with a clear and meaningful security impact. The goal has always been to reward research that helps protect the wider WordPress ecosystem, while keeping the program practical to triage and maintain.
This approach continued after Patchstack became a CNA. In many cases, we received well-written, high-severity reports with clear impact, reproducible proof-of-concepts, and enough technical detail to process them efficiently. The overall submission volume was also manageable, which allowed us to keep quality high while continuing to publish and coordinate vulnerabilities responsibly.
Over time, however, the type and volume of reports submitted to the program has changed significantly. We are now seeing a growing number of reports that technically try to fit within the rules, but do not always reflect the level of real-world security impact the program was originally designed to prioritize. This has made it harder to keep the bounty scope clear, consistent, and sustainable.
There’s no doubt AI has changed the space a lot. Beloved CTFs have lost most of the fun in them and many bug bounty programs have either been put to pause or have been restructured in an attempt to find a better fit in this new world. At Patchstack, we’re adapting in real-time and work hard to find the format that makes sense for the future.
What changed with AI
Since the rise of AI-assisted security research, especially throughout 2026, we have seen a significant increase in lower-impact reports that only narrowly meet the criteria of the Patchstack bug bounty program.
Each time we refine the rules, researchers quickly adapt and submit findings that still technically qualify. Because of the nature of the CVSS scoring system and the flexibility of WordPress itself, it is difficult to define strict boundaries without eventually creating an extremely large list of specific edge cases and exclusions.
Alongside the increase in lower-impact submissions, we are also seeing far more duplicate reports than in previous years. For some vulnerabilities, we have received more than 20 duplicate submissions from different researchers. This demonstrates how quickly AI tools can identify and reproduce certain vulnerability patterns at scale.
We also frequently encounter reports where the finding was not properly validated, or where incorrect AI-generated assumptions were not caught before submission. Examples include:
- A report claims an arbitrary file upload vulnerability, while the actual issue only allows uploading image files.
- A report claims a severe vulnerability in a WordPress AJAX endpoint, but it depends on a nonce that is never exposed to the frontend and incorrectly assumes a malicious user can arbitrarily generate it using
wp_create_nonce. - A report depends on unusual prerequisites that would not exist on a normal web server installation.
- A report requires knowledge of a secret value that cannot realistically be obtained remotely without first exploiting another vulnerability.
Of course, not all effects have been negative. AI has also improved the quality of many proof-of-concepts and report descriptions and discovering more vulnerabilities overall is ultimately beneficial for the ecosystem. However, the growing volume of submissions has created significant triage challenges, and this is something affecting many bug bounty programs, not just ours.
Statistics
The graph below shows the status outcome for submitted reports. These states are rejected, duplicate and valid.
This provides a clear visual representation of the types of reports we are currently receiving. Over the past few months, we have seen substantial spikes in duplicate submissions, alongside a significant increase in reports that do not meet the requirements of the Patchstack bug bounty program.
What happens next
To maintain the quality of the vulnerabilities we process, while also keeping triage manageable and consistent, we need to make further adjustments to the Patchstack bug bounty program rules.
These changes are significantly broader than previous updates, and we understand they will substantially affect the number and type of reports we receive and publish.
As of June 1, 2026, submitted reports must meet at least one of the following criteria.
1) Zero-day bounty requirements
Reports that meet the zero-day bounty requirements will continue to be accepted and remain eligible for bounty rewards. The requirements for a report to qualify as a zero-day can be found on this page under point 22.
2) Low user-roles requirement
The contributor user role is no longer part of the scope. This means that reports would have to involve roles such as guest, subscriber, customer and other similar custom roles. Custom roles that would have to be explicitly granted to a user by an admin are not in scope.
Essentially all high-severity vulnerabilities in the WordPress ecosystem that we have seen exploited involved no authentication or at most the subscriber/customer user role and this is what we want to focus on.
3) Specific vulnerability types (with conditions)
Reports are accepted if they fall into one of the following categories and meet the listed conditions.
- SQL injection
- Cross-Site Scripting (XSS)
- Must have an impact on the entire site, or be reflected
- Arbitrary file upload, deletion, or download
- Must provide full control over the path and extension
- Remote/Arbitrary Code Execution
- PHP Object Injection
- Arbitrary settings change
- Must involve WordPress options or settings with significant impact on the site
- Privilege escalation
- Must lead to contributor access or higher
- Local file inclusion or remote file inclusion
- Must provide full control over the path and extension
- Broken access control
- Must result in access to significant or sensitive objects, for example:
- API keys or secret values, including a demonstration of their impact
- password hashes
- backup files or SQL files
- Must result in access to significant or sensitive objects, for example:
- IDOR
- Must lead to significant security impact
- Examples that are not accepted:
- PII leakage alone, without broader security impact
- interactions with attachments, tickets, events, orders, or appointments
- CSRF
- Must result in one of the accepted write-related actions listed above
4) Patchstack mVDP software scope
Reports targeting software included in the Patchstack mVDP scope will continue to be accepted, including the contributor user role. They must have a measurable security impact.
Additional changes
We are also making some changes to the bounties and bounty pool:
- We no longer issue bounty rewards based on levels.
- We no longer issue bounty rewards to randomly selected researchers.
- The monthly bounty pool is now limited to the top 5.
- Reports affecting mVDP software will still be accepted if they demonstrate real security impact, although they may no longer receive XP.
Enforcement (temporary bans)
We still receive a large number of reports that clearly do not meet the Patchstack bug bounty program rules. To reduce repeated abuse of the system, researchers who submit the following types of reports will receive an immediate one-week ban:
- Reports containing incorrect AI-generated assumptions
- Reports that were clearly not tested against the actual plugin or theme
- Reports that clearly do not meet the Patchstack bug bounty program rules
Closing
We understand these changes will affect how researchers approach the Patchstack bug bounty program. Our goal is not to discourage security research, but to ensure the program remains sustainable, focused on meaningful security impact, and manageable for both researchers and our internal triage team.
