Answer in brief
CVE-2026-48702 records a High severity (CVSS 7.5) vulnerability in Rekor has an OOM Condition due to Unbounded gzip Decompression in Alpine APK Parsing Logic. The current sources do not mark it as known exploited. The current feed maps sigstore/rekor (generic), github.com/sigstore/rekor (go), github.com/sigstore/rekor (go). Check affected ranges and fixed versions before updating.
Analysis pending evidence review
HOL Guard separates source facts from reviewed analysis. See the methodology.
CVSS is 7.5. The current sources do not mark it as known exploited. Treat this as a source-backed prioritization signal, not a statement about your environment.
Analysis status
Analysis pending evidence review
Factual feed record only; HOL analysis is not approved for indexing. Read the methodology.
The current feed maps sigstore/rekor (generic), github.com/sigstore/rekor (go), github.com/sigstore/rekor (go). Check affected ranges and fixed versions before updating.
| Package | Affected range | Fixed version |
|---|---|---|
| sigstore/rekorgeneric | >=0.3.0 <1.5.2 | 1.5.2 |
| github.com/sigstore/rekorgo | >=0.3.0,<1.5.2 | 1.5.2 |
| github.com/sigstore/rekorgo | >=0.3.0 <1.5.2 | 1.5.2 |
Published upstream
Aug 13, 2026
Evidence: source:cvelist:source_dates:source-dates:recordSource modified
Oct 23, 2026
Evidence: source:cvelist:source_dates:source-dates:recordFirst seen by HOL
Jun 25, 2026
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.
Quoted source text, attributed separately from HOL analysis.