Gitsign's CertVerifier.Verify routine dereferences the first element of the certificates slice without checking that the slice contains any certificates. When a CMS/PKCS7 signed message supplies an empty certificate set, the routine panics with an index-out-of-range error. The panic is caught by an internal recovery wrapper that swallows the error and returns nil, leading the program to continue as if verification had succeeded. Because the error is hidden, the --verify command exits with status 0 despite the signature being invalid. Any script or CI system that interprets a zero exit status as a successful verification will therefore accept a forged commit or signature, effectively bypassing the trust model and allowing attackers to inject malicious changes. The flaw arises from improper bounds checking (CWE-129) and unchecked error handling (CWE-390). It affects sigstore's Gitsign tool versions 0.4.0 through 0.14.x and is fixed in 0.15.0.

Vendor sigstore publishes the Gitsign utility, a keyless signing tool for Git commits that uses GitHub/OIDC identities. The vulnerability exists in Gitsign releases 0.4.0 up to and including 0.14.x. Systems relying on any of these versions and using the git verify-commit path are susceptible until they are updated to 0.15.0 or later.

The CVSS score of 5.4 indicates a medium severity, and the vulnerability is not listed in CISA's KEV catalog. With no EPSS score published, the exploit probability is uncertain. The likely attack vector requires an attacker to supply a specially crafted PKCS7 signed message that contains no certificates; when such a message is verified via git verify-commit, the flawed recovery masks the failure and signals success. Although the attacker must be able to influence the verification process, the consequence of a successful bypass is that untrusted commits can appear authenticated, potentially compromising the integrity of the repository.