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.
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||
|---|---|---|---|---|---|---|---|---|---|
| sigstore | rekor | affected |
|
No data.
No data.
No data.
Project Subscriptions
No data.
Advisories
| Source | ID | Title |
|---|---|---|
 Github GHSA |
GHSA-47q9-m4ww-924m | Rekor has an OOM Condition due to Unbounded gzip Decompression in Alpine APK Parsing Logic |
Fixes
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
References
History
Thu, 13 Aug 2026 16:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
Thu, 13 Aug 2026 14:00:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | A flaw was found in Rekor. The `Package.Unmarshal()` function, which processes Alpine Package Keep (APK) files, decompresses gzip streams without limiting the total decompressed size. A remote attacker can exploit this by crafting a malicious APK file with a high compression ratio, causing the server to consume excessive memory. This leads to a Denial of Service (DoS) through an out-of-memory (OOM) error, and can be triggered via unauthenticated API endpoints. | 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. |
| Title | github.com/sigstore/rekor: Rekor: Denial of Service due to unbounded gzip decompression in Alpine APK parsing | Rekor has an OOM Condition due to Unbounded gzip Decompression in Alpine APK Parsing Logic |
Tue, 14 Jul 2026 00:15:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Description | A flaw was found in Rekor. The `Package.Unmarshal()` function, which processes Alpine Package Keep (APK) files, decompresses gzip streams without limiting the total decompressed size. A remote attacker can exploit this by crafting a malicious APK file with a high compression ratio, causing the server to consume excessive memory. This leads to a Denial of Service (DoS) through an out-of-memory (OOM) error, and can be triggered via unauthenticated API endpoints. | |
| Title | github.com/sigstore/rekor: Rekor: Denial of Service due to unbounded gzip decompression in Alpine APK parsing | |
| Weaknesses | CWE-770 | |
| References |
| |
| Metrics |
threat_severity
|
cvssV3_1
|
Projects
Sign in to view the affected projects.
MITRE
Status: PUBLISHED
Assigner: GitHub_M
Published:
Updated: 2026-08-13T15:16:26.293Z
Reserved: 2026-05-22T18:47:27.754Z
Link: CVE-2026-48702
Vulnrichment
Updated: 2026-08-13T15:15:33.515Z
NVD
Status : Received
Published: 2026-08-13T14:17:01.427
Modified: 2026-08-13T16:18:05.570
Link: CVE-2026-48702
Redhat
OpenCVE Enrichment
No data.
Weaknesses