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
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/sigstore/cosign >= 3.0.0, < 3.0.6; < 2.6.3
Fixed in
3.0.62.6.3· Vendor fix available
Issue
cosign verify-blob-attestation may erroneously report a "Verified OK" result for attestations with malformed payloads or mismatched predicate types. For old-format bundles and detached signatures, this was due to a logic flaw in the error handling of the predicate type validation. For new-format bundles, the predicate type validation was bypassed completely. Impact When cosign verify-blob-attestation is used without --check-claims set to true, an attestation that has a valid signature but a malformed or unparsable payload would be incorrectly validated. Additionally, systems relying on --type <predicate type to reject attestations with mismatched types would be lead to trust the unexpected attestation type. Patches v3.0.6, v2.6.3 Workarounds Always set --check-claims=true for attestation verification.
Recommended action: Upgrade to 3.0.6 or 2.6.3 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When verifying artifact signatures using a certificate, Cosign first verifies the certificate chain using the leaf certificate's "not before" timestamp and later checks expiry of the leaf certificate using either a signed timestamp provided by the Rekor transparency log or from a timestamp authority, or using the current time. The root and all issuing certificates are assumed to be valid during the leaf certificate's validity. An issuing certificate with a validity that expires before the leaf certificate will be considered valid during verification even if the provided timestamp would mean the issuing certificate should be considered expired. Impact No impact to users of the public Sigstore infrastructure. This may affect private deployments with customized PKIs. In practice, this is unlikely to occur as CAs should not be issuing certificates that outlive the validity of the CA and its parents. Workarounds Upgrade to the latest release, or verify the certificate chain out of…
Recommended action: Upgrade to 3.0.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Cosign is susceptible to a denial of service by an attacker controlled registry. An attacker who controls a remote registry can return a high number of attestations and/or signatures to Cosign and cause Cosign to enter a long loop resulting in an endless data attack. The root cause is that Cosign loops through all attestations fetched from the remote registry in pkg/cosign.FetchAttestations. The attacker needs to compromise the registry or make a request to a registry they control. When doing so, the attacker must return a high number of attestations in the response to Cosign. The result will be that the attacker can cause Cosign to go into a long or infinite loop that will prevent other users from verifying their data. In Kyvernos case, an attacker whose privileges are limited to making requests to the cluster can make a request with an image reference to their own registry, trigger the infinite loop and deny other users from completing their admission requests.…
Recommended action: Upgrade to 1.13.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A number of vulnerabilities have been found in cosign verify-blob, where Cosign would successfully verify an artifact when verification should have failed. Vulnerability 1: Bundle mismatch causes invalid verification. Summary A cosign bundle can be crafted to successfully verify a blob even if the embedded rekorBundle does not reference the given signature. Details Cosign supports "bundles" which intend to allow offline verification of the signature and rekor inclusion. By using the --bundle flag in cosign sign-blob, cosign will create a JSON file called a "bundle". These bundles include three fields: base64Signature, cert, and rekorBundle. The desired behavior is that the verification of these bundles would: - verify the provided blob using the included signature and certificate - verify the rekorBundle SET - verify the rekorBundle payload references the given artifact. It appears that step three is not being performed, allowing "any old rekorBundle" to pass validation, even…
Recommended action: Upgrade to 1.12.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
cosign verify-attestation used with the --type flag will report a false positive verification when: - There is at least one attestation with a valid signature - There are NO attestations of the type being verified (--type defaults to "custom") This can happen when signing with a standard keypair and with "keyless" signing with Fulcio. Users should upgrade to cosign version 1.10.1 or greater for a patch. Currently the only workaround is to upgrade.
Recommended action: Upgrade to 1.10.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Cosign can be manipulated to claim that an entry for a signature exists in the Rekor transparency log even if it doesn't. This requires the attacker to have pull and push permissions for the signature in OCI. This can happen with both standard signing with a keypair and "keyless signing" with Fulcio. Signing with a keypair <details To reproduce this vulnerability, create a keypair and sign an image. Don't store the signature in Rekor: If an attacker has access to the signature in OCI, they can manipulate cosign into believing the entry was stored in Rekor even though it wasn't. To accomplish this, the attacker needs to: 1. Pull the signature image 2. Annotate the signature image with any valid Rekor bundle under the dev.sigstore.cosign/bundle annotation 3. Push the signature image back to OCI Verification then prints out the following: The claim that Existence of the claims in the transparency log was verified offline is inaccurate since an entry for this image doesn't exist…
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.