sigstore 関連製品全体の CVE とセキュリティ脆弱性情報を集約し、CVSS、EPSS、公開日、脆弱性情報データを掲載しています。
過去の問題は主に vendor risk denial of service などに関し、一部は アプリケーションクラッシュ を招き、vendor surface production workloads and vendor surface software deployment 関連の場面に影響します。
掲載データは公開脆弱性情報とセキュリティ公告に基づき、過去の暴露面と修補優先度の評価に利用できます。
| CVE | 概要 | ソース | CVSS 最大値 | EPSS（%） | 公開 | 更新 |
|---|---|---|---|---|---|---|
| CVE-2026-39395 | Cosign provides code signing and transparency for containers and binaries. Prior to 3.0.6 and 2.6.3, 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. This vulnerability is fixed in 3.0.6 a | [email protected] | 4.3 | 0.03% | 2026-04-07 | 2026-04-15 |
| CVE-2026-31830 | sigstore-ruby is a pure Ruby implementation of the sigstore verify command from the sigstore/cosign project. Prior to 0.2.3, Sigstore::Verifier#verify does not propagate the VerificationFailure returned by verify_in_toto when the artifact digest does not match the digest in the in-toto attestation subject. As a result, verification of DSSE bundles containing in-toto statements returns VerificationSuccess regardless of whether the artifact matches the attested subject. This vulnerability is fixed | [email protected] | 7.5 | 0.03% | 2026-03-10 | 2026-03-20 |
| CVE-2026-24122 | Cosign provides code signing and transparency for containers and binaries. In versions 3.0.4 and below, 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. 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 | [email protected] | 3.7 | 0.01% | 2026-02-19 | 2026-02-20 |
| CVE-2026-22703 | Cosign provides code signing and transparency for containers and binaries. Prior to versions 2.6.2 and 3.0.4, Cosign bundle can be crafted to successfully verify an artifact even if the embedded Rekor entry does not reference the artifact's digest, signature or public key. When verifying a Rekor entry, Cosign verifies the Rekor entry signature, and also compares the artifact's digest, the user's public key from either a Fulcio certificate or provided by the user, and the artifact signature to th | [email protected] | 5.5 | 0.00% | 2026-01-10 | 2026-02-05 |
| CVE-2024-45395 | sigstore-go, a Go library for Sigstore signing and verification, is susceptible to a denial of service attack in versions prior to 0.6.1 when a verifier is provided a maliciously crafted Sigstore Bundle containing large amounts of verifiable data, in the form of signed transparency log entries, RFC 3161 timestamps, and attestation subjects. The verification of these data structures is computationally expensive. This can be used to consume excessive CPU resources, leading to a denial of service a | [email protected] | 3.1 | 0.22% | 2024-09-04 | 2024-09-24 |
| CVE-2024-29903 | Cosign provides code signing and transparency for containers and binaries. Prior to version 2.2.4, maliciously-crafted software artifacts can cause denial of service of the machine running Cosign thereby impacting all services on the machine. The root cause is that Cosign creates slices based on the number of signatures, manifests or attestations in untrusted artifacts. As such, the untrusted artifact can control the amount of memory that Cosign allocates. The exact issue is Cosign allocates exc | [email protected] | 4.2 | 0.72% | 2024-04-10 | 2025-01-09 |
| CVE-2024-29902 | Cosign provides code signing and transparency for containers and binaries. Prior to version 2.2.4, a remote image with a malicious attachment can cause denial of service of the host machine running Cosign. This can impact other services on the machine that rely on having memory available such as a Redis database which can result in data loss. It can also impact the availability of other services on the machine that will not be available for the duration of the machine denial. The root cause of t | [email protected] | 4.2 | 0.21% | 2024-04-10 | 2025-01-09 |
| CVE-2023-47122 | Gitsign is software for keyless Git signing using Sigstore. In versions of gitsign starting with 0.6.0 and prior to 0.8.0, Rekor public keys were fetched via the Rekor API, instead of through the local TUF client. If the upstream Rekor server happened to be compromised, gitsign clients could potentially be tricked into trusting incorrect signatures. There is no known compromise the default public good instance (`rekor.sigstore.dev`) - anyone using this instance is unaffected. This issue was fixe | [email protected] | 4.2 | 0.09% | 2023-11-10 | 2024-11-21 |
| CVE-2023-46737 | Cosign is a sigstore signing tool for OCI containers. 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 ma | [email protected] | 3.1 | 0.31% | 2023-11-07 | 2024-11-21 |
| CVE-2022-36056 | Cosign is a project under the sigstore organization which aims to make signatures invisible infrastructure. In versions prior to 1.12.0 a number of vulnerabilities have been found in cosign verify-blob, where Cosign would successfully verify an artifact when verification should have failed. First a cosign bundle can be crafted to successfully verify a blob even if the embedded rekorBundle does not reference the given signature. Second, when providing identity flags, the email and issuer of a cer | [email protected] | 5.5 | 0.02% | 2022-09-14 | 2024-11-21 |
| CVE-2022-35930 | 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:dd7614b5a12bc4d617b223c588b4e0c833402b8f4991f | [email protected] | 7.1 | 0.24% | 2022-08-04 | 2024-11-21 |
| CVE-2022-35929 | 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 vulnerab | [email protected] | 7.1 | 0.20% | 2022-08-04 | 2024-11-21 |
| CVE-2022-23649 | 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 manipula | [email protected] | 3.3 | 0.02% | 2022-02-18 | 2024-11-21 |