CVE-2026-48702: 
Datadog Agent vulnerability analysis and mitigation

CVE-2026-48702 is a denial-of-service vulnerability in Sigstore's Rekor transparency log server caused by unbounded gzip decompression during Alpine APK parsing. The Package.Unmarshal() function in pkg/types/alpine/apk.go decompresses gzip members of APK files into in-memory buffers without any size limit, enabling a decompression bomb attack. It affects Rekor versions >= 0.3.0 and < 1.5.2, with version 1.5.2 containing the fix. The vulnerability was first published by researcher Hayden-IO on May 26, 2026, and added to the GitHub Advisory Database on June 25, 2026. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Rekor Advisory).

The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling): the Package.Unmarshal() function reads and fully decompresses the signature and control gzip members of an APK file into heap memory with no upper bound on decompressed size. The existing max_apk_metadata_size guard (default 1MB) is applied only to individual tar entry header sizes after decompression completes, making it ineffective against this attack. An attacker crafts a gzip stream with approximately a 1000:1 compression ratio (e.g., 2MB of compressed zeros expanding to ~2GB), submits it as spec.package.content in an Alpine ProposedEntry, and triggers the decompression during request processing. The resulting fatal Go runtime out-of-memory error or OS OOM-kill cannot be caught by the server's recover() middleware, causing a hard crash. The vulnerable code path is reachable via two unauthenticated HTTP endpoints: POST /api/v1/log/entries and POST /api/v1/log/entries/retrieve, both of which invoke V001Entry.Canonicalize() → fetchExternalEntities() → apk.Unmarshal(packageData) (GitHub Advisory, Rekor Advisory).

Successful exploitation causes a complete denial of service of the Rekor transparency log server. Because the OOM condition triggers a fatal Go runtime error or OS OOM-kill that bypasses the server's error recovery middleware, the server process terminates entirely rather than gracefully rejecting the request. This disrupts the availability of the software supply chain transparency log, potentially impacting CI/CD pipelines and artifact signing/verification workflows that depend on Rekor. There is no confidentiality or integrity impact — the vulnerability is purely an availability issue (GitHub Advisory).

1. Identify target: Locate an internet-facing or network-accessible Rekor server running version >= 0.3.0 and < 1.5.2.
2. Craft decompression bomb: Create a gzip-compressed payload consisting of highly compressible data (e.g., repeated null bytes) achieving approximately a 1000:1 compression ratio — for example, ~2MB compressed data that expands to ~2GB when decompressed.
3. Construct malicious APK: Package the crafted gzip stream as the signature or control member of an Alpine APK file structure.
4. Submit via unauthenticated endpoint: Send an HTTP POST request to either POST /api/v1/log/entries or POST /api/v1/log/entries/retrieve with the malicious APK embedded in the spec.package.content field of an Alpine ProposedEntry JSON body.
5. Trigger OOM crash: The server's apk.Unmarshal() function decompresses the full payload into heap memory, exhausting available RAM and triggering a fatal Go runtime OOM error or OS OOM-kill, crashing the Rekor server process (GitHub Advisory).

• Network: Unexpected or repeated HTTP POST requests to /api/v1/log/entries or /api/v1/log/entries/retrieve with unusually large Content-Length values or Alpine APK content types from unknown or suspicious source IPs.
• Logs: Rekor server logs showing abrupt process termination without a graceful shutdown message; Go runtime fatal error messages such as runtime: out of memory or fatal error: runtime: out of memory in server stderr/logs.
• Process: Sudden disappearance of the Rekor server process; OS-level OOM-kill events logged in /var/log/kern.log or dmesg referencing the Rekor process (e.g., Out of memory: Kill process <pid> (rekor-server)).
• System: Spike in memory consumption on the Rekor host immediately preceding a server crash, visible in system monitoring tools.

The only effective remediation is upgrading Rekor to version 1.5.2 or later, which contains the fix for unbounded decompression (GitHub Advisory, Rekor Advisory). There is no effective workaround: setting max_request_body_size reduces but does not eliminate exposure, since a 1MB body limit still permits approximately 1GB of heap allocation at a 1000:1 compression ratio. Setting max_apk_metadata_size has no effect because the check is applied after decompression completes. Organizations should prioritize upgrading immediately, and in the interim consider restricting network access to Rekor API endpoints to trusted clients only.

The vulnerability was discovered and reported by researcher Hayden-IO, who published the advisory to the sigstore/rekor repository on May 26, 2026. The advisory was reviewed and added to the GitHub Advisory Database on June 25, 2026. An openSUSE security announcement was also issued referencing the vulnerability (openSUSE Security). No broader media coverage or notable community commentary beyond the official advisory has been identified.