Skip to main content
HIGH

CVE-2026-48702

CVSS v3

7.5

HIGH

EPSS Score

0.5 %

exploit probability, as of 2026-10-19

CISA KEV

No

known exploited

Exploitation

—

SSVC status

Get an alert for each new CVE published for sigstore/rekor.

Set up CVE WatchFree account · no credit card

Affected and fixed versions

Packages from OSV.dev and products from the vendors' CSAF advisories.

version not verifiedVersions not verified: read as OSV.dev and the vendors publish them, not checked against each vendor's release list.

Packages

  • github.com/sigstore/rekorGofrom 0.3.0 · fixed in 1.5.2

Vendor advisories

  • CVE-2026-48702 Red Hat Product Security8 products fixed · 2 known affected

    github.com/sigstore/rekor: Rekor: Denial of Service due to unbounded gzip decompression in Alpine APK parsing

    multicluster-engine/assisted-service-9-rhel9 as a component of Multicluster Engine for Kubernetes · rekor as a component of Red Hat Trusted Artifact Signer

  • RHSA-2026:59439 Red Hat Product Security1 product fixed

    Red Hat Security Advisory: RHTAS 1.3.7 - Red Hat Trusted Artifact Signer Release

  • RHSA-2026:50873 Red Hat Product Security1 product fixed

    Red Hat Security Advisory: RHTAS 1.4.3 - Red Hat Trusted Artifact Signer Release

  • RHSA-2026:35111 Red Hat Product Security3 products fixed

    Red Hat Security Advisory: Red Hat Hardened Images RPMs Security Update

  • RHSA-2026:25138 Red Hat Product Security3 products fixed

    Red Hat Security Advisory: Red Hat Hardened Images RPMs bug fix and enhancement update

Full record on NVD

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.

Technical details

CVSS v3 Vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Published
2026-08-13
Last Modified
2026-08-13

Frequently asked questions

What is CVE-2026-48702?

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.

Is CVE-2026-48702 actively exploited?

Active exploitation of CVE-2026-48702 has not been confirmed. Its EPSS score was 0.5% on 2026-10-19, the estimated probability of exploitation in the next 30 days.

What is the CVSS score for CVE-2026-48702?

CVE-2026-48702 has a CVSS v3 base score of 7.5 (HIGH severity), with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H.

Running sigstore/rekor? Hear about its next vulnerability

CVE Watch matches each new CVE to the vendors and products you list (vendor and product, not the version) and puts it in your alerts with its KEV and EPSS status.

Get alerts for this productCISA KEV additions, October 2026Search CVEs

Already have an account? Open CVE WatchNo credit card required · No monthly cap on website lookups · 250 API requests/month

Go further

Related vulnerabilities

Same product first, then the same vendor advisory and the same publication week.

Back to CVE Database