CVE-2026-48702 in Rekor
Summary
by MITRE • 08/13/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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/13/2026
The Rekor software supply chain transparency log system presents a critical memory exhaustion vulnerability affecting versions between 0.3.0 and 1.5.1 inclusive. This flaw stems from the Package.Unmarshal() function within pkg/types/alpine/apk.go which processes APK file signatures and control gzip members without implementing size limits on decompressed content. The vulnerability operates through a decompression bomb attack vector where an attacker crafts malicious gzip streams that compress at ratios approaching 1000:1, transforming small compressed payloads into massive decompressed data structures. When an Alpine ProposedEntry with such malicious content is submitted via the unauthenticated POST /api/v1/log/entries endpoint or the POST /api/v1/log/entries/retrieve endpoint, the system performs unbounded memory allocation during request processing.
The technical implementation of this vulnerability manifests in the absence of proper decompression size bounds enforcement within the APK parsing pipeline. While Rekor does implement a max_apk_metadata_size check set to 1MB by default, this validation mechanism only applies to individual tar entry header sizes after decompression has already completed. This timing gap allows attackers to exploit the decompression process before any size limitations can be enforced, creating a scenario where the Go runtime encounters fatal out-of-memory conditions that cannot be recovered from by the server's existing recover() middleware. The vulnerability is reachable through two distinct API endpoints that both traverse the same code path involving V001Entry.Canonicalize() → fetchExternalEntities() → apk.Unmarshal(packageData), making the attack surface particularly broad.
The operational impact of this vulnerability extends beyond simple denial-of-service conditions to include complete system crashes and resource exhaustion across the entire Rekor deployment. Memory allocation patterns that approach 2GB from only 2MB of compressed data create an environment where operating system OOM-kill mechanisms are triggered, effectively terminating the Rekor service and rendering it unavailable for legitimate supply chain transparency operations. The attack requires no authentication credentials and can be executed through standard HTTP POST requests, making it particularly dangerous for publicly accessible Rekor instances. This vulnerability directly aligns with CWE-400 Uncontrolled Resource Consumption and maps to ATT&CK technique T1499.004 Network Denial of Service within the context of supply chain attacks.
Mitigation efforts present significant challenges due to the fundamental nature of the vulnerability within the decompression logic. Version 1.5.2 introduced a patch addressing this specific issue by implementing proper size bounds enforcement during the decompression phase rather than after completion. However, no effective workarounds exist for affected versions since setting max_request_body_size only provides partial protection due to the extreme compression ratios involved. A 1MB body limit still permits approximately 1GB of heap allocation, while max_apk_metadata_size remains ineffective because it operates on decompressed data that has already consumed system resources. Organizations should prioritize upgrading to Rekor version 1.5.2 or later to ensure complete protection against this memory exhaustion vulnerability that could compromise the integrity and availability of their supply chain transparency infrastructure.