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:
service_worker_presence— fires when achrome.service_workersartifact has registered origins.threshold: anyor an integer count.
Future detection_signal kinds can be added by extending the dispatch
table in digger/detectors/browser.py:
extension_perm— match against a permission name in installed-extensions data.profile_default— match a Preferences-JSON path (e.g., a deprecated default that lets a site override security posture).always_fire— for bugs where presence is universal; fires on every Chromium profile.
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.