CVE-2026-48702
HighCVSS 7.5Exploitation Probability (EPSS)
Low risk39th percentile - higher than 39% of all known CVEs
Summary
Rekor, a software supply chain transparency log, contains a decompression bomb vulnerability in the `Package.Unmarshal()` function for APK files. An attacker can submit a specially crafted APK file that decompresses to a huge amount of memory, causing a server crash. The vulnerability affects versions 0.3.0 through 1.5.1 and is reachable via two unauthenticated endpoints.
Risk Assessment
The risk is the ability to remotely trigger an out-of-memory (OOM) error in the Rekor server, leading to denial of service (DoS). The attack requires no authentication, and request size limits do not fully mitigate the issue due to the high compression ratio.
Recommendation
Immediately upgrade Rekor to version 1.5.2 or later, which contains the fix. If upgrading is not possible, consider restricting access to the API endpoints or applying additional network-level protections, but note that there is no effective workaround.
Other vulnerabilities in Rekor
See all- CVE-2026-24117Medium
Rekor versions 1.4.3 and below allow SSRF to arbitrary internal services because /api/v1/index/retrieve supports retrieving a public key via a user-provided URL. The SSRF can only trigger GET requests, cannot mutate state, and the response is not returned, so only blind SSRF (internal network probing) is possible.
- CVE-2026-23831Medium
In Rekor (a software supply chain transparency log) versions 1.4.3 and below, the entry implementation can panic on attacker-controlled input when canonicalizing a proposed entry with an empty spec.message, causing a nil pointer dereference. The validate() function returns nil (success) when the message is empty, leaving sign1Msg uninitialized, and Canonicalize() later dereferences v.sign1Msg.Payload. A malformed proposed entry of the cose/v0.0.1 type can cause a panic on a thread within the Rekor process. The thread is recovered so the client receives a 500 error and the service continues, so the availability impact is minimal. This issue has been fixed in version 1.5.0.
- CVE-2023-33199Medium
The vulnerability in Rekor allows a malformed entry of type `intoto/v0.0.2` to cause a panic in a thread within the Rekor process. However, the service continues to run, and the client receives a 500 error message.
Original NVD description (English source)
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.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS