CVE Patch Diffing
CVE-XXXX is a label. The diff is the evidence.
- → Vulnerable version
- ↓ Fixed version
- ↓ Git diff
- ↓ Changed function
- ↓ Security check
- ↓ Root cause
- ↓ Impact
GitHub Security Lab describes discovery and verification on public open source — clone, query, confirm. This program is that habit, written as a journal: the check that was added, the callers that remain, the impact class that is actually justified.
Notes
01/Lab Journal/CVE Patch Diffing
How to Read a Security Patch Like a Researcher
A patch is a map from intended fix to original weakness — if you read the check that was added, not the changelog sentence.
How a researcher reads a security patch: version pair, changed function, added check, and the weakness the check implies. No exploit walkthrough.
Read the journal note02/CVE Patch Diffing/CVE Patch Diffing
CVE Patch Diffing: Finding the Root Cause
CVE-XXXX is a label. The research product is the path from version pair to the invariant the fix finally enforced.
A repeatable patch-diffing series: vulnerable version, fixed version, git diff, changed function, security check, root cause, impact. No live exploit.
Read the journal note
FAQ
Questions
- What is the CVE patch-diffing method?
- Vulnerable version → fixed version → git diff → changed function → security check → root cause → impact. The CVE identifier is the index key, not the research product.
- Do you invent CVE numbers?
- No. Identifiers appear only after official assignment and coordinated disclosure. Until then the note describes a class or a public, already-assigned record.