Pwnote cve research

CVE Research & Disclosure Workflow

Reference for running a vulnerability research + responsible disclosure engagement from initial finding through published advisory and CVE assignment.

1. Disclosure Timeline Tracking

Track every engagement as a timestamped activity log (maps to pwnote activity blocks or a timeline block):

Stage	What to log
Discovery	date, affected product/version, initial severity assessment
Vendor contact	date, channel used (security.txt, PSIRT email, HackerOne if they run a VDP), response received y/n
Vendor acknowledgment	date, vendor's stated timeline/SLA
Fix development	vendor updates, patch ETA changes
Embargo date	agreed public disclosure date — track any renegotiation
CVE assignment	date requested, date assigned, CVE ID
Publication	advisory published date, links

Default disclosure window if the vendor is unresponsive: industry norm is 90 days from initial contact before considering public disclosure, with recognition that this can extend if the vendor engages in good faith and needs more time for a complex fix. State your policy explicitly in the first vendor contact so there's no ambiguity later.

2. CVE Request Workflow

Two paths:

• Vendor has a CNA (most major vendors do) — request through their PSIRT/security contact; they issue the CVE.
• Vendor has no CNA — request via MITRE's CVE Request form, or use a CNA-of-last-resort if the vendor is unresponsive after your disclosure window has elapsed.

MITRE submission needs (map these fields when drafting a request):

• Vendor and product name(s) + affected version range
• Vulnerability type (map to a CWE — see references/cwe-mapping.md)
• Attack vector and prerequisites (what access/conditions are needed)
• Impact statement (confidentiality/integrity/availability, written concretely)
• Discoverer credit line (how you want to be attributed)
• Reference URLs (advisory, patch, vendor bulletin) — can be added after assignment if not yet published

Keep the description factual and impact-focused; MITRE reviewers reject vague submissions ("could allow attackers to do bad things") — be specific about what the flaw actually allows.

3. Advisory Writing Template

# [Vendor] [Product] — [Vuln Type] (CVE-YYYY-NNNNN)

## Summary
[1-2 sentences]

## Affected Versions
[version range]

## Details
[technical root cause explanation]

## Impact
[what an attacker can achieve]

## CVSS
Score: X.X
Vector: CVSS:3.1/...

## CWE
CWE-XXX: [name]

## Timeline
- YYYY-MM-DD: Discovered
- YYYY-MM-DD: Vendor notified
- YYYY-MM-DD: Vendor acknowledged
- YYYY-MM-DD: Patch released
- YYYY-MM-DD: CVE assigned
- YYYY-MM-DD: Public disclosure

## Credit
[researcher name/handle]

## References
- [patch link]
- [vendor bulletin]

This matches the structure used for prior published advisories (SSRF and auth-bypass class findings) — keep the format consistent across advisories so they're easy to reference as a set.

4. PoC Documentation Standards

Maintain two PoC versions:

• Public advisory PoC — sanitized, no working exploit for unpatched instances if patch isn't yet widely deployed; enough to prove the claim, not enough to be a turnkey exploit
• Client/internal PoC — full technical detail, kept in the engagement's private notes only, never in the published advisory

Default to withholding full exploit detail until patch adoption is reasonably mature, and use judgment on whether any technical detail should be withheld longer for high-impact/hard-to-patch classes (e.g. widely deployed infrastructure software).

5. Reference Files

• references/cwe-mapping.md — quick-lookup CWE categories for common vuln classes
• references/cna-submission.md — field-by-field MITRE/CNA submission checklist