Unpatched Chromium bugs A corpus for "known-bug-the-vendor-won't-fix-but-affects-every-Chrome-user" issues.

Some Chromium bugs are disclosed but never patched — sometimes for years. Project Zero has the most famous tracker for these but it focuses on 90-day-disclosure outcomes; what's missing is a persistent, machine-readable corpus of issues that affect every Chromium user right now and where the only remediation is a workaround.

digger ships digger/rules/browsers/chromium_unpatched.yaml as that corpus. BrowserDetector consumes it; adding a new entry fires a new finding with zero code changes.

The canary: crbug-40062121

The seed entry is crbug 40062121 — disclosed summer 2022 by Lyra Rebane. Mechanism: a registered service worker can keep firing background fetches and keep its parent registration alive long after the tab that installed it has closed, effectively turning the browser into a permanent botnet node controlled by the registering origin.

The Chromium ticket was made private shortly after disclosure. No patch has shipped to date. Every Chromium-based browser (Chrome / Edge / Brave / Arc / Vivaldi / Opera) at every version is affected.

digger emits a high-severity finding on every Chrome profile that has any registered service worker, with the workaround attached:

$ digger scan --case-dir /tmp/case
  [    high]  short_id=40062121  profile=Default     origins=34
           Unpatched Chromium bug 40062121 applies on profile Default:
           Persistent service-worker + background-fetch botnet primitive

           Workarounds:
             - Open chrome://serviceworker-internals and unregister any
               origins you do not recognize
             - Periodically purge ~/Library/Application Support/<browser>/
               <profile>/Service Worker/ (browser quit first)
             - Disable site-isolation/notification permissions on origins
               not actively needed

Corpus schema

Each entry in chromium_unpatched.yaml:

issues:
  - id: crbug-40062121         # digger stable identifier
    short_id: "40062121"       # upstream bug tracker number
    title: ...                 # human-readable one-liner
    url:   ...                 # upstream bug tracker URL
    discovered: "2022"         # year first observed
    disclosed:  "2022"         # year publicly disclosed
    vendor_status: "private"   # one of: private | won't fix | out of scope | pending
    affected_versions: "all"   # "all" = open-ended unpatched
    impact: "high"             # info | low | medium | high | critical
    detection_signal:
      kind: service_worker_presence   # see Detection signals below
      threshold: any                  # "any" or integer count
    workaround:
      - "..."                  # operator-actionable mitigations
    references: ["..."]
    notes: |                   # free-form context
      ...

Detection signals (extensible)

The detector recognizes:

Future detection_signal kinds can be added by extending the dispatch table in digger/detectors/browser.py:

Adding a new entry

No code changes required. Append to digger/rules/browsers/chromium_unpatched.yaml:

  - id: crbug-NEW
    short_id: "NEW"
    title: "Short description of the bug"
    url: "https://issues.chromium.org/issues/NEW"
    vendor_status: "won't fix"
    affected_versions: "all"
    impact: "medium"
    detection_signal:
      kind: service_worker_presence
      threshold: any
    workaround:
      - "what the operator should do"
    references:
      - "https://example.com/advisory"

Re-run digger scan and findings for the new bug appear.

Why digger-curated, not live-feed?

The live-first convention requires that every bundled rule have a live-feed counterpart. The chromium_unpatched.yaml corpus is an explicit # live-first-ok opt-out: no canonical "vendor-won't-fix browser bugs" feed exists today. When one is published in a stable machine-readable form (e.g., a future Project Zero data export), digger swaps to load_intel() with this file as fallback per the established convention.