https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 06:30:05 +0000 https://cve.radiocsirt.org/vuln/brew-sigstore-cve-2024-55655 <p><strong>Affected:</strong> Homebrew: sigstore</p> <p>sigstore-python is a Python tool for generating and verifying Sigstore signatures. Versions of sigstore-python newer than 2.0.0 but prior to 3.6.0 perform insufficient validation of the &#34;integration time&#34; present in &#34;v2&#34; and &#34;v3&#34; bundles during the verification flow: the &#34;integration time&#34; is verified *if* a source of signed time (such as an inclusion promise) is present, but is otherwise trusted if no source of signed time is present. This does not affect &#34;v1&#34; bundles, as the &#34;v1&#34; bundle format always requires an inclusion promise.</p> <p>Sigstore uses signed time to support verification of signatures made against short-lived signing keys. The impact and severity of this weakness is *low*, as Sigstore contains multiple other enforcing components that prevent an attacker who modifies the integration timestamp within a bundle from impersonating a valid signature. In particular, an attacker who modifies the integration timestamp can induce a Denial of Service, but in no different manner than already possible with bundle access (e.g. modifying the signature itself such that it fails to verify). Separately, an attacker could upload a *new* entry to the transparency service, and substitute their new entry&#39;s time. However, this would still be rejected at validation time, as the new entry&#39;s (valid) signed time would be outside the validity window of the original signing certificate and would nonetheless render the attacker auditable.</p> <p><strong>Affected:</strong> Homebrew: sigstore</p> <p>sigstore-python is a Python tool for generating and verifying Sigstore signatures. Versions of sigstore-python newer than 2.0.0 but prior to 3.6.0 perform insufficient validation of the &#34;integration time&#34; present in &#34;v2&#34; and &#34;v3&#34; bundles during the verification flow: the &#34;integration time&#34; is verified *if* a source of signed time (such as an inclusion promise) is present, but is otherwise trusted if no source of signed time is present. This does not affect &#34;v1&#34; bundles, as the &#34;v1&#34; bundle format always requires an inclusion promise.</p> <p>Sigstore uses signed time to support verification of signatures made against short-lived signing keys. The impact and severity of this weakness is *low*, as Sigstore contains multiple other enforcing components that prevent an attacker who modifies the integration timestamp within a bundle from impersonating a valid signature. In particular, an attacker who modifies the integration timestamp can induce a Denial of Service, but in no different manner than already possible with bundle access (e.g. modifying the signature itself such that it fails to verify). Separately, an attacker could upload a *new* entry to the transparency service, and substitute their new entry&#39;s time. However, this would still be rejected at validation time, as the new entry&#39;s (valid) signed time would be outside the validity window of the original signing certificate and would nonetheless render the attacker auditable.</p> https://cve.radiocsirt.org/vuln/brew-sigstore-cve-2024-55655 https://cve.radiocsirt.org/vuln/euvd-2026-206779 EUVD-2026-206779 https://cve.radiocsirt.org/vuln/euvd-2026-206779 https://cve.radiocsirt.org/vuln/fkie_cve-2024-55655 <p>sigstore-python is a Python tool for generating and verifying Sigstore signatures. Versions of sigstore-python newer than 2.0.0 but prior to 3.6.0 perform insufficient validation of the &#34;integration time&#34; present in &#34;v2&#34; and &#34;v3&#34; bundles during the verification flow: the &#34;integration time&#34; is verified *if* a source of signed time (such as an inclusion promise) is present, but is otherwise trusted if no source of signed time is present. This does not affect &#34;v1&#34; bundles, as the &#34;v1&#34; bundle format always requires an inclusion promise.</p> <p>Sigstore uses signed time to support verification of signatures made against short-lived signing keys. The impact and severity of this weakness is *low*, as Sigstore contains multiple other enforcing components that prevent an attacker who modifies the integration timestamp within a bundle from impersonating a valid signature. In particular, an attacker who modifies the integration timestamp can induce a Denial of Service, but in no different manner than already possible with bundle access (e.g. modifying the signature itself such that it fails to verify). Separately, an attacker could upload a *new* entry to the transparency service, and substitute their new entry&#39;s time. However, this would still be rejected at validation time, as the new entry&#39;s (valid) signed time would be outside the validity window of the original signing certificate and would nonetheless render the attacker auditable.</p> <p>sigstore-python is a Python tool for generating and verifying Sigstore signatures. Versions of sigstore-python newer than 2.0.0 but prior to 3.6.0 perform insufficient validation of the &#34;integration time&#34; present in &#34;v2&#34; and &#34;v3&#34; bundles during the verification flow: the &#34;integration time&#34; is verified *if* a source of signed time (such as an inclusion promise) is present, but is otherwise trusted if no source of signed time is present. This does not affect &#34;v1&#34; bundles, as the &#34;v1&#34; bundle format always requires an inclusion promise.</p> <p>Sigstore uses signed time to support verification of signatures made against short-lived signing keys. The impact and severity of this weakness is *low*, as Sigstore contains multiple other enforcing components that prevent an attacker who modifies the integration timestamp within a bundle from impersonating a valid signature. In particular, an attacker who modifies the integration timestamp can induce a Denial of Service, but in no different manner than already possible with bundle access (e.g. modifying the signature itself such that it fails to verify). Separately, an attacker could upload a *new* entry to the transparency service, and substitute their new entry&#39;s time. However, this would still be rejected at validation time, as the new entry&#39;s (valid) signed time would be outside the validity window of the original signing certificate and would nonetheless render the attacker auditable.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2024-55655 https://cve.radiocsirt.org/vuln/ghsa-hhfg-fwrw-87w7 <p><strong>Affected:</strong> PyPI: sigstore</p> <p>### Summary</p> <p>Versions of sigstore-python newer than 2.0.0 but prior to 3.6.0 perform insufficient validation of the &#34;integration time&#34; present in &#34;v2&#34; and &#34;v3&#34; bundles during the verification flow: the &#34;integration time&#34; is verified *if* a source of signed time (such as an inclusion promise) is present, but is otherwise trusted if no source of signed time is present.</p> <p>This does not affect &#34;v1&#34; bundles, as the &#34;v1&#34; bundle format always requires an inclusion promise.</p> <p>### Details</p> <p>Sigstore uses signed time to support verification of signatures made against short-lived signing keys.</p> <p>### Impact</p> <p>The impact and severity of this weakness is *low*, as Sigstore contains multiple other enforcing components that prevent an attacker who modifies the integration timestamp within a bundle from impersonating a valid signature. In particular, an attacker who modifies the integration timestamp can induce a Denial of Service, but in no different manner than already possible with bundle access (e.g. modifying the signature itself such that it fails to verify).</p> <p>Separately, an attacker could upload a *new* entry to the transparency service, and substitute their new entry&#39;s time. However, this would still be rejected at validation time, as the new entry&#39;s (valid) signed time would be outside the validity window of the original signing certificate and would nonetheless render the attacker auditable.</p> <p><strong>Affected:</strong> PyPI: sigstore</p> <p>### Summary</p> <p>Versions of sigstore-python newer than 2.0.0 but prior to 3.6.0 perform insufficient validation of the &#34;integration time&#34; present in &#34;v2&#34; and &#34;v3&#34; bundles during the verification flow: the &#34;integration time&#34; is verified *if* a source of signed time (such as an inclusion promise) is present, but is otherwise trusted if no source of signed time is present.</p> <p>This does not affect &#34;v1&#34; bundles, as the &#34;v1&#34; bundle format always requires an inclusion promise.</p> <p>### Details</p> <p>Sigstore uses signed time to support verification of signatures made against short-lived signing keys.</p> <p>### Impact</p> <p>The impact and severity of this weakness is *low*, as Sigstore contains multiple other enforcing components that prevent an attacker who modifies the integration timestamp within a bundle from impersonating a valid signature. In particular, an attacker who modifies the integration timestamp can induce a Denial of Service, but in no different manner than already possible with bundle access (e.g. modifying the signature itself such that it fails to verify).</p> <p>Separately, an attacker could upload a *new* entry to the transparency service, and substitute their new entry&#39;s time. However, this would still be rejected at validation time, as the new entry&#39;s (valid) signed time would be outside the validity window of the original signing certificate and would nonetheless render the attacker auditable.</p> https://cve.radiocsirt.org/vuln/ghsa-hhfg-fwrw-87w7 https://cve.radiocsirt.org/vuln/pysec-2026-1923 <p><strong>Affected:</strong> PyPI: sigstore</p> <p>### Summary</p> <p>Versions of sigstore-python newer than 2.0.0 but prior to 3.6.0 perform insufficient validation of the &#34;integration time&#34; present in &#34;v2&#34; and &#34;v3&#34; bundles during the verification flow: the &#34;integration time&#34; is verified *if* a source of signed time (such as an inclusion promise) is present, but is otherwise trusted if no source of signed time is present.</p> <p>This does not affect &#34;v1&#34; bundles, as the &#34;v1&#34; bundle format always requires an inclusion promise.</p> <p>### Details</p> <p>Sigstore uses signed time to support verification of signatures made against short-lived signing keys.</p> <p>### Impact</p> <p>The impact and severity of this weakness is *low*, as Sigstore contains multiple other enforcing components that prevent an attacker who modifies the integration timestamp within a bundle from impersonating a valid signature. In particular, an attacker who modifies the integration timestamp can induce a Denial of Service, but in no different manner than already possible with bundle access (e.g. modifying the signature itself such that it fails to verify).</p> <p>Separately, an attacker could upload a *new* entry to the transparency service, and substitute their new entry&#39;s time. However, this would still be rejected at validation time, as the new entry&#39;s (valid) signed time would be outside the validity window of the original signing certificate and would nonetheless render the attacker auditable.</p> <p><strong>Affected:</strong> PyPI: sigstore</p> <p>### Summary</p> <p>Versions of sigstore-python newer than 2.0.0 but prior to 3.6.0 perform insufficient validation of the &#34;integration time&#34; present in &#34;v2&#34; and &#34;v3&#34; bundles during the verification flow: the &#34;integration time&#34; is verified *if* a source of signed time (such as an inclusion promise) is present, but is otherwise trusted if no source of signed time is present.</p> <p>This does not affect &#34;v1&#34; bundles, as the &#34;v1&#34; bundle format always requires an inclusion promise.</p> <p>### Details</p> <p>Sigstore uses signed time to support verification of signatures made against short-lived signing keys.</p> <p>### Impact</p> <p>The impact and severity of this weakness is *low*, as Sigstore contains multiple other enforcing components that prevent an attacker who modifies the integration timestamp within a bundle from impersonating a valid signature. In particular, an attacker who modifies the integration timestamp can induce a Denial of Service, but in no different manner than already possible with bundle access (e.g. modifying the signature itself such that it fails to verify).</p> <p>Separately, an attacker could upload a *new* entry to the transparency service, and substitute their new entry&#39;s time. However, this would still be rejected at validation time, as the new entry&#39;s (valid) signed time would be outside the validity window of the original signing certificate and would nonetheless render the attacker auditable.</p> https://cve.radiocsirt.org/vuln/pysec-2026-1923