PatchGap

Docs

PatchGap tracks 1-day and n-day vulnerabilities in the major browser engines. For every disclosed CVE it locates the fixing commit, extracts the code change, links the reporter’s original bug report and proof-of-concept where the vendor makes it public, and surfaces the patch gap — the window in which a fix is visible in the source repository before the CVE is formally disclosed.

What is tracked

Vendor Fix source Bug report PoC
Chrome (Chromium, V8, ANGLE, PDFium, Skia, Dawn, WebRTC) Chromium Gerrit issues.chromium.org (opened 30–90 days after fix) Reporter attachments, when published
Firefox Mercurial (hg.mozilla.org) Bugzilla (opened after an embargo period) Reporter attachments, when published
WebKit WebKit Subversion/Git — (Apple does not publish reports) —

The goal is to cover as many years as the vendor’s public record allows, not just the current cycle.

How a CVE maps to a commit

  1. CVE → bug id. Chrome CVEs are read from the Chrome Releases blog, which lists each fixed CVE with its tracker id and reward. Firefox uses the MFSA advisories.
  2. Bug id → change. A bug:<id> (plus message: and Fixes:) search against the vendor’s code-review system returns every change that references that id — across all sub-repositories and release branches.
  3. Change → the fix. A search returns more than the fix: dependency rolls, reverts, fuzzing/flag plumbing and test-only changes all cite the same bug. PatchGap filters these out and selects the change with the largest non-test source footprint on the main branch. Release-branch changes are recorded separately as backports.
  4. Fallbacks when the main branch has no obvious fix. A single bug: search often isn’t enough, so PatchGap resolves the fix through a series of fallbacks, recording which one succeeded:
    • Backports — a fix hand-applied only to a stable release branch (refs/branch-heads/…, tagged [Merge M###]) still counts.
    • External-host rolls — components with their own code review (Skia, PDFium, Dawn, WebRTC, libaom) are fixed upstream and rolled into the browser; PatchGap follows the roll to the real change.
    • Cross-referenced fixes — when only a regression test lands under a bug and its message points at the actual fix CL (under a sibling bug), that reference is followed.
    • Manual dependency rolls — a roll that itself patches a vendored copy (e.g. an ffmpeg security roll) is treated as the fix; a pure version-bump roll instead links the upstream commit range that contains it.
    • Duplicates — a bug closed as a duplicate is mapped to the fix that landed under its canonical bug id, while keeping the CVE’s own tracker link.
  5. No public fix? When none of the above resolves a change (or the fix is still embargoed), PatchGap records no commit and the CVE page shows a “Fix not yet public” notice rather than attributing the wrong change. Nothing is guessed.

The patch gap

Because a fix usually lands in the public repository before the CVE is disclosed, the interval between the two is a window in which the vulnerability is known to anyone reading commits but not yet to defenders relying on the advisory. PatchGap makes that window explicit per-CVE and in aggregate on the Statistics page.

Field reference

Each CVE page is driven by structured metadata:

  • Severity — the vendor’s own rating (Critical / High / Medium / Low).
  • Component — the affected sub-system, taken from the vendor’s advisory text (e.g. Proxy, V8, ANGLE), not merely the repository the fix landed in.
  • Bug class — the vulnerability type (UAF, OOB write, type confusion, integer overflow, logic/authorization error, …).
  • Fix commit — the located change, its repository and the lines added/removed. A green dot on the home table means a public fix was found; a dash means embargoed / not yet public.
  • CVSS — score and vector where an advisory provides one.
  • Exploited in the wild — flagged from the advisory’s own “an exploit for CVE-… exists in the wild” statement, and independently from CISA’s KEV catalog. Shown as an ITW marker on every table.
  • Root-cause analysis — a prose explanation of the vulnerable code path and the invariant that was violated (see below).
  • Attack path — the analysis distilled into ordered stages (Entry → Controlled input → Trigger → Missing check → Primitive → Impact).
  • Original bug report — the reporter’s own write-up and attachments, linked once the vendor unseals them.

Root-cause analysis methodology

RCA is generated from the actual patch diff and the reporter’s report, never from the CVE description alone. Each analysis identifies the vulnerable code path, the violated invariant, and why the fix closes it, then structures the exploitation into a labelled attack path. An RCA is only shown when a fixing commit has been located — an embargoed CVE gets the “Fix not yet public” notice instead, so nothing on the page is speculative.

Search & filtering

  • Every table (the home page, the per-vendor and per-release pages) sorts by any column and marks, at a glance: ITW (exploited), Fix (a green dot when the fixing commit is public), and RCA (a check when a root-cause analysis is written).

  • The Search page does structured + full-text search across every tracked CVE. Operators are shown as clickable chips and combine with AND:

    Operator Matches
    vendor:chrome Browser engine (chrome / firefox / webkit)
    component:v8 Affected component (substring)
    class:uaf Bug class (substring): UAF, OOB, TypeConfusion…
    severity:critical Vendor severity
    cvss:8+ CVSS ≥ 8 (also cvss:7-9, cvss:9.8)
    status:analyzed Analysis/fix state — also status:mapped, status:embargoed
    analyzed Has a root-cause analysis (alias rca:true)
    mapped:true A fixing commit is located (alias diffed:true)
    embargoed:true No public fix located yet
    itw Exploited in the wild
    kev:true CISA KEV listed
    has_poc:true Ships a regression test / PoC
    month:2026-09 Advisory month (YYYY-MM)
    author:"Name" Credited researcher (quotes required)

    Example: vendor:chrome class:uaf severity:critical status:analyzed. The result table carries a Status column (Analyzed / Mapped / Embargoed). The top-nav vendor links open pre-filtered searches.

Caveats

  • Component and bug-class labels follow the vendor’s own taxonomy and advisory wording; where the advisory is terse the label is a best-effort inference from the patch.
  • “Embargoed” means no public fix located, which occasionally reflects a fix that landed under a non-obvious reference rather than a true embargo.
  • Reward figures and reporter credit are shown only as published by the vendor.