CVE-2026-48702

{
  "id": "CVE-2026-48702",
  "sourceIdentifier": "[email protected]",
  "published": "2026-08-13T14:17:01.427",
  "lastModified": "2026-10-23T18:10:00.167",
  "vulnStatus": "Awaiting Analysis",
  "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 → 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."
    },
    {
      "lang": "es",
      "value": "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."
    }
  ],
  "affected": [
    {
      "source": "[email protected]",
      "affectedData": [
        {
          "vendor": "sigstore",
          "product": "rekor",
          "versions": [
            {
              "version": ">= 0.3.0, < 1.5.2",
              "status": "affected"
            }
          ]
        }
      ]
    }
  ],
  "metrics": {
    "cvssMetricV31": [
      {
        "source": "[email protected]",
        "type": "Secondary",
        "cvssData": {
          "version": "3.1",
          "vectorString": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
          "baseScore": 7.5,
          "baseSeverity": "HIGH",
          "attackVector": "NETWORK",
          "attackComplexity": "LOW",
          "privilegesRequired": "NONE",
          "userInteraction": "NONE",
          "scope": "UNCHANGED",
          "confidentialityImpact": "NONE",
          "integrityImpact": "NONE",
          "availabilityImpact": "HIGH"
        },
        "exploitabilityScore": 3.9,
        "impactScore": 3.6
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "timestamp": "2026-08-13T15:12:38.632066Z",
          "id": "CVE-2026-48702",
          "options": [
            {
              "exploitation": "none"
            },
            {
              "automatable": "yes"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "version": "2.0.3"
        }
      }
    ]
  },
  "weaknesses": [
    {
      "source": "[email protected]",
      "type": "Secondary",
      "description": [
        {
          "lang": "en",
          "value": "CWE-770"
        }
      ]
    }
  ],
  "references": [
    {
      "url": "https://github.com/sigstore/rekor/security/advisories/GHSA-47q9-m4ww-924m",
      "source": "[email protected]"
    }
  ]
}