⚠️ Attention! New updates marked with green color and warning sign will come into force from 2024 August 1 (00:00 UTC).
1. Introduction
1.1. Patchstack operates an open bug bounty program with a specific focus on the WordPress ecosystem, as detailed on our website: https://patchstack.com/bug-bounty/.
1.2. We adhere to the UTC format for all program-related activities.
1.3. Patchstack retains the discretion to modify these rules at any time without prior notification.
1.4. Any valid vulnerabilities disclosed through the Patchstack bug bounty program will be allocated a CVE ID and subsequently published, provided there are no conflicts with existing CVE IDs.
1.5. CVE IDs are managed according to CVE program rules. Learn more about the rules here: https://www.cve.org/ResourcesSupport/AllResources/CNARules
2. Reporting protocol
2.1. Accessibility
2.1.1. Participation in the Patchstack Bug Bounty program is open to all, provided individuals adhere to the outlined rules.
2.1.2. Vulnerability reports must be submitted exclusively through the designated web form available at https://patchstack.com/database/report. Submissions via email or any alternative means will not be accepted.
2.2. Scope
2.2.1. The Patchstack Bug Bounty program exclusively accepts vulnerability reports about components within the WordPress ecosystem, including WordPress core, plugins, and themes.
2.2.2. Both free and premium WordPress plugins and themes are eligible for submission. For vulnerabilities detected in premium components, submission of the original, unaltered premium component archive is mandatory for validation purposes.
2.2.3. We will accept vulnerabilities that require an attacker to have admin or higher user roles (similar custom roles). However, these will be used only to report them to the vulnerable software vendor and disclose them in the Patchstack Vulnerability Database. CVE ID will be assigned, but, no XP points for the monthly Patchstack bug bounty competition or custom event will be calculated.
2.2.4. We are not accepting CSV injection vulnerabilities as they require a lot of steps to be made outside the vulnerable application and server that hosts it. From the perspective of WordPress, it’s impossible to evaluate the success and severity of the attack.
2.2.5. We do not accept IP spoofing as a vulnerability if it does not directly impact a feature that relies on it, such as IP blocking.
2.2.6. We are not accepting the “Race Condition” vulnerabilities with CVSS (3.1) Base Score lower than 7.0.
2.2.7. Auth. (Contributor+) Shortcode Preview is out of scope, and such reports are no longer accepted unless sensitive or security-related information is disclosed, like PII (valid and measurable security impact). Patchstack keeps the right to reject selected reports from this category. The ability to preview/execute a shortcode usually exposes no sensitive information, in the case it does, you can still report it. Note that this is not related to Cross-Site Scripting (XSS) and we still accept those.
2.2.8. Reports for CSRF or Broken Access Control vulnerabilities leading to the Dismissal of Notice are no longer eligible to receive AXP unless the Dismissal of Notice has a valid and measurable impact. Patchstack keeps the right to reject selected reports from this category.
2.2.9 We will accept vulnerabilities for components with less than 1000 active installs. However, these will be used only to report them to the vulnerable software vendor and disclose them in the Patchstack Vulnerability Database. Note that these vulnerabilities, if valid, will get the CVE IDs, but no XP points for the monthly Patchstack bug bounty competition will be calculated.
* (This does not apply to vulnerability reports submitted via the Patchstack mVDP program for vulnerabilities that are being reported on behalf of another bug bounty program.)
2.2.10. We only accept reports for components (plugins/themes) with the last update no older than three years. The usual rules apply if a component has 10K or more active installs. Also, we will make exceptions for high-security impact vulnerabilities like – unauth. site takeover and similar. We reserve the right to decide whether to accept or reject reports of this kind.
2.3. Uniqueness requirement
2.3.1. All vulnerability submissions must be novel and unique, not previously reported or published elsewhere. Exceptions apply when reporting directly to the vendor before Patchstack submission or through the Patchstack mVDP program (learn more here: https://patchstack.com/for-plugins/) on behalf of another bug bounty program. *(This does not apply to vulnerability reports submitted via the Patchstack mVDP program for vulnerabilities reported on behalf of another bug bounty program.)
2.4. Quality assurance
2.4.1. Researchers are expected to ensure the completeness and accuracy of their vulnerability reports. Incomplete submissions will be rejected, with two opportunities provided for rectification.
2.4.2. Repeated rejection of submissions (three times per month) will result in a temporary suspension from submitting reports for the current and subsequent month.
⚠️ 2.4.3. (New) We will not accept report in the form of URL, you need to provide PDF or TXT file with all information like PoC. We can’t control integrity of report if it is stored on 3rd party storage/website.
2.4. Rejection criteria
2.4.1. Reasons for rejection may include incomplete or invalid reports, inaccuracies in vulnerability details, reports originating from non-standard user roles, or roles with modified permissions. *(In case of reports submitted via the Patchstack mVDP program for vulnerabilities that are being reported on behalf of another bug bounty program, the details of the original researcher can be set to “undisclosed”.)
2.4.2. Reports for closed plugins or themes will not be accepted, and components must be fully accessible on the repository at the time of reporting, excluding submissions through the Patchstack mVDP program. * (This does not apply to vulnerability reports submitted via the Patchstack mVDP program for vulnerabilities that are being reported on behalf of another bug bounty program.)
2.4.3. We reserve the right to reject vulnerability reports if the vulnerable component is not in WordPress, Envato, GitHub, or other well-known repositories and is distributed from a private vendor repository.
2.4.4. We will not accept reports made by reported component vendors/developers/authors.
2.5. Vendor engagement
2.5.1. Patchstack will endeavor to utilize the most expedient means provided by vendors for vulnerability disclosure. In the absence of direct contact options, reports will be redirected to the hosting repository.
2.5.2. Creation of accounts on vendor-provided platforms or disclosure of vulnerability data to third parties, even if authorized by the vendor, is prohibited.
2.6. CVE assignment
2.6.1. CVE IDs will be assigned upon confirmation of the absence of potential collisions and subsequent disclosure within the Patchstack Vulnerability Database.
2.6.2. If we receive vulnerability reports for the same vulnerability from different members, we will assign them to the member who submitted the valid report first.
2.6.3. You retain the option to report vulnerabilities previously disclosed to other programs by selecting the corresponding checkbox during the reporting process. In such cases, we will include the vulnerability in our database without assigning a CVE.
2.7. Research points (XP)
2.7.1. XP, or research points, are awarded for valid vulnerabilities reported to the Patchstack Bug Bounty program. These points are instrumental in determining the winners of each Patchstack-organized event. The calculation of competition points involves several parameters:
2.7.2. CVSS (version 3.1) base score: This score, calculated using the CVSS 3.1 calculator, serves as a foundation for assessing the severity of vulnerabilities. (You can try CVSS 3.1 calculator here – https://www.first.org/cvss/calculator/3.1)
2.7.3. Count of active installs: For premium products, this count is equivalent to sales. Rather than using precise numbers, we categorize installations into ranges, with each range assigned a multiplier that influences the overall points calculation.
The ranges are as follows:
| Multiplier | Installs |
| x1 | 1000 to 25K active installs |
| x2 | 25K active installs |
| x3 | 50K active installs |
| x4 | 100K active installs |
| x5 | 200K active installs |
| x6 | 400K active installs |
| x7 | 800K active installs |
| x8 | 1.6 million active installs |
| x9 | 3.2 million active installs |
| x10 | 5 million active installs |
| x20 | WordPress core |
2.7.4. Coefficients based on privilege requirements: These coefficients are applied based on the level of privilege required to exploit the vulnerability.
They are as follows:
| Coefficients | Level of privilege |
| x0 | Admin, SuperAdmin |
| x0.25 | Shop Manager (WooCommerce) |
| x0.5 | Author and Editor |
| x0.75 | Contributor |
| x1 | Subscriber and Customer (WooCommerce) |
| x2 | Unauthenticated |
2.7.5. Coefficients based on vulnerability type: These coefficients vary depending on the type of vulnerability reported.
They are as follows:
| Coefficients | Vulnerability type |
| x3 | Remote Code Execution (RCE), Arbitrary file upload, Local File Inclusion (LFI), Privilege escalation to Admin users |
| x2 | SQL Injection (SQLi), PHP Object Injection, Insecure Deserialization |
| x1.5 | Arbitrary file download/deletion, Privilege escalation to Non-Admin users |
| x0.25 | Cross-Site Request Forgery (CSRF) |
| x0.2 | Race Condition |
2.7.6. CSRF vulnerability that leads to an additional vulnerability listed in section 2.7.5 above, should now also get the additional vulnerability multiplier, however, the CSRF multiplier will still be applied. CSRF case example: CSRF to Remote Code Execution, CSRF to Arbitrary File Deletion, etc.
2.7.7. In cases where determining the number of active installations or sales is impossible, we utilize available means such as Google or PublicWWW (https://publicwww.com/).
2.7.8. XP points are tallied monthly, beginning from the first day of the month to the last (in the UTC zone), or within the specified time range for monthly events. The ongoing results are displayed on the monthly scoreboard at https://patchstack.com/database/leaderboard . It’s important to note that final results are only available once all reports are validated and announced on the Patchstack Alliance (learn more here: https://patchstack.com/bug-bounty/)
Discord server or other official Patchstack channels.
2.7.8. Additionally, members can earn extra points (1.5x) for providing highly detailed advisories on vulnerabilities with a CVSS 3.1 base score of 7.5 or higher. However, it’s necessary to inform Patchstack before creating such detailed advisories to discuss the specifics.
3. Disclosure
3.1. Transparency policy
3.1.1. All vulnerabilities submitted to the Patchstack Bug Bounty program will be publicly disclosed via the Patchstack Vulnerability Database following established vulnerability disclosure policy.
3.1.2. Ethical disclosure practices are upheld, with vulnerability disclosure pending until the vendor releases a patched version and significant user adoption occurs, mitigating potential adverse impacts.
You can read more in Patchstack Vulnerability Disclosure Policy: https://patchstack.com/patchstack-vulnerability-disclosure-policy/
3.1.3. Researchers must refrain from disclosing vulnerability information to third parties before its official disclosure within the Patchstack Vulnerability Database.
3.2. Escalation protocol
3.2.1. In the event of vendor inaction or disregard for reported vulnerabilities over 14 days, Patchstack reserves the right to proceed with disclosure, potentially involving the WordPress Security Team.
3.2.2. The disclosure timeline may be extended unilaterally by Patchstack for components within the Patchstack mVDP program. It may be extended or disclosure can be made immediately if we see active exploitation attempts, disclosure made by third parties, or a component is removed from the repository.
3.3. Attribution
3.3.1. Vulnerabilities will be disclosed with attribution to the researcher, utilizing the provided name or nickname along with a link to their social media account. Additionally, “(Patchstack Alliance)” will be appended for public acknowledgment.
3.3.2. CVE IDs will be published in the global CVE database following disclosure within the Patchstack Vulnerability Database.
4. Events
4.1. Participation
4.1.1. The Patchstack Bug Bounty program hosts monthly competitions and custom events throughout the year, open to all individuals who submit legitimate and unique vulnerabilities in adherence to program rules.
4.2. Monthly competition
4.2.1. Monthly competitions commence on the first day of each month and conclude on the last day, with results announced on the Patchstack Alliance Discord server (the first day of the month at 00:00 (UTC) and end at midnight on the last day of the month).
4.2.2. A guaranteed monthly bounty pool is allocated based on final leaderboard standings, with prizes distributed accordingly.
4.2.3. You can see the preliminary results of the current month at https://patchstack.com/database/leaderboard. Also, you can see the historical data by selecting the year and month from the dropdown list.
⚠️ 4.2.4. (Update) Patchstack offers a monthly guaranteed bounty pool of $8,800. Each month, the total prize pool will be paid out based on the results from the final leaderboard.
⚠️ 4.2.5. (Update) The monthly bounty pool:
| Scoreboard | Bounty |
| 1st place | $2,000.00 |
| 2nd place | $1,400.00 |
| 3rd place | $800.00 |
| 4th place | $600.00 |
| 5th place | $500.00 |
| 6th place | $400.00 |
| 7th place | $400.00 |
| 8th place | $400.00 |
| 9th place | $400.00 |
| 10th place | $400.00 |
| 11th place | $200.00 |
| 12th place | $200.00 |
| 13th place | $200.00 |
| 14th place | $200.00 |
| 15th place | $200.00 |
| ⚠️ 16th place | $100.00 |
| ⚠️ 17th place | $100.00 |
| ⚠️ 18th place | $100.00 |
| ⚠️ 19th place | $100.00 |
| ⚠️ 20th place | $50.00 |
| Random | $50.00 |
⚠️ 4.2.6. (New) bounties will be paid only if researcher has more than 0 AXP on the particular month. 0 AXP means $0 even if on a scoreboard researcher stands on the place that allows to get particular bounty. Same applies to the “Random” bounty.
4.3. Ranking rewards
4.3.1. Members receive passive rewards for accumulating XP and leveling up. The XP is counted from bug-hunting competitions, custom events, and the Patchstack Zeroday bounties.
4.3.2. Starting from Level 2, researchers will unlock rewards (these will get paid out together with the monthly bounties):
| Rank | Reward |
| Level 2 | $200 |
| Level 3 | $300 |
| Level 4 | $400 |
| Level 5 | $500 + Mystery Box |
| Level 6 | $600 |
| Level 7 | $700 |
| Level 8 | $800 |
| Level 9 | $900 |
| Level 10 | $1337 + Mystery Box |
4.4. Custom events
4.4.1. Custom events are announced periodically on the Patchstack Alliance Discord server, adhering to standard program rules unless specified otherwise.
5. Zeroday bounties
⚠️ 5.1. (Update) Patchstack offers rewards for high-impact vulnerabilities on a case-by-case basis, subject to specific criteria and requirements. These rewards will get paid out together with the monthly bounties.
| Active installs | Unauthenticated | Subscriber/Customer |
| ⚠️ 5000+ | $150.00 | $75.00 |
| 10,000+ | $450.00 | $225.00 |
| 50,000+ | $900.00 | $450.00 |
| 100,000+ | $1,800.00 | $900.00 |
| 500,000+ | $3,600.00 | $1,800.00 |
| 1,000,000+ | $7,200.00 | $3,600.00 |
| 5,000,000+ | $14,400.00 | $7,200.00 |
5.2. Requirements for the Patchstack Zeroday bounties
5.2.1. It applies to all free and premium WordPress plugins, themes, and cores if it meet other program requirements except components hosted on non-public private repositories.
5.2.2. Vulnerability leads to a full site compromise (ability to upload & access a functional backdoor).
5.2.3. Exploitable with Unauthenticated (none), or non-higher than Subscriber/Customer (WooCommerce) user roles.
5.2.4. The report includes a working exploit.
5.2.5. No prerequisites (default settings / most common environment / does not need any other vulnerability to be present).
5.2.6. Exploitation does not require a user interaction.
⚠️ 5.2.7. (New) Vulnerability is not reported elsewhere, vulnerability is not known by vendor from any previous reports, vulnerability is not publicly disclosed.
5. Processing
5.1. CVE assignment
5.1.1. CVE IDs are assigned promptly upon verification of vulnerability submissions, ensuring no potential collisions exist.
6. Communication
6.1. Information dissemination
6.1.1. Official announcements and program updates are disseminated via the Patchstack Alliance Discord server and official Patchstack social media channels at https://discord.gg/rkE8yxtNmS
6.1.2. Additional assistance can be requested via email or support ticket on the Patchstack Alliance Discord server and some announcements will be published on official Patchstack pages at:
Twitter(X) https://twitter.com/patchstackapp
Facebook https://www.facebook.com/patchstackapp
LinkedIn https://www.linkedin.com/company/patchtsack/
6.1.3. If you need additional information, you can ask for help via email at darius.sveikauskas@patchstack.com or create a support ticket on the Patchstack Alliance Discord – https://discord.gg/rkE8yxtNmS.
7. Benefits of Participation
7.1. Opportunities
7.1.1. Participation offers the chance to earn rewards for discovering vulnerabilities, gain exposure through publicity, and contribute to enhancing the WordPress ecosystem’s security.
7.1.2. Researchers receive CVE IDs for validated reports and have the opportunity to share and acquire knowledge within the Patchstack community.
7.2. Membership
7.2.1. Membership in the Patchstack Alliance is open to individuals committed to improving WordPress security and fulfilling program requirements.
7.2.2. Access to the Discord member-only section is granted.
7.3. Payouts
7.3.1. We pay bounties via the PayPal payment platform.
7.3.2. Each researcher must take care of the administration of their PayPal account and the possibility of transferring money to the specified account.
7.3.3.Each researcher is responsible for the tax obligations for payouts received through the Patchstack bug bounty program.
7.3.4. If your PayPal account is blocked, investigated, or frozen due to sanctions, Patchstack will attempt to transfer the money within a month, and after one month, the bounty will be dropped back to the bounty pool.
7.3.5. Patchstack is paying bounties by invoices. We don’t make payments without invoices. PayPal invoice money requests should include the following data:
Full name; Country; Address; It should be addressed to – Patchstack OÜ;
Payment purpose – “Security research (+ your name or nickname that you use on the bug bounty program)”.
7.3.6. Additional details are always provided via email.
7.3.7. Payments are made 30 days after the final results are announced.
7.3.8. For additional help with payments, invoices, and Paypal check here: https://www.notion.so/patchstack/Patchstack-Alliance-payments-b6d63c55099e4f65b842bc5ce60de2d7
