CVE bundle changelog
The Vulkro CVE bundle is the offline-first vulnerability database the scanner matches your dependencies against. Built from OSV, NVD, CISA KEV, and EPSS feeds, signed with the production trust root, and published weekly to dist.vulkro.com.
This page records what changed in each bundle release: new advisories
added, severity revisions, KEV additions, and EPSS shifts above the
0.5 threshold (the cut Vulkro uses to bump a finding from Medium to
High at scan time). The bundle itself never leaves your machine after
vulkro update downloads it; this page is the inventory log so
you can see whether a given week's bundle would affect your scan
without having to apply it first.
How to read an entry
Each weekly release is one section, dated and tagged by bundle version. Per-section fields:
- New advisories: count of records added since the prior bundle,
bucketed by ecosystem (
npm,pypi,cargo,go,gem,composer,maven). - Severity revisions: records whose computed CVSS / KEV / EPSS-derived severity changed from the prior bundle. Increases (Medium → High → Critical) and decreases (Critical → High because the CVSS got re-scored) are both listed.
- KEV additions: CVEs added to CISA's Known Exploited Vulnerabilities catalog since the prior bundle. KEV-listed CVEs bump to Critical regardless of CVSS.
- EPSS shifts: records whose EPSS exploitation probability
crossed the 0.5 threshold in either direction. EPSS ≥ 0.5
triggers a
[priority: epss-high]annotation in scan output.
How the bundle is built
tools/cve-bundler (a separate workspace member) fetches OSV +
NVD + KEV + EPSS once per week, normalises every record into the
canonical CveRecord schema (crates/cve-schema), tarballs the
staging dir, signs it with the production ed25519 key kept in
Cloudflare R2, and publishes to dist.vulkro.com/cve/<version>.tar.gz
plus a manifest.json that points at it.
The build is reproducible: given the same source feeds at the same
fetch timestamps, the same bundle bytes come out. The trust root is
compiled into the vulkro binary, so a tampered bundle on the CDN
is rejected client-side at install time.
Verifying a bundle
# Install the latest bundle (signature verified against compiled-in trust root).
vulkro update
# Force a re-download even when the cache is fresh.
vulkro update --refresh
# Air-gapped: copy the .vkbundle file to the target machine and run
# `vulkro update --bundle ./vulkro-<version>.vkbundle`.
The full bundle format, signing pipeline, and trust-root rotation policy are in Bundle format and Signing & trust roots.
Recent releases
Bundle release entries appear here as they ship. The list is
generated from each release's signed manifest.json via
tools/cve-bundler/changelog_gen.py; check the
release pipeline
for the full archive.
Setup note: this page renders the changelog from each bundle's
manifest.json. Until the next weekly release lands a manifest with the newchangelog:block, this section reads "no entries yet". The generator emits one section per release in reverse-chronological order.
No bundle release entries yet. The first weekly bundle that ships with a populated changelog: block in its manifest will land here.
Subscribing to bundle updates
Three ways to stay current:
- GitHub releases: subscribe to repo releases on the vulkro release feed. Each bundle release is tagged.
- CLI auto-check: every
vulkroinvocation hits the GitHub release feed once per machine per day (24h cache, 2s timeout, opt out withVULKRO_NO_UPDATE_CHECK=1) and prints a one-line notification when a newer bundle is available. - This page: bookmark it. The bundle pipeline updates the
changelog block before publishing the new
.vkbundletodist.vulkro.com.
Reporting a stale or wrong record
If a CVE entry in a bundle is wrong (severity, affected versions, withdrawn upstream but still in our cache), file an issue against the vulkro repo with the bundle version + CVE id. Bundle corrections ship in the next weekly release; we don't push out-of-band patches mid-week unless the issue is a KEV-listed CVE we missed.