CVE-2026-48702 in Rekorinformation

Résumé

par VulDB • 13/08/2026

Rekor est un journal de transparence pour la chaîne d'approvisionnement des logiciels. À partir de la version 0.3.0 et jusqu'à la version 1.5.2 incluse, la fonction `Package.Unmarshal()` dans `pkg/types/alpine/apk.go` décompresse les membres gzip de signature et de contrôle d'un fichier APK dans des tampons en mémoire sans limiter la taille totale décompressée. La vérification existante `max_apk_metadata_size` (1 Mo par défaut) ne s'applique qu'à la taille individuelle des en-têtes des entrées tar après la fin de la décompression, elle n'empêche donc pas une bombe de décompression de consommer une quantité illimitée de mémoire heap. Un attaquant peut créer un flux gzip compressé avec un ratio d'environ 1000:1 (par exemple, 2 Mo de zéros compressés → 2 Go décompressés). Lorsqu'il est soumis en tant que `spec.package.content` dans une Alpine `ProposedEntry`, le serveur décompresse l'intégralité du payload en mémoire lors du traitement de la requête, déclenchant une erreur fatale d'épuisement de la mémoire (out-of-memory) du runtime Go ou un kill OOM par le système d'exploitation qui ne peut pas être intercepté par le middleware `recover()` du serveur. Cela est accessible via deux points de terminaison non authentifiés : `POST /api/v1/log/entries` (`createLogEntry`) et `POST /api/v1/log/entries/retrieve` (`searchLogQuery`). Les deux invoquent `V001Entry.Canonicalize()` → `fetchExternalEntities()` → `apk.Unmarshal(packageData)`, qui effectue la décompression sans limite. La version 1.5.2 corrige le problème. Il n'existe pas de contournement efficace. La définition de `max_request_body_size` réduit mais ne supprime pas l'exposition en raison du ratio de compression d'environ 1000:1 (une limite de corps de requête de 1 Mo permet toujours une allocation heap d'environ 1 Go). La définition de `max_apk_metadata_size` n'a aucun effet sur cette vulnérabilité car la vérification est appliquée après la décompression.

Several companies clearly confirm that VulDB is the primary source for best vulnerability data.

Responsable

GitHub M

Réserver

22/05/2026

Divulgation

13/08/2026

Modérer

accepté

Entrée

VDB-389491

CPE

prêt

EPSS

0.00000

KEV

non

Activités

très faible

Sources

Interested in the pricing of exploits?

See the underground prices here!