"Vulnerability Disclosure: What to Do When You Find a CVE"

You found a vulnerability in an open source project. Now what? Most developers have never reported a CVE before, and the process feels intimidating. But it doesn't have to be.

This guide walks you through the entire process: from finding a vulnerability to getting it fixed and getting credit for the discovery.

Why Report Vulnerabilities?

1. It helps everyone — A fix for one project helps thousands of others using the same package

2. You get credit — CVE databases credit discoverers. It's good for your reputation.

3. It's the right thing to do — Responsible disclosure protects users before attackers exploit the issue

4. Bug bounties — Some projects pay for vulnerability reports ($100-$10,000+)

Step 1: Verify the Vulnerability

Before reporting, make sure it's real:

1. Reproduce the issue — Can you trigger it consistently?

2. Check for existing reports — Search CVE databases, GitHub issues, and security advisories

3. Document the impact — What can an attacker do? How severe is it?

4. Identify the affected versions — Which versions are vulnerable?

# Check if a CVE already exists
vulnledger scan . | grep "your-package-name"

Step 2: Find the Right Contact

Most open source projects have a security policy:

- Check SECURITY.md in the repo root

- Look for a security email in README.md

- Check the project's website for a security page

- If nothing exists, open a private security advisory on GitHub

Don't post the vulnerability publicly until it's fixed. Public disclosure before a fix exists gives attackers a roadmap.

Step 3: Write the Report

A good vulnerability report includes:

Subject Line

Security: [Vulnerability Type] in [Package Name] [Version]

Report Body

## Vulnerability Summary

**Package:** [package-name]
**Affected Versions:** [version range]
**Severity:** [Critical/High/Medium/Low]
**CVE ID:** [if assigned]

## Description

[Clear description of the vulnerability]

## Steps to Reproduce

1. [Step 1]
2. [Step 2]
3. [Step 3]

## Impact

[What an attacker can do with this vulnerability]

## Suggested Fix

[If you have a suggestion for how to fix it]

## Affected Versions

[List all affected versions]

## References

[Links to related CVEs, advisories, or research]

Example Report

## Vulnerability Summary

**Package:** requests
**Affected Versions:** < 2.31.0
**Severity:** High
**CVE ID:** CVE-2024-35195

## Description

The requests library leaks proxy credentials in certain redirect scenarios.
When a request is redirected through a proxy, the Proxy-Authorization header
is forwarded to the redirected URL, exposing the proxy credentials.

## Steps to Reproduce

1. Set up a proxy with authentication
2. Make a request through the proxy to a URL that redirects
3. Check the redirected request headers
4. The Proxy-Authorization header is present in the redirected request

## Impact

An attacker on the redirect target can capture proxy credentials,
potentially accessing internal network resources.

## Suggested Fix

Strip the Proxy-Authorization header before following redirects.

## Affected Versions

All versions before 2.31.0

## References

- https://github.com/psf/requests/security/advisories/GHSA-xxxx

Step 4: Send the Report

Preferred methods (in order):

1. GitHub Security Advisory — Private, tracked, and gets a CVE

2. Email to security@ — If the project has a security email

3. Private issue — If the project accepts private security issues

4. Direct message — Last resort, only if no other option exists

Never:

- Post the vulnerability publicly before it's fixed

- Post it on Twitter/Reddit without contacting the maintainer first

- Demand payment before the fix is released

Step 5: Follow Up

- Wait 7 days for an initial response

- If no response, try a second contact method

- If still no response after 14 days, consider coordinated disclosure

- Document everything — emails, dates, responses

Step 6: Get Credit

Once the vulnerability is fixed:

1. Request a CVE — through MITRE or the project's CVE numbering authority

2. Get listed — in the project's security advisory

3. Blog about it — write about the discovery process (after the fix is released)

4. Add to your portfolio — vulnerability discoveries are valuable credentials

Responsible Disclosure Timeline

Common Mistakes

Mistake 1: Public disclosure too early

Posting on Twitter before the maintainer has a fix gives attackers a head start.

Mistake 2: Not documenting properly

Vague reports ("there's a security issue") waste everyone's time. Be specific.

Mistake 3: Demanding payment

Bug bounties are voluntary. Don't demand payment before disclosing.

Mistake 4: Giving up after no response

Maintainers are busy. Follow up. Try alternative contacts. Be persistent but polite.

Mistake 5: Not getting credit

Always request a CVE number. It's your proof of discovery and valuable for your career.

How VulnLedger Helps

VulnLedger helps with the "finding" part of vulnerability disclosure:

pip install vulnledger
vulnledger scan .

The scan finds CVEs in your dependencies. For vulnerabilities you discover yourself (not in dependencies), follow the disclosure process above.

Conclusion

Vulnerability disclosure is a community responsibility. When you find a vulnerability, report it responsibly. The process is straightforward: verify, document, report, follow up, get credit. It helps everyone and builds your reputation as a security-conscious developer.

This is the final post in the "Open Source Security" series. Here's the complete list:

1. Why Open Source Security Is Everyone's Problem — The case for action

2. How to Audit Your Open Source Dependencies — The audit process

3. SBOM: The Document Every Open Source Project Needs — The inventory

4. This post — The disclosure process

Together with the "How to Write Safe Software" series, you now have a complete guide to software security:

- Secure Coding Guide

- Input Validation

- Dependency Security

- Secrets Management

- CI/CD Security

- Open Source Security

- Dependency Auditing

- SBOM Guide

- Vulnerability Disclosure

That's 9 posts forming a complete security knowledge base, all linking to each other and to VulnLedger.