CVE-2026-48702 — rekor
HIGHCVE-2026-48702 is a high-severity (CVSS 7.5) CWE-770 vulnerability in github.com/sigstore/rekor. A fix is available for github.com/sigstore/rekor — see the affected versions and patch details below.
Rekor has an OOM Condition due to Unbounded gzip Decompression in Alpine APK Parsing Logic
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-48702.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
Where this sits among everything scored
Real-World Exposure
github.com/sigstore/rekorReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.
Description
Rekor is a software supply chain transparency log. Starting in version 0.3.0 and prior to version 1.5.2, the Package.Unmarshal() function in pkg/types/alpine/apk.go decompresses the signature and control gzip members of an APK file into in-memory buffers without bounding the total decompressed size. The existing max_apk_metadata_size check (default 1MB) is only applied to individual tar entry header sizes after decompression completes, so it does not prevent a decompression bomb from consuming unbounded heap memory. An attacker can craft a gzip stream that compresses at a ~1000:1 ratio (e.g., 2MB compressed zeros → 2GB decompressed). When submitted as spec.package.content in an Alpine ProposedEntry, the server decompresses the full payload into memory during request processing, triggering a fatal Go runtime out-of-memory error or OS OOM-kill that cannot be caught by the server's recover() middleware. This is reachable via two unauthenticated endpoints, POST /api/v1/log/entries (createLogEntry) and POST /api/v1/log/entries/retrieve (searchLogQuery). Both invoke V001Entry.Canonicalize() → fetchExternalEntities() → apk.Unmarshal(packageData), which performs the unbounded decompression. Version 1.5.2 patches the issue. There is no effective workaround. Setting max_request_body_size reduces but does not eliminate exposure due to the ~1000:1 compression ratio (a 1MB body limit still allows ~1GB heap allocation). Setting max_apk_metadata_size has no effect on this vulnerability since the check is applied after decompression.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/sigstore/rekor | ≥ 0.3.0&&< 1.5.2 | 1.5.2go get github.com/sigstore/rekor@v1.5.2 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/sigstore/rekor, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update github.com/sigstore/rekor to 1.5.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-48702 is resolved across your whole dependency graph.
Workarounds
Cap what an attacker can consume: apply request size, rate and timeout limits in front of the affected component, and run it with memory and CPU limits so exhaustion degrades one worker rather than the whole service.
Fixing This On Your OS
If you run this on a Linux distribution, patch through your package manager against the distro's own security advisory below — it tracks the exact backported fix for your release, which can ship on a different timeline (and sometimes a different severity) than the upstream project.
A flaw was found in Rekor, a transparency log for supply chain security. The Alpine APK parsing logic decompresses gzip members without bounding total decompressed size, allowing a decompression bomb to cause out-of-memory conditions via unauthenticated API endpoints. This vulnerability is server-side only, affecting…
There is no effective workaround. Setting max_request_body_size reduces but does not eliminate exposure due to the ~1000:1 compression ratio (a 1MB body limit still allows ~1GB heap allocation). Setting max_apk_metadata_size has no effect on this vulnerability since the check is applied after decompression. Upgrade to Rekor 1.5.2 or later.Source: Red Hat security advisory for CVE-2026-48702 (CC BY 4.0)
| Product | Fixed in | Advisory |
|---|---|---|
| Red Hat Hardened Images | cosign-main-3.1.1-0.1.hum1 | RHSA-2026:25138 |
| Red Hat Hardened Images | trivy-main-0.72.0-0.1.hum1 | RHSA-2026:35111 |
| Red Hat Trusted Artifact Signer 1.3 | rhtas/rekor-server-rhel9:1787305397 | RHSA-2026:59439 |
| Red Hat Trusted Artifact Signer 1.4 | rhtas/rekor-server-rhel9:1785391524 | RHSA-2026:50873 |
Frequently Asked Questions
Is CVE-2026-48702 in your dependencies?
Find it across Go, including transitive dependencies.