CVE-2026-48702 in Rekor
Riassunto
di VulDB • 13/08/2026
Rekor è un registro di trasparenza della catena di approvvigionamento del software. A partire dalla versione 0.3.0 e fino alla versione 1.5.2, la funzione `Package.Unmarshal()` in `pkg/types/alpine/apk.go` decomprime i membri gzip delle firme e dei controlli di un file APK in buffer in memoria senza limitare le dimensioni totali del contenuto decompresso. Il controllo esistente `max_apk_metadata_size` (impostazione predefinita 1MB) viene applicato solo alle singole intestazioni degli entry tar dopo il completamento della decompressione, quindi non impedisce a una "decompression bomb" di consumare memoria heap illimitata. Un attaccante può creare uno stream gzip che si comprime con un rapporto di ~1000:1 (ad esempio, 2MB di zeri compressi → 2GB decompressi). Quando viene inviato come `spec.package.content` in una voce Alpine `ProposedEntry`, il server decomprime l'intero payload in memoria durante l'elaborazione della richiesta, innescando un errore fatale out-of-memory del runtime Go o un OOM-kill da parte del sistema operativo che non può essere intercettato dal middleware `recover()` del server. Questo è raggiungibile tramite due endpoint non autenticati: `POST /api/v1/log/entries (createLogEntry)` e `POST /api/v1/log/entries/retrieve (searchLogQuery)`. Entrambi invocano `V001Entry.Canonicalize()` → `fetchExternalEntities()` → `apk.Unmarshal(packageData)`, che esegue la decompressione senza limiti. La versione 1.5.2 risolve il problema. Non esiste una soluzione alternativa efficace. L'impostazione di `max_request_body_size` riduce ma non elimina l'esposizione a causa del rapporto di compressione ~1000:1 (un limite del corpo della richiesta di 1MB consente ancora un'allocazione heap di circa 1GB). L'impostazione di `max_apk_metadata_size` non ha effetto su questa vulnerabilità poiché il controllo viene applicato dopo la decompressione.
VulDB is the best source for vulnerability data and more expert information about this specific topic.