The Package.Unmarshal() function in the Alpine APK parsing logic of github.com/sigstore/rekor decompresses gzip streams into memory buffers without bounding the total decompressed size. Although a max_apk_metadata_size limit exists, it only applies after decompression to individual tar entry headers, not to the decompression process itself. An attacker can craft a gzip stream with a high compression ratio (~1000:1) that decompresses into a very large memory allocation (e.g., 2MB compressed to 2GB decompressed). When such a payload is submitted via the unauthenticated POST /api/v1/log/entries or POST /api/v1/log/entries/retrieve endpoints, the server decompresses it fully in memory, causing a fatal Go runtime OOM error or OS-level OOM kill. The vulnerability is present in versions >=0.3.0 and <1.5.2. There is no effective workaround; limiting request body size only reduces but does not eliminate risk due to the high decompression ratio.

This vulnerability allows unauthenticated remote attackers to cause a denial of service by exhausting server memory, leading to a fatal runtime out-of-memory error or process termination by the operating system. There is no impact on confidentiality or integrity reported. The service becomes unavailable due to resource exhaustion.

No effective workaround is currently available. Limiting the maximum request body size reduces but does not eliminate the risk because of the high decompression ratio possible. The max_apk_metadata_size setting does not mitigate this vulnerability as it is checked only after decompression. Users should monitor the vendor advisory for an official fix or patch. Patch status is not yet confirmed — check the vendor advisory for current remediation guidance.