High [CVE-2026-48702] Denial of Service due to unbounded gzip decompression in Alpine APK parsing
This high-severity Red Hat Linux advisory covers CVE-2026-48702 affecting Red Hat Hardened Images, Red Hat Trusted Artifact Signer 1.3, Red Hat Trusted Artifact Signer 1.4.
Android app · Google Play
Monitor future Red Hat Linux CVEs from your phone.
Choose a whole vendor or a precise platform, then receive matching security advisories by phone notification, email, or both. Coverage follows 32 official vendor sources and 160+ reviewed platform categories.
Summary
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.
- < 0.3.0
- < 1.5.2
Official advisory · high-confidence parse· fetched 12 days ago·verify at source
- cosign-main-3.1.1-0.1.hum1
- trivy-main-0.72.0-0.1.hum1
- rhtas/rekor-server-rhel9:1787305397
- rhtas/rekor-server-rhel9:1785391524
- RHSA-2026:25138
- RHSA-2026:35111
- RHSA-2026:59439
- RHSA-2026:50873
Official advisory · high-confidence parse· fetched 12 days ago·verify at source
Mitigation checklist
- 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. Upgrade to Rekor 1.5.2 or later.
Official advisory · high-confidence parse· fetched 12 days ago·verify at source
Discussion(0)
No comments yet. Share field notes, upgrade gotchas, or questions — verify against the vendor advisory before acting on community advice.
Sign in to join the discussion.