CVE Patch Diffing: Finding the Root Cause

This is the flagship series for the laboratory. Each entry will take a public CVE with a public fix and stop at root cause and impact class. We will not title notes “What is CVE-XXXX?” and we will not publish a working exploit.

The method is the same every time so readers can audit the reasoning: version pair, diff, function, check, invariant, reachability, impact.

The vulnerability is whatever the fix actually closes. Advisories often name a CWE that is adjacent but not precise — for example “input validation” when the real issue is object injection after a deserializer, or “access control” when a single object-level check was missing.

Until the diff is read, the CWE is a hypothesis.

Open-source projects with tagged releases are the default corpus. We prefer software that is network-facing or used as a library inside network-facing services — web frameworks, API gateways, deserializers, and AI inference stacks.

We do not list unreleased or unconfirmed product names as if they were findings.

Surface is derived from callers of the changed function. If the function is only reachable from a local CLI, the CVE may still be real and still not be a remote finding. If it is reachable from an unauthenticated HTTP or RPC path, record that as the surface.

Root cause is a failed assumption: the bytes were trusted, the identifier was assumed to belong to the session, the URL was assumed to stay on-origin, the pickle stream was assumed to come from a local file.

Write the assumption in one sentence. If you cannot, you do not yet have a root cause.

This series always draws the same spine so later notes can be compared.

RCE is a possible impact class, not the default. It appears when the failed assumption sits in front of execution: unsafe deserialization, dynamic code load, native memory writes, or a plugin entry point.

If the check is an authorization predicate on a data object, the likely impact is information disclosure or state change. Say so. Do not upgrade it to RCE to make the note look more serious.

Practical steps we use in the lab: clone both tags, diff with function context, discard tests-only noise, then read production callers. Note whether the check is centralized or copy-pasted. Copy-pasted checks are where variants live.

We record “what is still accepted” as carefully as “what is now rejected.” Residual acceptance is the next research question, validated privately.

For defenders: watch for the vulnerable version range and for the specific function remaining reachable in your build. For researchers: watch security commits and CVE-linked PRs as a feed, then apply this method before writing anything public.

Upgrade to the fixed range after you confirm the check exists in the artifact you actually run — containers often pin transitive libraries that release notes forget.

If you cannot upgrade, mitigate at the surface: remove the endpoint, require authentication, or stop accepting the unsafe encoding. Workarounds are stopgaps, not root-cause fixes.

A CVE identifier is an index key. The laboratory product is a traced path from patch to impact. That is what a research portfolio should show.

CVE Program — https://www.cve.org/ — identifiers after assignment, not before.

NVD — https://nvd.nist.gov/ — published records and version ranges.

GitHub Security Lab public research notes on verification workflows.

Art of Vector Security disclosure policy — /about/responsible-disclosure.