CVE-2026-48702 (GCVE-0-2026-48702)

Vulnerability from cvelistv5 – Published: 2026-08-13 13:14 – Updated: 2026-08-13 15:16
VLAI
Title
Rekor has an OOM Condition due to Unbounded gzip Decompression in Alpine APK Parsing Logic
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 this vulnerability since the check is applied after decompression.
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
SSVC
Exploitation: none Automatable: yes Technical Impact: partial
CISA Coordinator · CISA-ADP (v2.0.3)
Decision recorded 2026-08-13 15:12 UTC
CWE
  • CWE-770 - Allocation of Resources Without Limits or Throttling
Assigner
GitHub_M CNA under the mitre root
CNA scorecard C 72/100 over 8016 records in the last 180 days details
References
Impacted products
Vendor Product Version CPE status
sigstore rekor Affected: >= 0.3.0, < 1.5.2
guessed Create a notification for this product.
Show details on NVD website
To clipboard 

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-48702",
                "options": [
                  {
                    "Exploitation": "none"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-08-13T15:12:38.632066Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-08-13T15:16:26.293Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "rekor",
          "vendor": "sigstore",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 0.3.0, \u003c 1.5.2"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "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 \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. 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()` \u2192 `fetchExternalEntities()` \u2192 `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."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "NETWORK",
            "availabilityImpact": "HIGH",
            "baseScore": 7.5,
            "baseSeverity": "HIGH",
            "confidentialityImpact": "NONE",
            "integrityImpact": "NONE",
            "privilegesRequired": "NONE",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-770",
              "description": "CWE-770: Allocation of Resources Without Limits or Throttling",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-08-13T13:14:19.324Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/sigstore/rekor/security/advisories/GHSA-47q9-m4ww-924m",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/sigstore/rekor/security/advisories/GHSA-47q9-m4ww-924m"
        }
      ],
      "source": {
        "advisory": "GHSA-47q9-m4ww-924m",
        "discovery": "UNKNOWN"
      },
      "title": "Rekor has an OOM Condition due to Unbounded gzip Decompression in Alpine APK Parsing Logic"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-48702",
    "datePublished": "2026-08-13T13:14:19.324Z",
    "dateReserved": "2026-05-22T18:47:27.754Z",
    "dateUpdated": "2026-08-13T15:16:26.293Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2",
  "vulnerability-lookup:meta": {
    "epss": {
      "cve": "CVE-2026-48702",
      "date": "2026-11-02",
      "epss": "0.0046",
      "percentile": "0.3988"
    },
    "nvd": {
      "cve": {
        "affected": [
          {
            "affectedData": [
              {
                "product": "rekor",
                "vendor": "sigstore",
                "versions": [
                  {
                    "status": "affected",
                    "version": "\u003e= 0.3.0, \u003c 1.5.2"
                  }
                ]
              }
            ],
            "source": "security-advisories@github.com"
          }
        ],
        "cveTags": [],
        "descriptions": [
          {
            "lang": "en",
            "value": "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 \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. 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()` \u2192 `fetchExternalEntities()` \u2192 `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."
          },
          {
            "lang": "es",
            "value": "Rekor es un registro de transparencia de la cadena de suministro de software. A partir de la versi\u00f3n 0.3.0 y antes de la versi\u00f3n 1.5.2, la funci\u00f3n \u2019Package.Unmarshal()\u2019 en \u2019pkg/types/alpine/apk.go\u2019 descomprime los miembros gzip de firma y control de un archivo APK en b\u00faferes en memoria sin limitar el tama\u00f1o total descomprimido. La comprobaci\u00f3n existente \u2019max_apk_metadata_size\u2019 (predeterminado 1MB) solo se aplica a los tama\u00f1os de encabezado de entrada tar individuales despu\u00e9s de que la descompresi\u00f3n se completa, por lo que no evita que una bomba de descompresi\u00f3n consuma memoria de mont\u00f3n ilimitada. Un atacante puede crear un flujo gzip que comprime con una relaci\u00f3n de ~1000:1 (por ejemplo, 2MB de ceros comprimidos ? 2GB descomprimidos). Cuando se env\u00eda como spec.package.content en una \u2019ProposedEntry\u2019 de Alpine, el servidor descomprime la carga \u00fatil completa en memoria durante el procesamiento de la solicitud, lo que desencadena un error fatal de falta de memoria del tiempo de ejecuci\u00f3n 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\u00e9s de dos puntos finales no autenticados, \u2019POST /api/v1/log/entries (createLogEntry)\u2019 y \u2019POST /api/v1/log/entries/retrieve (searchLogQuery)\u2019. Ambos invocan \u2019V001Entry.Canonicalize()\u2019 ? \u2019fetchExternalEntities()\u2019 ? \u2019apk.Unmarshal(packageData)\u2019, que realiza la descompresi\u00f3n ilimitada. La versi\u00f3n 1.5.2 corrige el problema. No existe una soluci\u00f3n alternativa efectiva. Establecer \u2019max_request_body_size\u2019 reduce pero no elimina la exposici\u00f3n debido a la relaci\u00f3n de compresi\u00f3n de ~1000:1 (un l\u00edmite de cuerpo de 1MB a\u00fan permite una asignaci\u00f3n de mont\u00f3n de ~1GB). Establecer \u2019max_apk_metadata_size\u2019 no tiene efecto en esta vulnerabilidad ya que la comprobaci\u00f3n se aplica despu\u00e9s de la descompresi\u00f3n."
          }
        ],
        "id": "CVE-2026-48702",
        "lastModified": "2026-10-23T18:10:00.167",
        "metrics": {
          "cvssMetricV31": [
            {
              "cvssData": {
                "attackComplexity": "LOW",
                "attackVector": "NETWORK",
                "availabilityImpact": "HIGH",
                "baseScore": 7.5,
                "baseSeverity": "HIGH",
                "confidentialityImpact": "NONE",
                "integrityImpact": "NONE",
                "privilegesRequired": "NONE",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
                "version": "3.1"
              },
              "exploitabilityScore": 3.9,
              "impactScore": 3.6,
              "source": "security-advisories@github.com",
              "type": "Secondary"
            }
          ],
          "ssvcV203": [
            {
              "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "ssvcData": {
                "id": "CVE-2026-48702",
                "options": [
                  {
                    "exploitation": "none"
                  },
                  {
                    "automatable": "yes"
                  },
                  {
                    "technicalImpact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-08-13T15:12:38.632066Z",
                "version": "2.0.3"
              }
            }
          ]
        },
        "published": "2026-08-13T14:17:01.427",
        "references": [
          {
            "source": "security-advisories@github.com",
            "url": "https://github.com/sigstore/rekor/security/advisories/GHSA-47q9-m4ww-924m"
          }
        ],
        "sourceIdentifier": "security-advisories@github.com",
        "vulnStatus": "Awaiting Analysis",
        "weaknesses": [
          {
            "description": [
              {
                "lang": "en",
                "value": "CWE-770"
              }
            ],
            "source": "security-advisories@github.com",
            "type": "Secondary"
          }
        ]
      }
    },
    "redhat_vex": {
      "aggregate_severity": "Important",
      "current_release_date": "2026-10-30T05:20:39+00:00",
      "cve": "CVE-2026-48702",
      "id": "CVE-2026-48702",
      "initial_release_date": "2026-06-25T21:33:36+00:00",
      "product_status:fixed": "8",
      "product_status:known_affected": "2",
      "product_status:known_not_affected": "187",
      "source": "Red Hat CSAF VEX",
      "status": "final",
      "title": "github.com/sigstore/rekor: Rekor: Denial of Service due to unbounded gzip decompression in Alpine APK parsing",
      "url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-48702.json",
      "version": "3"
    },
    "vulnrichment": {
      "containers": {
        "adp": [
          {
            "metrics": [
              {
                "other": {
                  "content": {
                    "id": "CVE-2026-48702",
                    "options": [
                      {
                        "Exploitation": "none"
                      },
                      {
                        "Automatable": "yes"
                      },
                      {
                        "Technical Impact": "partial"
                      }
                    ],
                    "role": "CISA Coordinator",
                    "timestamp": "2026-08-13T15:12:38.632066Z",
                    "version": "2.0.3"
                  },
                  "type": "ssvc"
                }
              }
            ],
            "providerMetadata": {
              "dateUpdated": "2026-08-13T15:15:33.515Z",
              "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
              "shortName": "CISA-ADP"
            },
            "title": "CISA ADP Vulnrichment"
          }
        ],
        "cna": {
          "affected": [
            {
              "product": "rekor",
              "vendor": "sigstore",
              "versions": [
                {
                  "status": "affected",
                  "version": "\u003e= 0.3.0, \u003c 1.5.2"
                }
              ]
            }
          ],
          "descriptions": [
            {
              "lang": "en",
              "value": "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 \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. 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()` \u2192 `fetchExternalEntities()` \u2192 `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."
            }
          ],
          "metrics": [
            {
              "cvssV3_1": {
                "attackComplexity": "LOW",
                "attackVector": "NETWORK",
                "availabilityImpact": "HIGH",
                "baseScore": 7.5,
                "baseSeverity": "HIGH",
                "confidentialityImpact": "NONE",
                "integrityImpact": "NONE",
                "privilegesRequired": "NONE",
                "scope": "UNCHANGED",
                "userInteraction": "NONE",
                "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
                "version": "3.1"
              }
            }
          ],
          "problemTypes": [
            {
              "descriptions": [
                {
                  "cweId": "CWE-770",
                  "description": "CWE-770: Allocation of Resources Without Limits or Throttling",
                  "lang": "en",
                  "type": "CWE"
                }
              ]
            }
          ],
          "providerMetadata": {
            "dateUpdated": "2026-08-13T13:14:19.324Z",
            "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
            "shortName": "GitHub_M"
          },
          "references": [
            {
              "name": "https://github.com/sigstore/rekor/security/advisories/GHSA-47q9-m4ww-924m",
              "tags": [
                "x_refsource_CONFIRM"
              ],
              "url": "https://github.com/sigstore/rekor/security/advisories/GHSA-47q9-m4ww-924m"
            }
          ],
          "source": {
            "advisory": "GHSA-47q9-m4ww-924m",
            "discovery": "UNKNOWN"
          },
          "title": "Rekor has an OOM Condition due to Unbounded gzip Decompression in Alpine APK Parsing Logic"
        }
      },
      "cveMetadata": {
        "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "assignerShortName": "GitHub_M",
        "cveId": "CVE-2026-48702",
        "datePublished": "2026-08-13T13:14:19.324Z",
        "dateReserved": "2026-05-22T18:47:27.754Z",
        "dateUpdated": "2026-08-13T15:16:26.293Z",
        "state": "PUBLISHED"
      },
      "dataType": "CVE_RECORD",
      "dataVersion": "5.2"
    }
  }
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

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.
Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

JSON

Loading timeline…




    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.