Short version

** There are more conditions. See all rules.*

Long version

  1. Membership
    1. Patchstack Alliance is an open community of cyber security researchers, developers, pentesters, and bug bounty hunters (hereafter in the text - members).
    2. Everyone can join the Patchstack Alliance as long as they are committed to making the WordPress ecosystem safer.
    3. By submitting at least one valid vulnerability report that meets the Patchstack Alliance vulnerability report submission requirements, you become a member of the Patchstack Alliance.
    4. Each Patchstack Alliance member will have its public profile page on the Alliance platform website (available after the official Alliance platform launch). The profile will include basic information about the member and all the data related to member activities (research points, discovered vulnerabilities, achievements badges, social links).
    5. Communication between Patchstack and Patchstack Alliance members should be done by email at and on the Patchstack Alliance Slack. All reports should be submitted only by vulnerability report submission form.
    6. Each member must provide a basic set of information about themselves, like the name (we need your name to be able to pay out the bounties), a nickname if you want to protect your privacy in your Patchstack Alliance public profile, and public vulnerability descriptions. Also, a valid email address that we will use for bounty payouts by PayPal and general communication.
    7. We have not set an age limit, but members must ensure that they are able to legally accept bounties in their local jurisdiction.
    8. Each member is responsible for the tax obligations for payouts received through the Patchstack Alliance.
    9. Patchstack Alliance members could be asked to give interviews as we want to introduce Patchstack Alliance members to the public for transparency and project promotion purposes.
    10. We expect common sense, responsibility, and abstinence from actions that may, in one way or another, damage the image of the Patchstack Alliance project.
    11. Patchstack reserves the right to expel any member from the Patchstack Alliance member list for unethical or malicious acts that may affect Patchstack and Alliance's image, even if malicious acts are not directly related to the Patchstack Alliance activities.
  2. Vulnerabilities and report submission
    1. Everyone can submit vulnerability report(s) to the Patchstack Alliance if they make it in accordance with Patchstack Alliance rules.
    2. All vulnerabilities submitted to the Patchstack Alliance project will be disclosed (once they got processed by Patchstack vulnerability disclosure rules) to the Patchstack Vulnerability Database - a public and free vulnerability database We will allow everyone to access, save, share and use this information as we don't want to limit the spread of this information.
    3. All vulnerabilities submitted by Patchstack Alliance members must be new and unique. It means all submitted vulnerabilities should not be reported or published anywhere before to ensure Patchstack Alliance will be the first and only recipient who will get the particular vulnerability report. We want to avoid duplicate CVE ID submissions or other possible issues that could waste our resources or harm our reputation. Vulnerabilities that have been previously publicly disclosed, published, reported elsewhere will be rejected.
    4. All vulnerability reports should be submitted by using the submission form available here - We don’t accept submissions by email or in another form. At this moment we accept only vulnerability reports for WordPress ecosystem components like WordPress core, plugins, and themes. We accept reports for all WordPress plugins and themes regardless of whether they are free or premium. But keep in mind that for premium components reports we require to provide the original (unaltered) archive of the component so we could use it for vulnerability validation.
    5. The Patchstack Alliance adheres to a philosophy of ethical disclosure. Therefore, disclosing a vulnerability is pending until the software manufacturer publishes a patched version and most users update it on their websites. The aim is to minimize the negative impact that disclosure of vulnerabilities can cause. You can read more in Patchstack Vulnerability Disclosure Policy -
    6. Suppose the software manufacturer takes no action and ignores the information received for 30 days. In that case, the vulnerability will be disclosed and reported to the WordPress Security Team ( if the vulnerable component is distributed by a WordPress plugin or theme repository.
    7. We will disclose vulnerabilities on behalf of the author (we will use the name or nickname you have provided to us and a link to your Twitter or LinkedIn account). However, we will add "(Patchstack Alliance)" to the author's name to publicity the whole project. Finally, if an Alliance member wants to stay incognito, we will add "Patchstack Alliance member" as an author.
    8. Make sure you provide all vulnerability details in your reports. All additional (unreported) vulnerabilities that will be discovered in the process of reported vulnerability validation or verification of patches applied by vendors will be published in the name of the in-house Patchstack researcher who will find these unreported issues.
    9. Pay attention to the quality of your reports, test them carefully before submitting them to the Patchstack Alliance. Incomplete reports will be rejected with the possibility to fix the report two times. We will count the last fix date as the submission date, so if you submitted a report in June, but there were issues and you updated information to fix the issue in July, we will count it as a report submitted in July.
    10. Three reports rejected per month will lead to a cooldown period. It means that we will not accept reports from such members for the next month.
    11. What could cause rejection: incomplete report, invalid report, wrong data (missed vulnerability title, wrong vulnerability type, inaccurate payload, etc.), reports generated by using non-standard user roles (doesn’t apply to user roles created by the vulnerable plugin), or users with altered permissions.
    12. We do not accept reports for closed plugins or themes that are not distributed actively on or another public repository.