CVE-2026-48702
Rekor has an OOM Condition due to Unbounded gzip Decompression in Alpine APK Parsing Logic
Description
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 this vulnerability since the check is applied after decompression.
INFO
Published Date :
Aug. 13, 2026, 2:17 p.m.
Last Modified :
Oct. 23, 2026, 6:10 p.m.
Remotely Exploit :
Yes !
Source :
[email protected]
CVSS Scores
| Score | Version | Severity | Vector | Exploitability Score | Impact Score | Source |
|---|---|---|---|---|---|---|
| CVSS | 134c704f-9b21-4f2e-91b3-4a467353bcc0 | |||||
| CVSS 3.1 | HIGH | [email protected] | ||||
| CVSS 3.1 | HIGH | MITRE-CVE |
Solution
- Update Rekor to version 1.5.2.
- Apply vendor patches if using an affected version.
References to Advisories, Solutions, and Tools
Here, you will find a curated list of external links that provide in-depth
information, practical solutions, and valuable tools related to
CVE-2026-48702.
| URL | Resource |
|---|---|
| https://github.com/sigstore/rekor/security/advisories/GHSA-47q9-m4ww-924m |
CWE - Common Weakness Enumeration
While CVE identifies
specific instances of vulnerabilities, CWE categorizes the common flaws or
weaknesses that can lead to vulnerabilities. CVE-2026-48702 is
associated with the following CWEs:
Common Attack Pattern Enumeration and Classification (CAPEC)
Common Attack Pattern Enumeration and Classification
(CAPEC)
stores attack patterns, which are descriptions of the common attributes and
approaches employed by adversaries to exploit the CVE-2026-48702
weaknesses.
We scan GitHub repositories to detect new proof-of-concept exploits. Following list is a collection of public exploits and proof-of-concepts, which have been published on GitHub (sorted by the most recently updated).
Results are limited to the first 15 repositories due to potential performance issues.
The following list is the news that have been mention
CVE-2026-48702 vulnerability anywhere in the article.
The following table lists the changes that have been made to the
CVE-2026-48702 vulnerability over time.
Vulnerability history details can be useful for understanding the evolution of a vulnerability, and for identifying the most recent changes that may impact the vulnerability's severity, exploitability, or other characteristics.
-
CVE Translated by [email protected]
Oct. 23, 2026
Action Type Old Value New Value Added Translation Title: rekor de sigstore, Description: Rekor es un registro de transparencia de la cadena de suministro de software. A partir de la versión 0.3.0 y antes de la versión 1.5.2, la función ’Package.Unmarshal()’ en ’pkg/types/alpine/apk.go’ descomprime los miembros gzip de firma y control de un archivo APK en búferes en memoria sin limitar el tamaño total descomprimido. La comprobación existente ’max_apk_metadata_size’ (predeterminado 1MB) solo se aplica a los tamaños de encabezado de entrada tar individuales después de que la descompresión se completa, por lo que no evita que una bomba de descompresión consuma memoria de montón ilimitada. Un atacante puede crear un flujo gzip que comprime con una relación de ~1000:1 (por ejemplo, 2MB de ceros comprimidos ? 2GB descomprimidos). Cuando se envía como spec.package.content en una ’ProposedEntry’ de Alpine, el servidor descomprime la carga útil completa en memoria durante el procesamiento de la solicitud, lo que desencadena un error fatal de falta de memoria del tiempo de ejecución de Go o un OOM-kill del sistema operativo que no puede ser capturado por el middleware recover() del servidor. Esto es accesible a través de dos puntos finales no autenticados, ’POST /api/v1/log/entries (createLogEntry)’ y ’POST /api/v1/log/entries/retrieve (searchLogQuery)’. Ambos invocan ’V001Entry.Canonicalize()’ ? ’fetchExternalEntities()’ ? ’apk.Unmarshal(packageData)’, que realiza la descompresión ilimitada. La versión 1.5.2 corrige el problema. No existe una solución alternativa efectiva. Establecer ’max_request_body_size’ reduce pero no elimina la exposición debido a la relación de compresión de ~1000:1 (un límite de cuerpo de 1MB aún permite una asignación de montón de ~1GB). Establecer ’max_apk_metadata_size’ no tiene efecto en esta vulnerabilidad ya que la comprobación se aplica después de la descompresión. -
CVE Modified by 134c704f-9b21-4f2e-91b3-4a467353bcc0
Aug. 13, 2026
Action Type Old Value New Value Added SSVC {'id': 'CVE-2026-48702', 'role': 'CISA Coordinator', 'options': [{'exploitation': 'none'}, {'automatable': 'yes'}, {'technicalImpact': 'partial'}], 'version': '2.0.3', 'timestamp': '2026-08-13T15:12:38.632066Z'} -
New CVE Received by [email protected]
Aug. 13, 2026
Action Type Old Value New Value Added Affected [{'vendor': 'sigstore', 'product': 'rekor', 'versions': [{'status': 'affected', 'version': '>= 0.3.0, < 1.5.2'}]}] Added Description 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 this vulnerability since the check is applied after decompression. Added CVSS V3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H Added CWE CWE-770 Added Reference https://github.com/sigstore/rekor/security/advisories/GHSA-47q9-m4ww-924m