Vulnerability-Lookup

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

Vulnerability from cvelistv5 – Published: 2026-08-13 13:14 – Updated: 2026-08-13 15:16

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 8035 records in the last 180 days details

References

1 reference

URL	Tags
https://github.com/sigstore/rekor/security/adviso…	x_refsource_CONFIRM

Impacted products

1 product

Vendor	Product	Version	CPE status
sigstore	rekor	Affected: >= 0.3.0, < 1.5.2	guessed

Show details on NVD website

JSON

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"
    }
  }
}

GHSA-47Q9-M4WW-924M

Vulnerability from github – Published: 2026-06-25 21:33 – Updated: 2026-06-25 21:33

Summary

Rekor has an OOM Condition due to Unbounded gzip Decompression in Alpine APK Parsing Logic

Details

Description

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.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Show details on source website

JSON

To clipboard

{
  "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"
}

OPENSUSE-SU-2026:11154-1

Vulnerability from csaf_opensuse - Published: 2026-06-30 00:00 - Updated: 2026-09-17 17:12

Summary

hauler-2.0.1-1.1 on GA media

Severity

Moderate

Scope

1 vulnerability in this advisory, including CVE-2026-48702.

CVE-2026-48702

7.5 (High)


                
                  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Recommended: 4 products

Open the full advisory

OPENSUSE-SU-2026:11398-1

Vulnerability from csaf_opensuse - Published: 2026-07-28 00:00 - Updated: 2026-09-17 17:17

Summary

tekton-cli-0.45.1-1.1 on GA media

Severity

Moderate

Scope

2 vulnerabilities in this advisory, including CVE-2026-48702.

CVE-2026-48702

7.5 (High)


                
                  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Recommended: 16 products

Open the full advisory

OPENSUSE-SU-2026:21262-1

Vulnerability from csaf_opensuse - Published: 2026-07-06 09:02 - Updated: 2026-09-17 17:38

Summary

Security update for hauler

Severity

Important

Scope

6 vulnerabilities in this advisory, including CVE-2026-48702.

CVE-2026-48702

7.5 (High)


                
                  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Recommended: 2 products

Open the full advisory

RHSA-2026:25138

Vulnerability from csaf_redhat - Published: 2026-06-10 21:27 - Updated: 2026-11-01 05:09

Summary

Red Hat Security Advisory: Red Hat Hardened Images RPMs bug fix and enhancement update

Severity

Important

Scope

3 vulnerabilities in this advisory, including CVE-2026-48702.

CVE-2026-48702

A flaw was found in Rekor. The `Package.Unmarshal()` function, which processes Alpine Package Keep (APK) files, decompresses gzip streams without limiting the total decompressed size. A remote attacker can exploit this by crafting a malicious APK file with a high compression ratio, causing the server to consume excessive memory. This leads to a Denial of Service (DoS) through an out-of-memory (OOM) error, and can be triggered via unauthenticated API endpoints.

7.5 (High)


                
                  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Fixed: 3 products

https://access.redhat.com/errata/RHSA-2026:25138

Open the full advisory

RHSA-2026:35111

Vulnerability from csaf_redhat - Published: 2026-07-02 23:34 - Updated: 2026-10-31 21:32

Summary

Red Hat Security Advisory: Red Hat Hardened Images RPMs Security Update

Severity

Important

Scope

8 vulnerabilities in this advisory, including CVE-2026-48702.

CVE-2026-48702

7.5 (High)


                
                  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Fixed: 3 products

https://access.redhat.com/errata/RHSA-2026:35111

Open the full advisory

RHSA-2026:50873

Vulnerability from csaf_redhat - Published: 2026-08-05 17:55 - Updated: 2026-10-31 05:43

Summary

Red Hat Security Advisory: RHTAS 1.4.3 - Red Hat Trusted Artifact Signer Release

Severity

Important

Scope

4 vulnerabilities in this advisory, including CVE-2026-48702.

CVE-2026-48702

7.5 (High)


                
                  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Fixed: 1 product Known not affected: 9 products

https://access.redhat.com/errata/RHSA-2026:50873

Open the full advisory

RHSA-2026:59439

Vulnerability from csaf_redhat - Published: 2026-08-25 13:53 - Updated: 2026-11-01 05:18

Summary

Red Hat Security Advisory: RHTAS 1.3.7 - Red Hat Trusted Artifact Signer Release

Severity

Important

Scope

5 vulnerabilities in this advisory, including CVE-2026-48702.

CVE-2026-48702

7.5 (High)


                
                  CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Fixed: 1 product Known not affected: 9 products

https://access.redhat.com/errata/RHSA-2026:59439

Open the full advisory

UBUNTU-CVE-2026-48702 (CVE-2026-48702)

Vulnerability from osv_ubuntu – Published: 2026-08-13 14:17 – Updated: 2026-08-19 11:05 – Source website

Details

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

N/A (UNKNOWN)


                    
                      medium

References

URL

Type

	https://ubuntu.com/security/CVE-2026-48702	REPORT
	https://www.cve.org/CVERecord?id=CVE-2026-48702	REPORT
	https://github.com/sigstore/rekor/pull/2831	REPORT

JSON

To clipboard

{
  "affected": [
    {
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "golang-github-sigstore-rekor-dev",
            "binary_version": "1.5.0-1ubuntu0.26.04.1~esm1"
          },
          {
            "binary_name": "rekor",
            "binary_version": "1.5.0-1ubuntu0.26.04.1~esm1"
          }
        ]
      },
      "package": {
        "ecosystem": "Ubuntu:Pro:26.04:LTS",
        "name": "rekor",
        "purl": "pkg:deb/ubuntu/rekor@1.5.0-1ubuntu0.26.04.1~esm1?arch=source\u0026distro=esm-apps/resolute"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "1.3.9-1",
        "1.5.0-1",
        "1.5.0-1ubuntu0.26.04.1~esm1"
      ]
    }
  ],
  "aliases": [],
  "details": "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.",
  "id": "UBUNTU-CVE-2026-48702",
  "modified": "2026-08-19T11:05:27Z",
  "published": "2026-08-13T14:17:00Z",
  "references": [
    {
      "type": "REPORT",
      "url": "https://ubuntu.com/security/CVE-2026-48702"
    },
    {
      "type": "REPORT",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-48702"
    },
    {
      "type": "REPORT",
      "url": "https://github.com/sigstore/rekor/pull/2831"
    }
  ],
  "related": [],
  "schema_version": "1.7.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"
    },
    {
      "score": "medium",
      "type": "Ubuntu"
    }
  ],
  "upstream": [
    "CVE-2026-48702"
  ]
}

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

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
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.

Action not permitted

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

Description

Workarounds

UBUNTU-CVE-2026-48702 (CVE-2026-48702)

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour