CVE-2026-48702

CVE-2026-48702 in Rekor's APK parser isn't really a decompression bomb vulnerability — it's a control architecture failure that deserves explicit attention in your vulnerability assessments. The issue is that Rekor implemented `max_apk_metadata_size` as a security guard, but the check fires on decompressed tar header sizes, which means a 2MB crafted gzip payload will fully decompress into ~2GB of heap memory before any guard can intervene. The control exists, was clearly intended as a security measure, and is structurally incapable of serving its purpose because it executes after the damage already occurred. Go's runtime OOM panic is unrecoverable at the application layer — surrounding `recover()` middleware cannot catch it, so the process terminates regardless. The unauthenticated attack surface compounds this: two HTTP endpoints invoke the vulnerable code path without any credential requirement, meaning a single POST request can kill a Rekor instance. The CVSS 7.5 rating obscures the operational reality. This isn't a recoverable error — it's process-level termination via uncaught runtime panic, triggered trivially. The EPSS score of 0.00461 is more misleading than helpful: it models per-CVE exploitation likelihood but doesn't account for trivial exploitability. Standard gzip, known endpoints, no authentication, no CSRF, no rate limit described. An attacker doesn't need to exploit the data — they just need to make verification unreliable, and for a transparency log, availability IS integrity. Disrupting Rekor creates uncertainty about software provenance downstream. The patch in v1.5.2 targets `pkg/types/alpine/apk.go` and the `Unmarshal()` function — the correct fix moves bounded decompression logic inside the parser itself rather than at the HTTP layer. But audit your other package type parsers (RPM, Debian, etc.) proactively: this vulnerability class tends to be structural rather than isolated, and the APK parser is likely older infrastructure that received less scrutiny than newer attestation formats. When you upgrade, verify that the patch didn't introduce new unbounded `io.ReadAll` calls in adjacent decompression paths — emergency CVE fixes often patch the immediate hole without auditing nearby code. Check whether your Rekor deployment is exposing the vulnerable endpoints externally; if so, rate-limit or restrict access immediately as a compensating control while you patch.

Reviewed through automated stages and approved by a human before publication.