GHSA-47Q9-M4WW-924M
Vulnerability from github – Published: 2026-06-25 21:33 – Updated: 2026-06-25 21:33Description
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) - POST /api/v1/log/entries/retrieve (searchLogQuery)
Both invoke V001Entry.Canonicalize() → fetchExternalEntities() → apk.Unmarshal(packageData), which performs the unbounded decompression.
Workarounds
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.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/sigstore/rekor"
},
"ranges": [
{
"events": [
{
"introduced": "0.3.0"
},
{
"fixed": "1.5.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-48702"
],
"database_specific": {
"cwe_ids": [
"CWE-770"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-25T21:33:36Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Description\n\nThe `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.\n\nAn attacker can craft a gzip stream that compresses at a ~1000:1 ratio (e.g., 2MB compressed zeros \u2192 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\u0027s recover() middleware.\n\nThis is reachable via two unauthenticated endpoints:\n- POST /api/v1/log/entries (createLogEntry)\n- POST /api/v1/log/entries/retrieve (searchLogQuery)\n\nBoth invoke `V001Entry.Canonicalize()` \u2192 `fetchExternalEntities()` \u2192 `apk.Unmarshal(packageData)`, which performs the unbounded decompression.\n\n## Workarounds\n\nThere 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.",
"id": "GHSA-47q9-m4ww-924m",
"modified": "2026-06-25T21:33:36Z",
"published": "2026-06-25T21:33:36Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/sigstore/rekor/security/advisories/GHSA-47q9-m4ww-924m"
},
{
"type": "PACKAGE",
"url": "https://github.com/sigstore/rekor"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
],
"summary": "Rekor has an OOM Condition due to Unbounded gzip Decompression in Alpine APK Parsing Logic"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.