Vulnerability disclosure policy

At a glance

This page defines NextPDF’s coordinated vulnerability disclosure policy. It tells you how to contact the maintainers privately, what response timeline to expect, and how embargoes work.

Boundary. A disclosure policy is a process commitment, not a timeline or outcome guarantee. The targets below are the maintainers’ good-faith commitments to you as a reporter; they describe the process the project follows, not a contractual promise that any specific report will be acknowledged, triaged, fixed, or disclosed by any specific date. Coordinated-disclosure timing is negotiated, not unilaterally guaranteed.

Install

Not applicable. You do not need to install anything to report a vulnerability. The machine-readable contact surface is published at /.well-known/security.txt (Request for Comments (RFC) 9116). The repository SECURITY.md is the authoritative human-readable policy.

Conceptual overview

The policy implements coordinated vulnerability disclosure as defined by ISO/IEC 29147 and the handling process in ISO/IEC 30111 (iso_iec_30111#x9.x43.p2): private intake, triage and severity assessment, remediation under embargo, and joint public release. If a vulnerability affects multiple vendors, the affected parties coordinate advisory timing instead of setting it unilaterally (iso_iec_29147#x3.x110.p13).

The process also aligns with the manufacturer vulnerability-handling obligations in the European Union (EU) Cyber Resilience Act (CRA) (eu_cra#x1.p191) and the “respond to vulnerabilities” practice in the National Institute of Standards and Technology (NIST) Secure Software Development Framework (SSDF) (nist_sp_800_218#x15). Both describe these as repeatable process duties, not as a warranty that any individual outcome is guaranteed.

API surface

Not applicable. Disclosure is a process, not an application programming interface (API). The machine-readable discovery surface is the RFC 9116 security.txt file; tooling reads its Contact: and Expires: fields. This page does not duplicate that file’s contents beyond the channels below.

Code sample — Quick start

Not applicable. There is no code to run when you report a vulnerability. Use a private channel:

GitHub Security Advisories (preferred — encrypted at rest, audit log): open a draft advisory in the project’s GitHub Security tab.
Email: [email protected] with [SECURITY] in the subject. If you require end-to-end encryption and no published OpenPGP key is listed yet in security.txt, use the GitHub Security Advisory channel instead.

Do not report through public issues, public mailing lists, social media, or chat. Public disclosure before a fix puts users on unpatched versions at risk.

Code sample — Production

Not applicable.

Edge cases & gotchas

Targets are commitments, not service-level agreements (SLAs). The timeline below states what the project aims to do. A complex multi-component issue, or one that requires upstream coordination, can take longer; the project keeps the reporter informed.
Embargo length is negotiable, with a ceiling. The default embargo runs from triage to fix release. If you need longer, request it explicitly when you open the advisory. After the maximum, the project will publish the advisory whether or not a fix is available, consistent with industry coordinated-disclosure norms. This protects users from an indefinitely withheld advisory.
Severity drives the schedule. A critical, actively exploited issue is handled on a compressed timeline; a low-severity hardening suggestion is not. Severity is assessed during triage and can be revised.
Common Vulnerabilities and Exposures (CVE) issuance is part of triage. The maintainer requests a CVE through the project’s GitHub Security Advisory CVE Numbering Authority (CNA) enrollment as part of the triage step; the reporter does not need to request one separately.

Performance

Not applicable.

Security notes

The response-timeline targets are commitments to reporters and form the project’s vulnerability-handling baseline. They are targets, not guarantees:

Stage	Target
Acknowledge receipt	within 1–2 business days
Initial triage + severity assessment	within ~5 business days / 7 calendar days
Patch development + private review	typically 14 business days; 30–90 days for complex confirmed CVEs depending on severity
CVE assignment (if accepted)	concurrent with patch, via the GitHub CNA channel
Coordinated public disclosure	at patch release, on a date set jointly with the reporter
Embargo (from triage to release)	default ~90 days, reduced under active exploitation, extendable on explicit request up to a fixed maximum

Reviewers can check these process rules:

Private-first. No public channel is accepted for intake. The only accepted channels are the GitHub Security Advisory and the security email.
Coordinated, not unilateral. Disclosure timing is negotiated with the reporter and any co-affected vendors (iso_iec_29147#x3.x110.p13).
Bounded embargo. The embargo has a default and a hard ceiling; the project does not withhold an advisory indefinitely.
Credit on request. Researchers are credited after the embargo lifts, unless they request anonymity.

These statements describe the process the project commits to follow. They do not guarantee that a given report will result in a fix, a CVE, or a disclosure by a particular date.

Conformance

Not a conformance profile. The policy aligns with ISO/IEC 29147, ISO/IEC 30111, and the CRA and SSDF process duties cited above; “aligned with” is deliberate wording. The project does not assert certification against any of these schemes. They define a sound process; this page documents the project’s commitment to operate one.