⚠️ Attention! New update, starting May 1, 2026.
1.1. Patchstack operates a public Bug Bounty Program focused primarily on vulnerabilities in the WordPress ecosystem components like plugins and themes. More information is available at: https://patchstack.com/bug-bounty/
1.2. The program includes monthly competitions and occasional custom events throughout the year. Participation is open to anyone who submits valid and unique vulnerabilities in accordance with these rules.
1.3. All program operations, timelines, and communications follow UTC (Coordinated Universal Time). Support is provided Mon-Fri (5AM – 4PM) via Patchstack Alliance Discord server #support channel tickets or via triage@patchstack.com email.
1.4. Patchstack reserves the right to change or update these rules at any time, without prior notice.
1.5. All valid, in-scope vulnerabilities submitted through the Patchstack Bug Bounty Program will be publicly disclosed in the Patchstack Vulnerability Database.
1.6. Patchstack is a CVE Numbering Authority (CNA). This means that each valid, in-scope vulnerability will receive a unique CVE ID and be published in the CVE database, provided no conflicts exist with previously issued CVEs.
1.7. CVE assignment follows official CVE Program rules, with the following exception – assignment may be delayed to prevent CVE conflicts between multiple CNAs operating in the same ecosystem (for example, WordPress).
1.8. By participating in the Patchstack Bug Bounty Program, researchers can earn bounties (bounties are paid based on monthly leaderboard position; only Zeroday program-applicable vulnerability reports are rewarded individually) by reporting valid, unique, and impactful security issues affecting in-scope components such as WordPress core, plugins, and themes.
1.9. By submitting a vulnerability to the Patchstack Bug Bounty Program, you agree to comply with all rules outlined in this document and any related documents.
2.1. All vulnerability reports must be submitted ONLY through the official reporting form –https://patchstack.com/database/report
2.2. Reports sent via email or any other channel will not be accepted.
2.3. A researcher account is created automatically after at least one valid, in-scope vulnerability is submitted. You can access your account any time via this link –https://vdp.patchstack.com/researchers/login using the email address you used for vulnerability reporting.
2.4. Each researcher may operate only one account. Creating or using multiple accounts may result in immediate suspension of all related accounts.
2.5. Participation is open to individuals and companies that follow and respect the program rules.
2.6. Reports must be submitted by individual researchers or organizations. Team submissions are not supported, as the monthly competition system does not allow team-based point calculations.
3.1. The Patchstack Bug Bounty Program accepts vulnerability reports for components in the WordPress ecosystem, including:
● WordPress core
● WordPress plugins (free/premium)
● WordPress themes (free/premium)
3.2. A vulnerability is considered valid only if it has a clear and measurable security impactand does not fall outside the accepted scope.
3.3. Both free and premium plugins and themes are accepted. For premium components, researchers must provide the original, unmodified archive file for validation. If a theme depends on specific plugins, those plugins must also be provided.
3.4. Vulnerabilities must have a CVSS base score of 6.5 or higher.
3.5. Reported components should have 1,000 or more active installs. A lower install count is out of scope unless the reported vulnerability has a CVSS base score of 8.5 or higher and the reported component has at least 100 active installs.
3.6. Only the latest versions are accepted in reports, and the last version should not be older than 3 years since the last update. The component must be publicly available through WordPress.org, the vendor’s official website, or another publicly accessible source such as GitHub, CodeCanyon, or ThemeForest. Custom-made, modified, or private components that are not publicly distributed are not accepted.
3.7. Only vulnerabilities that can be exploited by unauthenticated users or by users with default Subscriber or Customer roles are eligible. Reports requiring Contributor level access are accepted only if the CVSS base score is 7.5 or higher. Vulnerabilities requiring roles with higher privileges are out of scope.
3.8. Reports involving custom roles are accepted only if the role provided by the affected component has capabilities equivalent or closely aligned with those of the Subscriber or Customer roles. Reports involving roles with capabilities exceeding those of the default Subscriber or Customer roles are not accepted.
3.9. Out of scope (not accepted/rejection)
Configuration & expected functionality
● Vulnerabilities that only exist because a high-privilege user explicitly configured the component that way.
● Vulnerabilities where the plugin’s own Permissions UI lets administrators grant a capability to a lower-priv role (Author/Editor/Contributor/Subscriber), exposing the issue to that role.
● Expected functionality is not a vulnerability – e.g. a contact form that allows uploads does not qualify as DoS just because someone could submit large quantities of entries.
● Authenticated shortcode issues without sensitive data disclosure.
Scoring & identifier requirements
● Any report involving Attack Complexity: High (AC:H).
● Subscriber-or-higher vulns leading to minor/insignificant data leakage, minor data modification, or minor availability impact (CVSS 5.4 with two CIA at L, 6.3 with three at L).
● Unauthenticated vulns with only one CIA at Low impact (CVSS 5.3).
● Actions that require a non-guessable or unrealistic identifier to be impactful – e.g. cancelling a subscription that requires knowing a long, randomly-generated subscription hash.
● Re-ordering data, clearing cache, or manually triggering cronjobs / scheduled tasks.
Submission requirements
● Multiple findings of the same vulnerability type must be consolidated into a single report.
● Vendor or developer self-submissions – accepted for disclosure but not eligible for bounties.
● Incomplete, inaccurate, or unverifiable information, or invalid vulnerability claims.
● Unrealistic pre-requisites or exploitation scenarios.
● Closed, inaccessible, or non-publicly-distributed components, or reports based on non-standard user roles.
● CSV injection vulnerabilities, as they depend on external actions outside WordPress and cannot be reliably evaluated.
● CAPTCHA bypasses and IP spoofing, unless these are the main plugin functions.
Information disclosure
● Full path disclosure.
● Private or draft post, page, or content disclosure – unless the post type can leak extremely sensitive data.
● Enumeration that does not expose significant information (only confidentiality at Low impact).
● API key leakage that does not result in significant impact.
XSS, HTML & CSS injection
● Contributor-level (or higher) stored XSS.
● HTML-only injection without JavaScript execution – e.g. injection into emails or rendered output where script execution is not possible.
● CSS injection.
Authentication & access control
● 2FA bypass – typically Attack Complexity: High since you need the password to exploit.
● Lack of brute-force protection / rate-limiting (e.g. login). Excludes the login TOTP feature and sequential filenames.
● Account creation or registration with a low-privilege role (below Contributor).
● Arbitrary user registration unless it leads to a Contributor-or-higher account.
CSRF
● Multi-step CSRF exploits – e.g. CSRF to an admin action that then requires the admin to perform a second action to trigger the impact.
● CSRF must lead to one of: arbitrary file upload or deletion, privilege escalation (e.g. via an options change), RCE with a working PoC, or a settings change that leads to wider compromise.
● CSRF or access-control issues that only affect admin-notice dismissal, or IP bypass for non-critical actions.
File operations
● Non-arbitrary LFI – only accepted with full control over the path AND extension.
● Constrained-path LFI without a working directory-traversal exploit. Windows-specific bypass techniques are excluded.
● Non-arbitrary file uploads involving legacy extensions such as .phtml.
Open redirect
● Open redirect is inherently out of scope.
DoS, race conditions & SSRF
● Most race conditions (below CVSS 7.1).
● DoS, unless it has high availability impact and is demonstrable on any environment.
● Blind SSRF – must demonstrate concrete impact.
● AI feature token exhaustion.
4.1. All reported vulnerabilities must be new and unique and must not have been previously reported or publicly disclosed.
4.2. Exceptions apply if the vulnerability was first reported directly to the vendor prior to submission to Patchstack. Such reports are accepted only if the vendor contacts us to confirm the vulnerability and show a willingness to patch it. This requirement is mandatory for components developed or owned by Automattic, which must first be reported through Automattic’s HackerOne program.
4.3. If multiple researchers report the same vulnerability (even across different parameters or endpoints), credit is given to the first valid submission. Attempts to manipulate the system, such as using multiple accounts or submitting duplicates across different bounty programs may result in penalties, including account suspension.
4.4. Incomplete patches that are publicly disclosed are not considered new vulnerabilities. However, if an incomplete patch introduces a new attack vector that was not possible before, it may be considered a new vulnerability.
5.1. All reports must be submitted using the official reporting form and must follow the form’s requirements: https://patchstack.com/database/report
5.2. Reports must be complete, accurate, and reproducible. Incomplete reports will be rejected. Researchers are given up to two chances to fix and resubmit rejected reports.
5.3. Each report must include:
● A clear, step-by-step text-based proof of concept (PoC)
● Steps starting from plugin or theme installation and ending with successful exploitation
● All required raw HTTP request(s) in text form
● The exact payload(s) used during testing
● Video screenshots are highly appreciated
5.4. High rejected report rate of 50% (1/2 of all reports) or higher, will result in the researcher being removed from the leaderboard for one month, with a cooldown period applied (no reports accepted).
5.5. No bounties will be paid out for that specific month when the rejection rate was 67% (2/3 of all reports) or higher. All AXP from that month will be zeroed and will not count toward the overall AXP total or Levels.
5.6. If the same malicious behavior persists, the researcher will be permanently banned from the Patchstack Bug Bounty Program and the Patchstack Alliance community. Any pending bounties, if applicable, will be returned to the bug bounty pool.
5.7. Researchers who disregard the Patchstack mVDP by reporting or selling vulnerabilities to any third party (other CNAs, malicious actors) will be permanently banned from the Patchstack Bug Bounty Program and the Patchstack Alliance community. Their accounts will be deleted, and any associated achievements will be removed.
6.1. Reports may be rejected for reasons including, but not limited to:
● Incomplete or inaccurate information
● Invalid vulnerability claims
● Patchstack may reject reports if the affected component is not publicly distributed throughWordPress.org, Envato, GitHub, or another widely recognized repository.
● Reports submitted by the vendor or developer of the affected component are accepted for disclosure purposes but are not eligible for bounties.
7.1. Patchstack will use the most efficient publicly listed vendor contact channels for vulnerability reporting.
7.2. Contact methods that require account registration will be ignored.
7.3. If no contact details are available, the vulnerability may be disclosed immediately.
7.4. Vendors are notified once. It is the vendor’s responsibility to patch the issue promptly.
8.1. CVE IDs are assigned only after confirming there are no conflicts with existing CVEs. Assignment may be delayed to prevent duplicate CVE IDs across multiple CNAs.
8.2. If multiple researchers report the same vulnerability, the CVE is assigned to the first valid report. All later submissions are rejected.
8.3. Researchers may disclose vulnerabilities already reported to other programs by selecting the appropriate option during submission. In such cases, the vulnerability may be listed without a CVE ID.
9.1. XP (Research Points) are awarded for valid vulnerability reports and are used to determine competition rankings and winners on monthly competitions and custom events.
9.2. XP calculations are based on several factors, described below.
9.3. XP is calculated by adding multipliers (listed below) to the initial CVSS base score.
10.1. The CVSS v3.1 is the primary indicator of severity and must be calculated using the official calculator: https://www.first.org/cvss/calculator/3.1
10.2. We are using only CVSS base score for all the calculations.
11.1. Each range applies a multiplier to the final XP score
11.2. For premium products, active installs are estimated based on sales volume.
| Multiplier | Installs |
| x0.25 | < 1K installs (eligible only if component has at least 100 installs, a CVSS base score of 8.5 or higher, and can be exploited by unauthenticated users or users with Subscriber or Customer roles). |
| x0.5 | 1k+ active installs |
| x0.75 | 5K+ active installs |
| x1 | 10K+ 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 |
Privilege Requirement Coefficients
12.1. XP multipliers are applied based on the minimum privilege level required to exploit the vulnerability.
| Multiplier | Level of privilege |
| none | Editor, Author, Admin, Shop Manager, SuperAdmin (not accepted) |
| x0.75 | Contributor (only if CVSS base score is 7.5 or higher) |
| x1 | Subscriber and Customer (WooCommerce) |
| x2 | Unauthenticated |
Vulnerability Type Coefficients
13.1. XP multipliers are applied based on vulnerability type.
| Multiplier | Vulnerability type |
| x3 | Remote Code Execution (RCE), Arbitrary file upload, deletion, Privilege escalation to Admin users, Arbitrary code execution |
| x2 | SQL Injection (SQLi), Insecure Deserialization |
| x1.5 | Arbitrary file download, Privilege escalation to Non-Admin users |
| x1 | PHP Object Injection, Local File Inclusion (LFI) |
| x0.25 | Cross-Site Request Forgery (CSRF) |
| x0.2 | Race Condition |
13.2. If a CSRF vulnerability leads to another vulnerability type (for example, CSRF leading to RCE), both multipliers apply.
13.3. If install or sales numbers cannot be reliably determined, Patchstack may use public data sources such as Google SERPs or PublicWWW.
13.4. XP is calculated monthly or within the timeframe of a specific custom event. Ongoing results appear on the leaderboard: https://patchstack.com/database/leaderboard
13.5. Final results are announced after all reports are validated (up to 1 month if a backlog of reports requires more time for processing).
14.1. All vulnerabilities are publicly disclosed to the Patchstack Vulnerability Database according to the Patchstack Vulnerability Disclosure Policy.
14.2. Disclosure may be delayed until a fix is released and sufficient user adoption is observed.
14.3. Policy details: https://patchstack.com/patchstack-vulnerability-disclosure-policy/
14.4. Researchers must not disclose vulnerability details to any third parties before official public disclosure by Patchstack, which occurs when the vulnerability is publicly visible in the Patchstack Vulnerability Database and the assigned CVE is published.
14.5. To comply with EU CRA requirements all publications will be instant once the patch is released and validated (or released after validation).
14.6. The patch must be released as a dedicated update containing only security-related changes, with no additional code modifications. The version number or changelog description must clearly indicate that the release is a security fix.
15.1. If a vendor does not respond within 14 days, Patchstack may proceed with public disclosure and may notify relevant security teams.
15.2. For components enrolled in Patchstack mVDP, disclosure timelines may be extended. Disclosure may be accelerated in cases of active exploitation or third-party disclosure.
15.3. If a vendor overlooks a report and the vulnerability is publicly disclosed, they may contact us at triage@patchstack.com to receive prompt assistance with vulnerability details, quick patch validation, and issue resolution.
16.1. Public disclosures include researcher attribution using the provided name or nickname, and include ‘Patchstack Bug Bounty Program’ for program recognition.
16.2. CVE IDs are published in the global CVE database after disclosure with the same researcher data as in the Patchstack Vulnerability Database entry.
17.1. Monthly competitions run from the first day of the month at 00:00 UTC to the last day at 23:59 UTC.
17.2. Results are announced on the Patchstack Alliance Discord server.
17.3. Patchstack guarantees a minimum monthly bounty pool of $8,800, distributed based on final rankings.
17.4. Leaderboard: https://patchstack.com/database/leaderboard
18.1. Custom events and CTF games, along with their rules, are announced on Discord.
18.2. Custom challenges may be announced for extra bounties as part of the monthly competition.
19.1. Monthly bounties are distributed based on final leaderboard rankings as follows:
| Rank | Bounty |
| 1st place | $2,000 |
| 2nd place | $1,400 |
| 3rd place | $800 |
| 4th place | $600 |
| 5th place | $500 |
| 6th–10th place | $400 |
| 11th–15th place | $200 |
| 16th–19th place | $100 |
| 20th place + one random researcher | $50 |
19.2. A random bounty of $50 is awarded to one randomly selected researcher outside the top 20 rankings who has submitted at least one valid report with XP greater than 0.
19.3. High-impact vulnerabilities may be eligible for individual bounty rewards even if they do not qualify for the Zeroday program. Such cases are evaluated individually and must be discussed by opening a support ticket on the Patchstack Alliance Discord server in the #support channel.
20.1. Bounties are paid only if the researcher has more than 0 XP for the respective month. If a researcher has 0 XP, no bounty will be paid, even if their leaderboard position qualifies for a reward. This rule also applies to random rewards.
21.1. Researchers receive passive rewards for accumulating XP and progressing through levels. XP is earned through:
● Monthly competitions
● Custom events
● Patchstack Zeroday bounties
21.2. Levels reset to Level 1 at the beginning of each year. Updated level-related rules are announced after final monthly and yearly results are confirmed.
21.3. Starting from Level 1, researchers unlock additional rewards. These rewards are paid together with monthly bounties.
| Level | XP Required | Reward |
| Level 1 | 100 | $50 |
| Level 2 | 300 | $100 |
| Level 3 | 600 | $200 |
| Level 4 | 1,000 | $300 |
| Level 5 | 1,700 | $500 |
| Level 6 | 2,700 | $700 |
| Level 7 | 4,000 | $1,000 |
| Level 8 | 5,500 | $1,337 |
| Level 9 | 7,500 | $1,700 |
| Level 10 | 10,000 | $2,500 |
| Level 11 | 13,000 | $3,500 |
| Level 12 | 19,000 | $5,000 |
22.1. Patchstack offers Zeroday bounties for high-impact vulnerabilities on a case-by-case basis (bounty per vulnerability).
22.2. Zeroday rewards are paid together with monthly bounties.
22.3. Zeroday Bounties are:
| Active Installs | Unauthenticated | Subscriber / Customer |
| 1,000+ | $250 | $125 |
| 5,000+ | $400 | $200 |
| 10,000+ | $600 | $300 |
| 50,000+ | $1,400 | $700 |
| 100,000+ | $2,600 | $1,300 |
| 500,000+ | $4,900 | $2,450 |
| 1,000,000+ | $7,200 | $3,600 |
| 5,000,000+ | $14,400 | $7,200 |
| 15,000,000+ or WordPress Core (latest stable) | $33,000 | $16,500 |
22.4. Zeroday bounty requirements are as follows:
To qualify for a Zeroday bounty, all of the following conditions must be met:
● The component is a free or premium WordPress plugin, theme, or WordPress core(excluding components hosted in private, non-public repositories)
● The vulnerability leads to a full site compromise, including the ability to upload and access a functional backdoorExploitable by: Unauthenticated users, or Subscriber / Customer (WooCommerce) roles or lower
● The report includes a working exploit
● No prerequisites are required:
- Latest stable version
- Default settings
- Common environment
- No additional vulnerabilities required
● Exploitation does not require user interaction
● The vulnerability:
- Has not been reported elsewhere
- Is not previously known to the vendor
- Is not publicly disclosed
● The vulnerability is eligible under all other Patchstack program rules
● End-of-life components or components not updated in the last three years are not accepted
● Any required POP chain must exist in the latest WordPress core version at the time of submission, or the affected component itself
● A single vulnerability affecting multiple components is treated as one issue, resulting in:
- One bounty payout
- One CVE ID
- Total active installs across all affected components used to calculate impact
22.5. Valid Zeroday vulnerabilities are not included in XP for the monthly competition or levels, as they are rewarded separately.
22.6. XP points earned from Zero-day reports do not contribute to level progression (21. Level Rewards), as these reports are rewarded on a per-bounty, per-report basis.
23.1. Participation provides opportunities to:
● Earn financial rewards
● Gain public recognition
● Receive CVE IDs for valid vulnerabilities
● Contribute to improving the security of the WordPress ecosystem and open-source in general
● Engage with the Patchstack research community
24.1. Membership in the Patchstack Alliance is open to individuals committed to improving WordPress security and complying with program requirements. Members receive access to Discord member-only channels.
24.2. Patchstack reserves the right to remove or ban any researcher from the public Discord channels dedicated to the Alliance community and the Bug Bounty program (including account deletion) in cases of inappropriate behavior, violations of applicable rules, or failure to adhere to the ethical standards of responsible vulnerability disclosure.
25.1. Bounties are paid via PayPal by default. Researchers are responsible for managing their PayPal accounts and complying with all local tax obligations.
25.2. If a PayPal account is blocked, restricted, or frozen due to sanctions, Patchstack will attempt to complete payment within three months. After three months, unpaid bounties are returned to the bounty pool.
25.3. For bounties of $500 or higher, we offer two additional payment options:
● Bank transfer payments
● Cryptocurrency payments (Bitcoin or Ethereum) are processed using the exchange rate available at the time of payment. Patchstack is not responsible for any decrease in cryptocurrency value. By choosing this payout method, you acknowledge and accept all associated risks.
25.4. An invoice is mandatory regardless of the payment method. PayPal has its own integrated invoicing engine; for other payments, you need to generate invoices on your own. All payments require an invoice. Payments are not processed without one.
25.5. Invoices must include:
● Full name
● Country and address
● Addressed to: Patchstack OÜ
● Payment purpose:“Security research (your name or nickname used in the program)”
25.6. Payments are processed 30 days after final results are announced (counting from the day the invoice was submitted).
25.7. Additional payment guidance:
Invoice generation instructions are here.
26.1. Official updates are shared via:
● Discord: https://discord.gg/rkE8yxtNmS
● X (Twitter): https://twitter.com/patchstackapp
● Facebook: https://www.facebook.com/patchstackapp
● LinkedIn: https://www.linkedin.com/company/patchstack/
26.2. Support is available via Discord support tickets in the #support channel.
26.3. For edge cases or sensitive questions: darius.sveikauskas@patchstack.com
