CVE-2026-48702: Rekor has an OOM Condition due to Unbounded gzip Decompression in Alpine APK Parsing Logic
Vulnerability summary
CVE-2026-48702 is a high (CVSS 7.5) vulnerability in sigstore rekor. EPSS estimates a 0.46% chance of exploitation in the next 30 days, higher than 39.9% of scored vulnerabilities.
Severe, CVSS 7.5 (CVE.org); no exploitation reported by the 5 checked sources; EPSS 0% (FIRST, 03-11-2026)
Source freshness unavailable
How is this decided?Advisory lineage
Upstream 0 · Downstream 5 · Related 4Timeline
- 13-08-2026PublishedVulnerability first disclosed.
- 13-08-2026Last modifiedVulnerability information updated.
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.
CVSS metrics
7 scores · 7 sources · 1 version- OSV · UbuntuEcosystem advisory · calculated7.5HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- OSV · DebianEcosystem advisory · calculated7.5HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- OSV · WolfiEcosystem advisory · calculated7.5HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- OSV · GoEcosystem advisory · calculated7.5HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- OSV · ChainguardEcosystem advisory · calculated7.5HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- NVDNIST7.5HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
EPSS trend
Probability
0.46%
Chance of exploitation in the next 30 days
Percentile
40%
Versus all other CVEs
30-day change
No change 0.00 pp
From 0.46% on 04-10-2026
Known exploited
Compare KEV catalogsNot in the CISA KEV catalog.
Not in the ENISA CNW catalog.
Not in the CIRCL catalog.
Public exploits
0 foundNo public exploits indexed.
Weaknesses
CWE · root causeAffected systems
Known conditions: network-reachable, no authentication, no user interaction (CVSS vector). Other conditions: not stated in public data.
Chainguard156 products
- aactl< 0.4.12-r60
- chainctl-fips< 0.2.292-r1
- cloudbeat-8.17< 8.17.10-r31
- cloudbeat-9.0< 9.0.8-r33
- cloudbeat-9.1< 9.1.10-r23
Wolfi40 products
- aactl< 0.4.12-r60
- crossplane-2.1< 2.1.7-r2
- crossplane-2.2< 2.2.3-r2
- falcoctl< 0.13.0-r7
- gitsign< 0.16.1-r1
Debian1 product
- rekorAll versions (No fix recorded) | < 1.5.2-1
Github.com/sigstore1 product
- rekor≥ 0.3.0, < 1.5.2
Opensuse1 product
- hauler&distro=openSUSE Tumbleweed< 2.0.1-1.1
Ubuntu1 product
- rekorAll versions (No fix recorded)
6 vendors · 200 products · Showing 200 of 201
References
9 links- github.com/sigstore/rekorPACKAGE