ℹ️ Last updated: October 15, 2026
Overview and scope
Patchstack is committed to improving the security of the open-source web through responsible vulnerability discovery and disclosure.
Patchstack is a CVE Numbering Authority (CNA). This policy describes how Patchstack validates, coordinates, and publicly discloses vulnerabilities, as well as how it assigns CVE IDs and publishes CVE Records in accordance with the CVE Program CNA Operational Rules.
This policy applies to vulnerabilities in third-party PHP and JavaScript software (including WordPress core, plugins, and themes) discovered by Patchstack or by researchers participating in the Patchstack Bug Bounty Program.
CNA scope. Patchstack assigns CVE IDs for vulnerabilities in third-party PHP and JavaScript software discovered by Patchstack or reported through the Patchstack Bug Bounty Program, subject to the applicable CVE Program scope and right-of-first-refusal requirements. Our approved Scope Definition is published in the CVE Program List of Partners.
Vulnerabilities affecting Patchstack’s own products, services, or infrastructure are outside the scope of this policy and are governed by a separate Patchstack Vulnerability Disclosure Policy.
1. Vulnerability reporting and CVE requests
Researchers participating in the Patchstack Bug Bounty Program should submit vulnerabilities through our official reporting form. The program is governed by its Bug Bounty Guidelines & Rules.
Researchers participating in the Patchstack Bug Bounty Program must comply with the program’s Bug Bounty Guidelines & Rules, including requirements concerning confidentiality, coordination, and independent public disclosure. Researchers intending to publish vulnerability information independently must coordinate such disclosure with Patchstack in accordance with those rules.
Requests related to CVE ID assignment, CVE Record content, or corrections to records published by Patchstack can be sent to our public CVE contact, triage@patchstack.com. We aim to respond to these requests within 3 business days.
2. Validation and vendor notification
Patchstack aims to validate submitted vulnerabilities within 72 hours of receipt. Complex reports may require additional investigation.
Once a vulnerability is validated, Patchstack generally makes reasonable efforts to notify the affected vendor through publicly available and accessible contact channels.
Where direct vendor notification is unavailable, impractical, or where circumstances justify contacting the software’s distribution repository to protect users, Patchstack may notify repository management instead of, or in addition to, the vendor. Such repositories may include WordPress.org, npm, etc.
Patchstack provides affected vendors with the complete vulnerability report, including technical details, supporting evidence, attachments, and proof-of-concept (PoC) materials submitted by the researcher, to support vulnerability reproduction, investigation, and remediation.
Vendors are encouraged to acknowledge reports promptly and coordinate remediation with Patchstack.
3. CVE ID assignment
Patchstack generally reserves a CVE ID during the later stages of vulnerability processing, after validation and applicable CNA scope and duplicate-assignment checks, when public disclosure is planned. This approach is intended to minimize conflicting assignments where multiple CNAs may operate in overlapping areas.
- CNA right-of-first-refusal. Patchstack respects the CVE Program’s CNA scope and right-of-first-refusal requirements. Where the affected software falls within another CNA’s more specific scope, Patchstack coordinates CVE ID assignment and disclosure with the responsible CNA. If assignment responsibility is unclear or disputed, or the responsible CNA does not respond, Patchstack follows the applicable CVE Program coordination and escalation procedures before assigning a CVE ID.
- Reporter notification. When Patchstack assigns a CVE ID to a reported vulnerability, we provide the CVE ID to the reporter and vendor.
- CVE assignment criteria. Patchstack generally assigns separate CVE IDs to independently fixable vulnerabilities. Vulnerabilities originating from a shared vulnerable component across multiple products may be covered by a single CVE ID. Exceptions and special cases are handled in accordance with the applicable CVE Program assignment rules.
- Malicious code. Patchstack does not assign CVE IDs to software that is deliberately malicious by design. Legitimate software that has been compromised, for example through a backdoor or malicious code inserted into a release, may receive a CVE ID in accordance with CVE Program requirements.
- End-of-life, abandoned, and closed components. Patchstack may assign CVE IDs to vulnerabilities in software that no longer receives fixes, following the CVE Program’s End of Life Vulnerability Assignment Process. Records covering only such software are tagged “unsupported-when-assigned”. Software that has been closed or removed from its primary distribution repository is evaluated on a case-by-case basis, considering its maintenance status and the applicable CVE Program assignment rules.
- Unused IDs. CVE IDs that are reserved but not used are rejected in accordance with CVE Program requirements.
4. Disclosure timelines
Disclosure timelines begin on the date of Patchstack’s first documented attempt to notify the affected vendor or the relevant distribution repository management. Subsequent notifications, follow-ups, or escalations do not restart the timeline.
Patchstack follows the disclosure timelines below:
- 14 days, standard disclosure: Vulnerabilities may be publicly disclosed after 14 calendar days, regardless of patch availability.
- 7 days, vendor nonresponse: Patchstack may publicly disclose a vulnerability after 7 calendar days if neither the affected vendor nor the notified repository management has specifically acknowledged the vulnerability report or demonstrated meaningful engagement with it. Automated acknowledgments, generic ticket confirmations, and merely viewing or accessing a report do not constitute a qualifying response.
- Upon patch release: Patchstack may publicly disclose a vulnerability immediately upon the public release of a security patch. This includes incomplete or ineffective patches, even where the vulnerability remains unresolved or exploitable; residual issues may receive a new CVE ID or remain under the existing one. Patchstack retains discretion to delay disclosure when necessary to protect affected users.
- Exceptional circumstances: Patchstack may disclose vulnerabilities earlier in cases involving active exploitation, supply chain attacks (including malicious code modifications or dependencies), malware injection, or the removal or closure of a component in its primary public distribution repository.
If a CVE ID reserved by Patchstack becomes public before the corresponding Patchstack advisory, Patchstack publishes the advisory and the associated CVE Record within 72 hours of becoming aware of it.
All timelines refer to calendar days. Vendor acknowledgment or ongoing remediation does not automatically extend the disclosure deadline.
Patchstack may extend deadlines when justified by remediation complexity, demonstrated progress, or user safety considerations. Extensions are granted solely at Patchstack’s discretion and are not automatic.
Vendor approval is not required for Patchstack to publicly disclose a vulnerability once the applicable disclosure conditions have been met.
5. Public disclosure and CVE Record publication
Public disclosure by Patchstack begins with the publication of a vulnerability advisory in the Patchstack Vulnerability Database. The associated CVE Record is published to the CVE List within 48 hours of the advisory’s publication, subject to any earlier deadline arising from prior public disclosure of the assigned CVE ID or applicable CVE Program requirements.
Patchstack Vulnerability Database advisories are freely accessible to the public, require no registration or login, and are not subject to terms of use that restrict general-purpose use of the information or conflict with the CVE Program Terms of Use.
Published advisories may include affected software and versions, vulnerability severity, security impact, patch availability, and researcher attribution, where applicable. In CVE Records, researcher credit is given in the record’s credits field rather than in the description.
Vulnerabilities may be disclosed even when no security patch is available, including those affecting unresponsive vendors, abandoned software, or end-of-life (EOL) components.
Patchstack may limit the technical details published to reduce exploitation risks, while ensuring that disclosures meet the minimum information requirements of the CVE Program.
Researchers receive attribution according to their preferences and the applicable Patchstack Bug Bounty Program rules.
Patchstack reserves the right to make case-by-case disclosure decisions to protect affected users and the broader open-source ecosystem, within the requirements of the CNA Operational Rules.
6. CVE Record updates and rejections
Patchstack updates published CVE Records when material information changes, for example when a patch becomes available or affected versions are corrected.
If Patchstack later determines that no vulnerability exists, that a CVE ID was assigned in error, or that it duplicates another assignment, the CVE Record is rejected with an explanation, using the mechanisms specified by the CVE Program.
7. Disputes
Vendors who dispute or reject a reported vulnerability should provide a clear technical explanation supporting their position by contacting triage@patchstack.com.
Patchstack independently evaluates disputed vulnerabilities and makes the final decision on its own advisories and disclosure timing, subject to applicable CVE Program requirements. A vendor’s rejection or disagreement does not automatically invalidate a vulnerability, pause the disclosure timeline, or prevent public disclosure.
Where a dispute concerns a CVE ID assignment or the content of a CVE Record, Patchstack may update the record, mark it as “disputed” with an explanation, or reject it, in accordance with the applicable CVE Program rules.
If the disagreement cannot be resolved with Patchstack directly, either party may escalate it through the CVE Program Policy and Procedure for Disputing a CVE Record.
8. Contact and policy changes
- Vulnerability reports: Patchstack Bug Bounty Program reporting form
- CVE requests, record corrections, and disputes: triage@patchstack.com
Patchstack may update this policy at any time without prior notice. Changes take effect upon publication and generally apply to both new and ongoing vulnerability reports. Patchstack may, at its discretion, honor previously communicated disclosure arrangements where appropriate, subject to applicable CVE Program requirements.
9. Disclaimer and limitation of liability
Patchstack processes, validates, and publishes vulnerability information obtained through its own research and from independent security researchers, third-party vendors, and other external sources. This information is provided “as is”, without warranty of any kind. While Patchstack makes reasonable efforts to ensure its accuracy and reliability, and corrects or rejects inaccurate information as described in section 6, it does not warrant or guarantee its completeness, accuracy, or suitability for any particular purpose.
To the maximum extent permitted by applicable law, Patchstack disclaims liability for any direct or indirect financial, operational, reputational, or other losses or damages arising from or related to vulnerability reports, CVE assignments, public disclosures, published advisories, or reliance on information provided under this policy, including any inaccuracies, omissions, or disclosure decisions.
