Update module github.com/sigstore/rekor to v1.5.2 [SECURITY] (release-v0.8)#3364
Conversation
|
|
🤖 Finished Review · ✅ Success · Started 9:02 PM UTC · Completed 9:09 PM UTC |
|
Looks good to me Low
Labels: PR is a Go dependency update addressing a security vulnerability. Previous runLooks good to me Previous run (2)Looks good to me Labels: Renovate bot dependency update for Go modules |
b0e172d to
1544905
Compare
|
🤖 Finished Review · ✅ Success · Started 11:06 AM UTC · Completed 11:13 AM UTC |
1544905 to
4243fdf
Compare
|
🤖 Finished Review · ✅ Success · Started 3:45 PM UTC · Completed 3:53 PM UTC |
| @@ -23,7 +23,7 @@ require ( | |||
| github.com/pkg/errors v0.9.1 | |||
| github.com/secure-systems-lab/go-securesystemslib v0.10.0 | |||
There was a problem hiding this comment.
[low] dependency version skew
The PR updates go-securesystemslib from v0.10.0 to v0.11.0 in go.mod but leaves it at v0.10.0 in acceptance/go.mod. The acceptance module directly imports the encrypted sub-package (acceptance/rekor/rekor.go:38). While Go's MVS will resolve the actual minimum required version transitively, and Renovate not bumping it suggests rekor v1.5.2 does not mandate v0.11.0 in the acceptance module graph, it is worth confirming.
Suggested fix: Run go mod tidy in the acceptance/ directory and verify no version changes are needed.
This PR contains the following updates:
v1.5.0→v1.5.2Rekor has an OOM Condition due to Unbounded gzip Decompression in Alpine APK Parsing Logic
CVE-2026-48702 / GHSA-47q9-m4ww-924m
More information
Details
Description
The
Package.Unmarshal()function inpkg/types/alpine/apk.godecompresses the signature and control gzip members of an APK file into in-memory buffers without bounding the total decompressed size. The existingmax_apk_metadata_sizecheck (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:
Both invoke
V001Entry.Canonicalize()→fetchExternalEntities()→apk.Unmarshal(packageData), which performs the unbounded decompression.Workarounds
There is no effective workaround. Setting
max_request_body_sizereduces but does not eliminate exposure due to the ~1000:1 compression ratio (a 1MB body limit still allows ~1GB heap allocation). Settingmax_apk_metadata_sizehas no effect on this vulnerability since the check is applied after decompression.Severity
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:HReferences
This data is provided by the GitHub Advisory Database (CC-BY 4.0).
Release Notes
sigstore/rekor (github.com/sigstore/rekor)
v1.5.2Compare Source
Changelog
759b98ealpine: Enforce max size limit on decompression (#2831)c7e77eeSupport restricting kinds on insertion (#2814)a10818afix(trillianclient): strip dns:/// scheme from TLS ServerName in gRPC dial (#2812)8a2f3a2add checks to ensure returned entries match client inputs to rekor-cli (#2799)0e88bacadd nil pointer check to resolve fuzzing crash (#2807)93da954client: surface last-response details after retries are exhausted (#2796)4d67ecdFix internal error detail leakage in 500 responses (#2801)b34ca94add defensive check to ensure tid is in config ahead of getting client (#2795)656c832restapi: include inactiveShards in the homepage total count (#2797)Thanks for all contributors!
v1.5.1Compare Source
Features
Bug Fixes
Configuration
📅 Schedule: (UTC)
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR is behind base branch, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR was generated by Mend Renovate. View the repository job log.