https://db.gcve.eu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 18:19:10 +0000 https://db.gcve.eu/vuln/ghsa-whqx-f9j3-ch6m <p><strong>Affected:</strong> Go: github.com/sigstore/cosign/v3, Go: github.com/sigstore/cosign/v2</p> <p>### Impact</p> <p>A Cosign bundle can be crafted to successfully verify an artifact even if the embedded Rekor entry does not reference the artifact&#39;s digest, signature or public key. When verifying a Rekor entry, Cosign verifies the Rekor entry signature, and also compares the artifact&#39;s digest, the user&#39;s public key from either a Fulcio certificate or provided by the user, and the artifact signature to the Rekor entry contents. Without these comparisons, Cosign would accept any response from Rekor as valid. A malicious actor that has compromised a user&#39;s identity or signing key could construct a valid Cosign bundle by including any arbitrary Rekor entry, thus preventing the user from being able to audit the signing event.</p> <p>This vulnerability only affects users that provide a trusted root via `--trusted-root` or when fetched automatically from a TUF repository, when no trusted key material is provided via `SIGSTORE_REKOR_PUBLIC_KEY`. When using the default flag values in Cosign v3 to sign and verify (`--use-signing-config=true` and `--new-bundle-format=true` for signing, `--new-bundle-format=true` for verification), users are unaffected. Cosign v2 users are affected using the default flag values.</p> <p>This issue had previously been fixed in https://github.com/sigstore/cosign/security/advisories/GHSA-8gw7-4j42-w388 but recent refactoring caused a regression. We have added testing to prevent a future regression.</p> <p>#### Steps to Reproduce</p> <p>``` echo blob &gt; /tmp/blob cosign sign-blob -y --…</p> <p><strong>Affected:</strong> Go: github.com/sigstore/cosign/v3, Go: github.com/sigstore/cosign/v2</p> <p>### Impact</p> <p>A Cosign bundle can be crafted to successfully verify an artifact even if the embedded Rekor entry does not reference the artifact&#39;s digest, signature or public key. When verifying a Rekor entry, Cosign verifies the Rekor entry signature, and also compares the artifact&#39;s digest, the user&#39;s public key from either a Fulcio certificate or provided by the user, and the artifact signature to the Rekor entry contents. Without these comparisons, Cosign would accept any response from Rekor as valid. A malicious actor that has compromised a user&#39;s identity or signing key could construct a valid Cosign bundle by including any arbitrary Rekor entry, thus preventing the user from being able to audit the signing event.</p> <p>This vulnerability only affects users that provide a trusted root via `--trusted-root` or when fetched automatically from a TUF repository, when no trusted key material is provided via `SIGSTORE_REKOR_PUBLIC_KEY`. When using the default flag values in Cosign v3 to sign and verify (`--use-signing-config=true` and `--new-bundle-format=true` for signing, `--new-bundle-format=true` for verification), users are unaffected. Cosign v2 users are affected using the default flag values.</p> <p>This issue had previously been fixed in https://github.com/sigstore/cosign/security/advisories/GHSA-8gw7-4j42-w388 but recent refactoring caused a regression. We have added testing to prevent a future regression.</p> <p>#### Steps to Reproduce</p> <p>``` echo blob &gt; /tmp/blob cosign sign-blob -y --…</p> https://db.gcve.eu/vuln/ghsa-whqx-f9j3-ch6m