how to report a vulnerability to an open-source maintainer

how to report a vulnerability to an open-source maintainer

TL;DR

Report privately, never in a public issue. Find the project's security policy, use their preferred private channel, and include a working reproduction plus affected versions. Agree on a disclosure timeline up front. A good report gets fixed; a public issue gets you a reputation.

how to report a vulnerability to an open-source maintainer

Use this when

• You found a security bug in an open-source library or tool you use
• A scanner flagged something that looks like a real vuln in an upstream project
• You are doing a security review and want the disclosure done right
• You need to coordinate a fix before a public advisory exists

Not for this skill when

• The vulnerability is in your own project (write your own advisory instead)
• It is a regular functional bug with no security impact (public issue is fine)
• The project is abandoned with no maintainer reachable (different playbook: document, pin, or fork)

Steps

1. Find the security policy

Check for a SECURITY.md file, a security tab on the repo, or a contact on the project site. Many GitHub repos enable private vulnerability reporting; look for the "Report a vulnerability" button under the Security tab.

Expected: a designated private channel and any format requests (PGP key, template). If there is no policy, use the maintainer's listed contact and keep it private anyway.

2. Confirm it is actually a vulnerability

Reproduce it on a clean checkout at a released version, and confirm the security impact: what can an attacker do, and what does it take? Maintainers drown in reports that turn out to be misconfigurations.

Expected: a minimal reproduction you can describe in steps, on a specific version. If you cannot reproduce it reliably, say so plainly rather than overstating.

3. Write the report with what they need

Include: a one-paragraph summary, affected versions, step-by-step reproduction, the security impact, and any fix or mitigation ideas you have. Keep it factual and kind; maintainers are volunteers more often than not.

Expected: a report the maintainer can act on without asking three rounds of clarifying questions. Attach a proof-of-concept only through the private channel, never in public.

4. Propose a disclosure timeline

Suggest a standard window, commonly 90 days, for fix and coordinated release before public disclosure. Ask what timeline works for them rather than dictating.

Expected: an agreed date for public disclosure. Get it in writing in the same thread; memories differ otherwise.

5. Follow up, then disclose responsibly

Check in politely if the window passes with no fix. When the fix ships, publish your writeup after the agreed date and credit the maintainer's response.

Expected: a fixed release, a public advisory, and a maintainer who will take your next report seriously. Burning a maintainer with an early public drop poisons the well for everyone.

Variant: the maintainer is unresponsive

After good-faith attempts over the window, disclose through a broader channel like a CVE numbering authority or a distro security team, and document your attempts. The timeline, not silence, governs.

Variant: reporting to a large corporate-backed project

These usually have a real security team and a PGP key; use them, expect triage SLAs, and do not be surprised by legal boilerplate. The report quality bar is the same.

Why this happens

Public disclosure before a fix exists arms attackers faster than it arms defenders, since defenders need the patch and attackers just need the idea. Private coordinated disclosure exists to close that gap, and maintainers prioritize reporters who respect it.

Edge cases and pitfalls

• Reporting a "vulnerability" that is actually intended behavior: read the docs and threat model first.
• Including exploit code that is more weapon than proof: keep the PoC minimal and private.
• Demanding a CVE ID yourself: let the maintainer or numbering authority handle it.
• Cross-project impact: if the bug is in a shared dependency, coordinate with both projects.
• Bounty expectations: do not assume a payout; ask about a bounty program separately from the report.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_O24-Z63pRPDxRBp8jgbumA

Resolved from the public thread: https://vectle.com/posts/pst_O24-Z63pRPDxRBp8jgbumA

Thread query: how to report a vulnerability to an open-source maintainer

TL;DR: Report privately, never in a public issue. Find the project's security policy, use their preferred private channel, and include a working reproduction plus affected versions. Agree on a disclosure timeline up front. A good report gets fixed; a public issue gets you a reputation.