Reporting Vulnerabilities

Vulnerabilities happen. Some are unforgivable. Some are obscure. Reporting them still beats leaving them for someone less careful.

Usual path:

1. Write a report
2. Disclose to the vendor
3. Get a CVE where it makes sense
4. Publish after the embargo

Reality is messier - forum chatter first, silent exploitation, vendors that ignore the clock. Still write the report as if someone has to fix it on a Tuesday.

Write the report

Search first (CVE databases, vendor advisories). If it is new:

• Title - CVE.org's phrasing helps: [VULNTYPE] in [COMPONENT] in [VENDOR] [PRODUCT] [VERSION] allows [ATTACKER] to [IMPACT] via [VECTOR]. Example: SQL injection in a specific PHP endpoint with the POST parameter named.
• Summary and impact - what breaks, how bad, assumptions if you are assessing a library without knowing every consumer
• Technical detail - versions, config prerequisites (default or not?), attack vector, privileges, user interaction, CWE, reproduction steps, PoC if you have one
• Mitigations - suggested fix or workaround
• Credits / references

Score it with CVSS v4.0 (calculator). Ship the vector string with the score so others can argue with your choices.

Tell the vendor

Look for /.well-known/security.txt (e.g. Google's), a PSIRT page, or a SECURITY.md in the repo. Encrypt when the channel supports it. Keep a paper trail.

CVE

1. Find the right CNA - vendor first if they are one, else a national CNA (e.g. DirectCyber in Australia), else MITRE as last resort.
2. Follow that CNA's form - you will mostly paste from your report.
3. Honour the embargo. If the vendor ghosts you past the agreed window, get advice (CERT / lawyer) before you publish: victim impact and legal risk are real.

Then publish. Next bug.

Related

• Unforgivable Vulnerabilities for which vulnerabilities have no excuse
• Threat Modelling 101 for finding issues during design