Haydentherapper

**Name of the Vulnerable Software and Affected Versions** sigstore-python versions 2.0.0 through 3.6.0 **Description** The issue concerns insufficient validation of the "integration time" in "v2" and "v3" bundles during the verification flow. This affects versions of sigstore-python newer than 2.0.0 but prior to 3.6.0. The "integration time" 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 "v1" bundles, as they always require an inclusion promise. Sigstore uses signed time to support verification of signatures made against short-lived signing keys. The impact and severity of this weakness are low, as Sigstore contains multiple other enforcing components that prevent an attacker from impersonating a valid signature by modifying the integration timestamp. An attacker who modifies the integration timestamp can induce a Denial of Service, but this is already possible with bundle access. An attacker could upload a new entry to the transparency service and substitute their new entry's time, but this would be rejected at validation time due to the new entry's signed time being outside the validity window of the original signing certificate. **Recommendations** For versions 2.0.0 through 3.6.0, update to version 3.6.0 or later to resolve the issue. As a temporary workaround, consider restricting access to the verification flow to minimize the risk of exploitation. Avoid modifying the integration timestamp within bundles, as this could induce a Denial of Service. Restrict access to the transparency service to prevent attackers from uploading new entries with substituted times.

**Name of the Vulnerable Software and Affected Versions** Dex versions prior to 2.35.0 **Description** Dex is an identity service that uses OpenID Connect to drive authentication for other apps. An attacker can exploit this issue by making a victim navigate to a malicious website and guiding them through the OIDC flow, stealing the OAuth authorization code in the process. The authorization code can then be exchanged for a token, gaining access to applications accepting that token. **Recommendations** For versions prior to 2.35.0, update to version 2.35.0 to resolve the issue. As a temporary workaround, consider disabling public clients to minimize the risk of exploitation. Note that disabling public clients may impact behavior. There are no known workarounds for existing versions without impacting behavior.

**Name of the Vulnerable Software and Affected Versions** cosign versions prior to 1.12.0 **Description** A number of issues have been found in cosign verify-blob, where cosign would successfully verify an artifact when verification should have failed. These issues include: - a cosign bundle can be crafted to successfully verify a blob even if the embedded rekorBundle does not reference the given signature, - when providing identity flags, the email and issuer of a certificate is not checked when verifying a Rekor bundle, and the GitHub Actions identity is never checked, - providing an invalid Rekor bundle without the experimental flag results in a successful verification, - an invalid transparency log entry will result in immediate success for verification. **Recommendations** For versions prior to 1.12.0, update to version 1.12.0 to resolve the issues. As a temporary workaround for the first issue, consider extracting the signature and certificate from the bundle and using them for verification instead of the bundle, by running `cosign verify-blob blob1 --signature $(jq -r '.base64Signature' bundle1) --certificate $(jq -r '.cert' bundle1)`. However, note that this workaround may make a network call to Rekor and could be subject to the fourth issue. For the other issues, there are no workarounds, and users should update to version 1.12.0.