CVE-2026-48702

Rekor has an OOM Condition due to Unbounded gzip Decompression in Alpine APK Parsing Logic

View on CVE.org
Published Aug 13, 2026 CVSS 3.1 · 7.5 High EPSS < 1% KEV · Not listed
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.

Analysis

No analysis available yet

Remediation

No remediation available yet

Tracking

Sign in to view the affected projects.

Advisories

Source ID Title
Github GHSA Github GHSA GHSA-47q9-m4ww-924m Rekor has an OOM Condition due to Unbounded gzip Decompression in Alpine APK Parsing Logic
History
Type Values Removed Values Added
Metrics ssvc

{'options': {'Automatable': 'yes', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}
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
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

None

 cvssV3_1

{'score': 7.5, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H'}

threat_severity

Important

Subscriptions

No data.

Weaknesses
  • CWE-770

    Allocation of Resources Without Limits or Throttling

Sources

Status
PUBLISHED
Assigner
GitHub_M
Published
Updated
Aug 13, 2026, 3:16 PM
Reserved
May 22, 2026, 6:47 PM

View source JSON

Updated
Aug 13, 2026, 3:15 PM

JSON

Status
Awaiting Analysis
Published
Aug 13, 2026, 2:17 PM
Modified
Oct 23, 2026, 6:10 PM

View source JSON

Severity
Important
Public date
Jun 25, 2026, 9:33 PM

View source Bugzilla JSON

No data.