🎉 Welcome to the Wordfence Intelligence Bug Bounty Program 🎉

In Scope Assets

🚨 High Threat Vulnerabilities 🚨

All Other Vulnerabilities

For other vulnerabilities, all WordPress plugins and themes, free and premium (excluding those listed in Out of Scope Assets) are in scope with active installation thresholds that vary with your Researcher tier:

If in doubt on what's in scope for your tier, use our bounty estimator to check if your discovery is in scope, or out of scope.

Out of Scope Assets

There are some assets explicitly out of scope of our bug bounty program which are listed below:

Additionally, Plugins or Themes Closed to Downloads or Sales at the time of submission, or any web service associated with a WordPress plugin or theme that is not run locally (such as an API running on a plugin vendor’s website) is considered out of scope.

We may still assign CVEs to any vulnerabilities discovered in the products outlined above, however, they will not be eligible for a bounty through our bug bounty program.

We may still assign CVEs to any vulnerabilities discovered in the out of scope list above, however, they will not be eligible for a bounty through our bug bounty program.

Program Rules Key Highlights & Important Things to Know

• You must be a registered researcher on the Wordfence website, and be authenticated at the time of submission, in order to submit a vulnerability for the Bug Bounty Program.
• Vulnerabilities that require more than one CVE assignment may only earn a single bounty for the higher awarding CVE (i.e. Cross-Site Request Forgery and Missing Authorization in a single function)
• Researchers can be banned or throttled from the program if they are continuously submitting low-quality or spammy false positive reports, or appear to be gaming the rules of the program in a harmful fashion.
• Developers cannot report vulnerabilities in their own software for bounties, though they can submit issues for CVE ID assignments.
• Wordfence must handle the responsible disclosure process for any reported vulnerabilities, and you must keep the information confidential until we publicly disclose the issue in our database. This means Wordfence must be the only organization you submit the vulnerability to.
• The first researcher to submit a vulnerability with a valid and working proof of concept will be the only one to receive a bounty in the event of a duplicate report.
• Bounty payments are processed in bulk on the 1st and 15th of every month.
• In-Scope submissions are typically triaged within 5-7 business days, with critical issues typically having a much faster turnaround. Out-of-Scope submissions are triaged as time allows.
• Remember that when you participate in our Bug Bounty program, you are giving back to the security of the WordPress ecosystem. All of the vulnerabilities submitted to us are added to the Wordfence Intelligence vulnerability database which is given back to the community through webhook and API access completely for free. All other WordPress-centric vulnerability databases charge for this level of access.

Pending In-Scope Report Limits

All researchers have a limit to the number of vulnerabilities that can be actively submitted and pending triage at one time for participation in the Bug Bounty Program. The following outlines these pending report limits:

Out-of-scope submissions adequately marked as such upon submission do not count against this limit so you can still request CVEs for anything that would not constitute a bounty under our program.

This allows us to control the flow of submissions to ensure we can sustain reasonable triage times for all of our researchers and everyone has a fair chance at submitting qualifying vulnerabilities.

When do in-scope reports roll over?

As soon as you get the message that a submitted vulnerability is validated, or it has been rejected, that means you have one more open slot to submit a vulnerability. Pro-tip: You will know if you are at your pending report limit by accessing the vulnerability submission form. If you get a notice that you are at your limit then you can not submit any more vulnerabilities for participation in the Bug Bounty Program. If you do not get a notice, then you are all clear to submit another bounty-eligible report.

For a more detailed overview, please read our terms and conditions.

There are various researcher tiers that control what your scope is and how many pending vulnerability submission reports you can have at any given time.

What are critical or high severity vulnerabilities in our eyes?

The following outlines some examples of critical and high severity qualifying vulnerabilities. Please note that these all assume there are no prerequisites to exploit (i.e. settings or user interaction). In order for a vulnerability to qualify, the plugin or theme should have >=50,000 active installations.

Our goal with the Wordfence Bug Bounty Program is to get the most impactful and harder to find vulnerabilities remediated before threat actors can find and exploit them as an 0-day. This means we award the highest bounty rewards for things like authentication bypasses, privilege escalation, arbitrary file uploads, and arbitrary options updates while easier to find vulnerabilities like Cross-Site Scripting, or less likely to be exploited vulnerabilities, like vulnerabilities that require contributor-level access or user interaction to exploit, are awarded far less. We hope this encourages researchers to spend more time focusing on harder to find critical issues that greatly increase the overall security of the WordPress ecosystem.

All bounty rewards are based on how many active installations the vulnerable piece of software has, the type of vulnerability being reported, the authentication requirements to exploit the vulnerability, the impact of the vulnerability, and what, if any, prerequisites to exploit.

Use our bounty estimator to get an idea of what bounties you may be awarded for different vulnerability types:

Please note that the bounty estimator provides an estimated reward amount only and is subject to change at any time. Any estimate provided by the bounty estimator is not a guarantee of a specific reward amount. Many factors can impact the bounties we award such as:

• Prerequisites to exploit, such as software settings or specific server configuration
• Ease and replicability of exploitation (i.e. if the vulnerability can be automatically exploited across various environments)
• Active user interaction, or unlikely passive user interaction, as a requirement to exploit
• The impact the vulnerabilities has on the site as a whole (i.e. to what extent does the vulnerability impact the CIA of the site).
• Dependency on another vulnerability not present in the same vulnerable piece of software. Typically the payout is divided by at least half.

Other important things to consider with the bounties we typically award:

• PHP Object Injection will be awarded at the highest level of impact if a usable gadget is present in the software, or in the current version of WordPress Core, and exploitation of it is demonstrated in the submitted report. Otherwise, PHP Object Injection is awarded at a lower rate to account for the fact that no usable gadget means no real impact.
• The ‘Basic Information Disclosure’ type is often used when information is exposed to unauthorized users, but the information is not incredibly sensitive (i.e. email disclosure, log file exposure, phpinfo access, etc.)

Bounty Bonuses

In addition to our bounties, we offer bonuses for exceptional, well documented, and unique researchers. Please find all of the additional bonuses we may award listed below:

The Achievement Badges for the Wordfence Bug Bounty Program are designed to recognize the contributions and skills of participants in enhancing the security of the WordPress open-source community. Through a system of badges named "Achievements," individuals are rewarded for their expertise, perseverance, and collaborative efforts in making the WordPress environment safer. These badges signify not only personal growth and discovery but also professional development, as they are displayed on the researcher's profile, enhancing their reputation and providing clear milestones in their bug-hunting career.

This initiative encourages both seasoned and novice security researchers to engage actively, pursue continual improvement, and gain acknowledgment within the open-source ecosystem, with the promise of expanding the badge offerings in the future to further incentivize and track progress in contributing to a more secure open-source community.