CVE-2026-48702 in Rekor
摘要
由 VulDB • 2026-08-13
Rekor 是一个软件供应链透明度日志。从版本 0.3.0 开始至版本 1.5.2（不含）之前，`pkg/types/alpine/apk.go` 中的 `Package.Unmarshal()` 函数会将 APK 文件的签名和控制 gzip 成员解压到内存缓冲区中，但未限制总解压大小。现有的 `max_apk_metadata_size` 检查项（默认值为 1MB）仅在解压完成后应用于各个 tar 条目头的大小，因此无法防止“解压缩炸弹”消耗无限制的堆内存。攻击者可以构造一个压缩比约为 1000:1 的 gzip 流（例如：2MB 压缩后的零数据 → 2GB 解压后数据）。当作为 Alpine `ProposedEntry` 中的 spec.package.content 提交时，服务器在处理请求期间会将整个有效载荷解压到内存中，触发致命的 Go 运行时内存不足错误或被操作系统 OOM-kill，且服务器的 recover() 中间件无法捕获此异常。该漏洞可通过两个未认证端点访问：`POST /api/v1/log/entries (createLogEntry)` 和 `POST /api/v1/log/entries/retrieve (searchLogQuery)`。两者均会调用 `V001Entry.Canonicalize()` → `fetchExternalEntities()` → `apk.Unmarshal(packageData)`，从而执行无限制的解压操作。版本 1.5.2 已修补此问题。没有有效的变通方法。设置 `max_request_body_size` 只能减少但不能消除暴露风险，因为压缩比约为 1000:1（即 1MB 的请求体限制仍允许分配约 1GB 的堆内存）。由于检查是在解压后应用的，因此设置 `max_apk_metadata_size` 对此漏洞无效。
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.