rekor — security advisory
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 t
- Products
- rekor
- Affected versions
- 1.3.10-1, 1.3.9-1, 1.4.0-1, 1.4.2-1, 1.4.3-1, 1.5.0-1, 1.5.1-1, 1.5.2-1, 1.5.3-1, 1.5.3-2
- Fixed versions
- 1.5.2-1
- CVEs
- CVE-2026-48702
- Confirmed fixed CVEs
- Not specified
- Updated in this feed
- 1 Nov 2026, 04:07 UTC · Revision 1
Source evidence
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 t
osv:DEBIAN-CVE-2026-48702
rekor
Fixed versions: Not specified
rekor
Fixed versions: 1.5.2-1
Complete source record
{
"id": "ae6e5301026fa696f51e0f5e2ef23c46b9979d5621273fff65634447c2a07348",
"url": "https://osv.dev/vulnerability/DEBIAN-CVE-2026-48702",
"method": "structured",
"payload": {
"kind": "advisory",
"title": "DEBIAN-CVE-2026-48702",
"summary": "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 t",
"evidence": "osv:DEBIAN-CVE-2026-48702",
"products": [
{
"name": {
"value": "rekor",
"evidence": "/affected/0/package/name"
},
"prerequisites": [],
"fixed_versions": [],
"affected_versions": [
{
"value": "1.3.10-1",
"evidence": "/affected/0/versions"
},
{
"value": "1.3.9-1",
"evidence": "/affected/0/versions"
},
{
"value": "1.4.0-1",
"evidence": "/affected/0/versions"
},
{
"value": "1.4.2-1",
"evidence": "/affected/0/versions"
},
{
"value": "1.4.3-1",
"evidence": "/affected/0/versions"
},
{
"value": "1.5.0-1",
"evidence": "/affected/0/versions"
},
{
"value": "1.5.1-1",
"evidence": "/affected/0/versions"
},
{
"value": "1.5.2-1",
"evidence": "/affected/0/versions"
},
{
"value": "1.5.3-1",
"evidence": "/affected/0/versions"
},
{
"value": "1.5.3-2",
"evidence": "/affected/0/versions"
}
]
},
{
"name": {
"value": "rekor",
"evidence": "/affected/1/package/name"
},
"prerequisites": [],
"fixed_versions": [
{
"value": "1.5.2-1",
"evidence": "/affected/1/ranges"
}
],
"affected_versions": [
{
"value": "1.3.10-1",
"evidence": "/affected/1/versions"
},
{
"value": "1.3.9-1",
"evidence": "/affected/1/versions"
},
{
"value": "1.4.0-1",
"evidence": "/affected/1/versions"
},
{
"value": "1.4.2-1",
"evidence": "/affected/1/versions"
},
{
"value": "1.4.3-1",
"evidence": "/affected/1/versions"
},
{
"value": "1.5.0-1",
"evidence": "/affected/1/versions"
},
{
"value": "1.5.1-1",
"evidence": "/affected/1/versions"
}
]
}
],
"severity": "high",
"structured": {
"id": "DEBIAN-CVE-2026-48702",
"aliases": [
"DEBIAN-CVE-2026-48702"
],
"metrics": [
{
"type": "CVSS_V3",
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H"
}
],
"affected": [
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "0"
}
]
}
],
"package": {
"name": "rekor",
"purl": "pkg:deb/debian/rekor?arch=source&distro=trixie",
"ecosystem": "Debian:13"
},
"versions": [
"1.3.10-1",
"1.3.9-1",
"1.4.0-1",
"1.4.2-1",
"1.4.3-1",
"1.5.0-1",
"1.5.1-1",
"1.5.2-1",
"1.5.3-1",
"1.5.3-2"
],
"database_specific": {
"source": "https://storage.googleapis.com/debian-osv/debian-cve-osv/DEBIAN-CVE-2026-48702.json"
},
"ecosystem_specific": {
"urgency": "not yet assigned"
}
},
{
"ranges": [
{
"type": "ECOSYSTEM",
"events": [
{
"introduced": "0"
},
{
"fixed": "1.5.2-1"
}
]
}
],
"package": {
"name": "rekor",
"purl": "pkg:deb/debian/rekor?arch=source&distro=forky",
"ecosystem": "Debian:14"
},
"versions": [
"1.3.10-1",
"1.3.9-1",
"1.4.0-1",
"1.4.2-1",
"1.4.3-1",
"1.5.0-1",
"1.5.1-1"
],
"database_specific": {
"source": "https://storage.googleapis.com/debian-osv/debian-cve-osv/DEBIAN-CVE-2026-48702.json"
},
"ecosystem_specific": {
"urgency": "not yet assigned"
}
}
],
"modified": "2026-10-24T09:47:31.854758553Z",
"provider": "osv",
"upstream": [
"CVE-2026-48702"
],
"references": [
"https://security-tracker.debian.org/tracker/CVE-2026-48702"
]
},
"related_cves": [
{
"value": "CVE-2026-48702",
"evidence": "/upstream"
}
],
"security_relevant": true,
"severity_evidence": "/severity/0/score"
},
"source_id": "core-osv",
"document_id": 429005,
"published_at": "2026-08-13T14:17:01.427+00:00"
}