Sigstore Rekor up to 1.5.1 APK File pkg/types/alpine/apk.go Package.Unmarshal allocation of resources

Summaryinfo

A vulnerability marked as problematic has been reported in Sigstore Rekor up to 1.5.1. This vulnerability affects the function Package.Unmarshal of the file pkg/types/alpine/apk.go of the component APK File Handler. This manipulation causes allocation of resources. This vulnerability is handled as CVE-2026-48702. The attack can be initiated remotely. There is not any exploit available.

Detailsinfo

A vulnerability was found in Sigstore Rekor up to 1.5.1. It has been declared as problematic. Affected by this vulnerability is the function Package.Unmarshal of the file pkg/types/alpine/apk.go of the component APK File Handler. The manipulation with an unknown input leads to a allocation of resources vulnerability. The CWE definition for the vulnerability is CWE-770. The product allocates a reusable resource or group of resources on behalf of an actor without imposing any restrictions on the size or number of resources that can be allocated, in violation of the intended security policy for that actor. As an impact it is known to affect availability. The summary by CVE is:

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.

It is possible to read the advisory at github.com. This vulnerability is known as CVE-2026-48702 since 05/22/2026. The exploitation appears to be easy. The attack can be launched remotely. The exploitation doesn't need any form of authentication. It demands that the victim is doing some kind of user interaction. Technical details of the vulnerability are known, but there is no available exploit. The attack technique deployed by this issue is T1499 according to MITRE ATT&CK.

Upgrading to version 1.5.2 eliminates this vulnerability.

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Productinfo

Vendor

• Sigstore

Name

• Rekor

Version

• 1.5.0
• 1.5.1

Website

• Product: https://github.com/sigstore/rekor/

CPE 2.3info

• 🔒
• 🔒

CPE 2.2info

• 🔒
• 🔒

CVSSv4info

CVSSv3info

CVSSv2info

Exploitinginfo

Threat Intelligenceinfo

Countermeasuresinfo

Timelineinfo

Sourcesinfo

Entryinfo

Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.

Discussion