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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-13T14:17:01.427Z",
  "pubdate": "2026-08-13T14:17:01.427Z",
  "executiveSummary": "An unbounded memory consumption vulnerability exists in Rekor within the Package.Unmarshal() function located in pkg/types/alpine/apk.go.\nThe flaw allows unauthenticated remote attackers to trigger a denial of service via a specially crafted Alpine APK file containing a high compression ratio gzip stream.\nWhen processed, the application decompresses signature and control gzip members into in-memory buffers without bounding the total decompressed size.\nThis bypasses the existing max_apk_metadata_size check, which only evaluates individual tar entry header sizes after decompression completes.\nExploitation results in a fatal Go runtime out-of-memory error or an operating system OOM-kill that evades server recovery middleware.\nAffected software includes Rekor versions starting from 0.3.0 and prior to 1.5.2.\nAttackers can leverage this vulnerability via two unauthenticated endpoints: POST /api/v1/log/entries and POST /api/v1/log/entries/retrieve.\nThere are no effective native workarounds, as setting max_request_body_size only mitigates the compression ratio partially and max_apk_metadata_size is ineffective.",
  "technicalDetails": "The vulnerability resides in the Package.Unmarshal() function within pkg/types/alpine/apk.go of the Rekor software supply chain transparency log.\nThe root cause is the lack of strict size bounds when decompressing the signature and control gzip members of an input APK file into in-memory buffers.\nThe existing max_apk_metadata_size configuration, defaulting to 1MB, fails to prevent this issue because it is only applied to individual tar entry header sizes after the complete decompression process has already finished.\nAn attacker can exploit this by crafting a malicious gzip stream with a high compression ratio of approximately 1000:1, such as transforming 2MB of compressed zeros into 2GB of uncompressed data in memory.\nThe attack flow begins when an unauthenticated attacker submits the malicious payload as spec.package.content within an Alpine ProposedEntry to the Rekor server.\nThe attack surface is exposed via two unauthenticated network endpoints: POST /api/v1/log/entries (createLogEntry) and POST /api/v1/log/entries/retrieve (searchLogQuery).\nBoth endpoints invoke V001Entry.Canonicalize(), which subsequently calls fetchExternalEntities(), and finally triggers apk.Unmarshal(packageData) to perform the vulnerable unbounded decompression.\nDuring request processing, the full payload expands entirely in heap memory, causing immediate exhaustion of available system memory.\nThis triggers a fatal Go runtime out-of-memory error or an OS-level OOM-kill that bypasses the server's recover() middleware, resulting in an unrecoverable service crash.\nThe vulnerability affects Rekor versions 0.3.0 up to, but not including, version 1.5.2."
}