Details

WordPress is an open-source publishing platform. Our HackerOne program covers the Core software, as well as a variety of related projects and infrastructure.

Our most critical targets are:

WordPress Core software, API, and website.
Gutenberg software and Classic Editor software.
WP-CLI software and website.
BuddyPress software and website.
bbPress software and website.
GlotPress software (but not the website).
WordCamp.org website.

Source code for most websites can be found in our GitHub account, or in the Meta repository (git clone git://meta.git.wordpress.org/). Many of the sites have Docker environments that will automatically provision a local copy for you to test against.

For more targets, see the In Scope section below.

All bounties are doubled if they're reported before the bug is released to users.

Please note that WordPress.com is a separate entity from the main WordPress open source project. Please report vulnerabilities for WordPress.com or the WordPress mobile apps through Automattic's HackerOne page.

Qualifying Vulnerabilities

Any reproducible vulnerability that has a severe effect on the security or privacy of our users is likely to be in scope for the program. Common examples include XSS, CSRF, SSRF, RCE, SQLi, and privilege escalation.

We generally aren’t interested in the following problems:

Any vulnerability with a CVSS 3 score lower than 4.0, unless it can be combined with other vulnerabilities to achieve a higher score.
Brute force, DoS, phishing, text injection, or social engineering attacks. Wikis, Tracs, forums, etc are intended to allow users to edit them.
Availability of XML-RPC file without PoC demonstrating a significant security impact. As noted above, this excludes DDoS and brute force attacks.
Security vulnerabilities in WordPress plugins not specifically listed as an in-scope asset. Out of scope plugins can be reported to the Plugin Review team.
Reports for hacked websites. The site owner can learn more about restoring their site.
Users with administrator or editor privileges can post arbitrary JavaScript
Self-XSS issues within wp-admin requiring users with unfiltered_html capability are not under the scope of this program. For example, script execution within /wp-admin as an administrator or editor on a single-site installation. Only the cases where a less-privileged user is able to execute XSS attacks on a higher-privileged user will be under the bug bounty scope.
Disclosure of user IDs
Open API endpoints serving public data (Including usernames and user IDs)
Path disclosures for errors, warnings, or notices
WordPress version number disclosure
Mixed content warnings for passive assets like images and videos
Lack of HTTP security headers (CSP, X-XSS, etc.)
Output from automated scans - please manually verify issues and include a valid proof of concept.
Any non-severe vulnerability on irclogs.wordpress.org, lists.wordpress.org, or any other low impact site.
Clickjacking with minimal security implications
Vulnerabilities in Composer/NPM devDependencies, unless there's a practical way to exploit it remotely.
Theoretical vulnerabilities where you can't demonstrate a significant security impact with a PoC.
Broken Links to external resources / social media accounts in documentation, profiles, or WordCamp sites, unless a significant security impact can be shown. Broken links in documentation should be reported to https://meta.trac.wordpress.org/.

Guidelines

We're committed to working with security researchers to resolve the vulnerabilities they discover. You can help us by following these guidelines:

Follow HackerOne's disclosure guidelines.
Pen-testing Production:
- Please setup a local environment instead whenever possible. Most of our code is open source (see above).
- If that's not possible, limit any data access/modification to the bare minimum necessary to reproduce a PoC.
- Don't automate form submissions! That's very annoying for us, because it adds extra work for the volunteers who manage those systems, and reduces the signal/noise ratio in our communication channels.
If you don't follow these guidelines we will not award a bounty for the report.
Be Patient - Give us a reasonable time to correct the issue before you disclose the vulnerability. We care deeply about security, but we're an open-source project and our team is mostly comprised of volunteers. WordPress powers 40% of the Web, so changes must undergo multiple levels of peer-review and testing, to make sure that they don't break millions of websites when they're installed automatically.

We also expect you to comply with all applicable laws. You're responsible to pay any taxes associated with your bounties.

Qualifying Vulnerabilities

We generally aren’t interested in the following problems:

Any vulnerability with a CVSS 3 score lower than 4.0, unless it can be combined with other vulnerabilities to achieve a higher score.

Brute force, DoS, phishing, text injection, or social engineering attacks. Wikis, Tracs, forums, etc are intended to allow users to edit them.

Availability of XML-RPC file without PoC demonstrating a significant security impact. As noted above, this excludes DDoS and brute force attacks.

Security vulnerabilities in WordPress plugins not specifically listed as an in-scope asset. Out of scope plugins can be reported to the Plugin Review team.

Reports for hacked websites. The site owner can learn more about restoring their site.

Users with administrator or editor privileges can post arbitrary JavaScript

Self-XSS issues within wp-admin requiring users with unfiltered_html capability are not under the scope of this program. For example, script execution within /wp-admin as an administrator or editor on a single-site installation. Only the cases where a less-privileged user is able to execute XSS attacks on a higher-privileged user will be under the bug bounty scope.

Disclosure of user IDs

Open API endpoints serving public data (Including usernames and user IDs)

Path disclosures for errors, warnings, or notices

WordPress version number disclosure

Mixed content warnings for passive assets like images and videos

Lack of HTTP security headers (CSP, X-XSS, etc.)

Output from automated scans - please manually verify issues and include a valid proof of concept.

Any non-severe vulnerability on irclogs.wordpress.org, lists.wordpress.org, or any other low impact site.

Clickjacking with minimal security implications

Vulnerabilities in Composer/NPM devDependencies, unless there's a practical way to exploit it remotely.

Theoretical vulnerabilities where you can't demonstrate a significant security impact with a PoC.

Broken Links to external resources / social media accounts in documentation, profiles, or WordCamp sites, unless a significant security impact can be shown. Broken links in documentation should be reported to https://meta.trac.wordpress.org/.

Guidelines

We're committed to working with security researchers to resolve the vulnerabilities they discover. You can help us by following these guidelines:

Follow HackerOne's disclosure guidelines.

Pen-testing Production:

Please setup a local environment instead whenever possible. Most of our code is open source (see above).
If that's not possible, limit any data access/modification to the bare minimum necessary to reproduce a PoC.
Don't automate form submissions! That's very annoying for us, because it adds extra work for the volunteers who manage those systems, and reduces the signal/noise ratio in our communication channels.

If you don't follow these guidelines we will not award a bounty for the report.

Be Patient - Give us a reasonable time to correct the issue before you disclose the vulnerability. We care deeply about security, but we're an open-source project and our team is mostly comprised of volunteers. WordPress powers 40% of the Web, so changes must undergo multiple levels of peer-review and testing, to make sure that they don't break millions of websites when they're installed automatically.

We also expect you to comply with all applicable laws. You're responsible to pay any taxes associated with your bounties.