Page 3 of 13 results (0.004 seconds)

CVSS: 8.8EPSS: 0%CPEs: 1EXPL: 0

PolicyController is a utility used to enforce supply chain policy in Kubernetes clusters. In versions prior to 0.2.1 PolicyController will report a false positive, resulting in an admission when it should not be admitted when there is at least one attestation with a valid signature and there are NO attestations of the type being verified (--type defaults to "custom"). An example image that can be used to test this is `ghcr.io/distroless/static@sha256:dd7614b5a12bc4d617b223c588b4e0c833402b8f4991fb5702ea83afad1986e2`. Users should upgrade to version 0.2.1 to resolve this issue. There are no workarounds for users unable to upgrade. • https://github.com/sigstore/policy-controller/commit/e852af36fb7d42678b21d7e97503c25bd1fd05c8 https://github.com/sigstore/policy-controller/releases/tag/v0.2.1 https://github.com/sigstore/policy-controller/security/advisories/GHSA-739f-hw6h-7wq8 • CWE-347: Improper Verification of Cryptographic Signature •

CVSS: 9.8EPSS: 0%CPEs: 1EXPL: 2

cosign is a container signing and verification utility. In versions prior to 1.10.1 cosign can report a false positive if any attestation exists. `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 and 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. This vulnerability can be reproduced with the `distroless.dev/static@sha256:dd7614b5a12bc4d617b223c588b4e0c833402b8f4991fb5702ea83afad1986e2` image. • https://github.com/sigstore/cosign/commit/c5fda01a8ff33ca981f45a9f13e7fb6bd2080b94 https://github.com/sigstore/cosign/security/advisories/GHSA-vjxv-45g9-9296 • CWE-347: Improper Verification of Cryptographic Signature •

CVSS: 3.3EPSS: 0%CPEs: 1EXPL: 0

Cosign provides container signing, verification, and storage in an OCI registry for the sigstore project. Prior to version 1.5.2, 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. 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. • https://github.com/sigstore/cosign/commit/96d410a6580e4e81d24d112a0855c70ca3fb5b49 https://github.com/sigstore/cosign/security/advisories/GHSA-ccxc-vr6p-4858 • CWE-295: Improper Certificate Validation •