Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The Package.Unmarshal() function in pkg/types/alpine/apk.go decompresses the signature and control gzip members of an APK file into in-memory buffers without bounding the total decompressed size. The existing maxapkmetadatasize check (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: - POST /api/v1/log/entries (createLogEntry) - POST /api/v1/log/entries/retrieve (searchLogQuery) Both invoke…
Recommended action: Upgrade to 1.5.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
/api/v1/index/retrieve supports retrieving a public key via a user-provided URL, allowing attackers to trigger SSRF to arbitrary internal services. Since the SSRF only can trigger GET requests, the request cannot mutate state. The response from the GET request is not returned to the caller so data exfiltration is not possible. A malicious actor could attempt to probe an internal network through Blind SSRF. Impact SSRF to cloud metadata (169.254.169.254) SSRF to internal Kubernetes APIs SSRF to any service accessible from Fulcio's network Patches Upgrade to v1.5.0. Note that this is a breaking change to the search API and fully disables lookups by URL. If you require this feature, please reach out and we can discuss alternatives. Workarounds Disable the search endpoint with --enableretrieveapi=false.
Recommended action: Upgrade to 1.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Rekor’s cose v0.0.1 entry implementation can panic on attacker-controlled input when canonicalizing a proposed entry with an empty spec.message. validate() returns nil (success) when message is empty, leaving sign1Msg uninitialized, and Canonicalize() later dereferences v.sign1Msg.Payload. Impact A malformed proposed entry of the cose/v0.0.1 type can cause a panic on a thread within the Rekor process. The thread is recovered so the client receives a 500 error message and service still continues, so the availability impact of this is minimal. Patches Upgrade to v1.5.0 Workarounds None
Recommended action: Upgrade to 1.5.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A malformed proposed entry of the intoto/v0.0.2 type can cause a panic on a thread within the Rekor process. The thread is recovered so the client receives a 500 error message and service still continues, so the availability impact of this is minimal. Patches This is fixed in v1.2.0 of Rekor. Workarounds No References Discovered by OSS-Fuzz
Recommended action: Upgrade to 1.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Two vulnerabilities have been found in Rekor types for archive files JARs and APKs, where Rekor would crash due to out of memory conditions caused by reading archive metadata files into memory without checking their sizes first causing a Denial of Service of Rekor. These vulnerabilities were found through fuzzing with OSS-Fuzz. Vulnerability 1: OOM due to large files in META-INF directory of JAR files. Summary Verification of a JAR file submitted to Rekor can cause an out of memory crash if files within the META-INF directory of the JAR are sufficiently large. Details As part of verifying a JAR file, Rekor uses the relic library to check that the JAR is signed, the signature verifies, and that the hashes in the signed manifest are all valid. This library function reads files within META-INF/ into memory without checking their sizes, resulting in an OOM if the uncompressed file is sufficiently large. Rekor is also not performing any such checks prior to passing the JAR to this…
Recommended action: Upgrade to 1.1.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.