CVE-2026-48702 in Rekor
Zusammenfassung
von VulDB • 13.08.2026
Rekor ist ein Transparenzprotokoll für die Software-Lieferkette. Ab Version 0.3.0 und vor Version 1.5.2 dekomprimiert die Funktion `Package.Unmarshal()` in `pkg/types/alpine/apk.go` die signierten und Steuerungs-Gzip-Elemente einer APK-Datei in Pufferspeicher im Arbeitsspeicher, ohne die gesamte dekomprimierte Größe zu begrenzen. Die vorhandene Prüfung auf `max_apk_metadata_size` (Standardwert 1 MB) wird erst nach Abschluss der Dekompression für die Header-Größen einzelner Tar-Einträge angewendet und verhindert daher nicht, dass ein „Decompression Bomb“ unbegrenzten Heap-Speicher verbraucht. Ein Angreifer kann einen Gzip-Stream erstellen, der mit einem Verhältnis von ca. 1000:1 komprimiert (z. B. 2 MB komprimierte Nullbytes → 2 GB dekomprimiert). Wenn dieser als `spec.package.content` in einem Alpine `ProposedEntry` übermittelt wird, dekomprimiert der Server die gesamte Nutzlast während der Verarbeitung der Anfrage in den Arbeitsspeicher und löst einen fatalen Out-of-Memory-Fehler des Go-Laufzeitsystems oder eine OOM-Kill-Aktion durch das Betriebssystem aus, die vom `recover()`-Middleware des Servers nicht abgefangen werden kann. Dies ist über zwei unauthentifizierte Endpunkte erreichbar: `POST /api/v1/log/entries (createLogEntry)` und `POST /api/v1/log/entries/retrieve (searchLogQuery)`. Beide rufen `V001Entry.Canonicalize()` → `fetchExternalEntities()` → `apk.Unmarshal(packageData)` auf, was die unbegrenzte Dekomprimierung durchführt. Version 1.5.2 behebt das Problem. Es gibt keinen wirksamen Workaround. Das Festlegen von `max_request_body_size` reduziert zwar, beseitigt aber nicht die Angriffsfläche aufgrund des Kompressionsverhältnisses von ca. 1000:1 (ein Limit für den Body von 1 MB ermöglicht weiterhin eine Heap-Allokation von ~1 GB). Das Festlegen von `max_apk_metadata_size` hat auf diese Schwachstelle keinen Einfluss, da die Prüfung erst nach der Dekomprimierung angewendet wird.
Once again VulDB remains the best source for vulnerability data.