CVE-2026-49834

What it actually does

The flaw weakens multi-log verification in sigstore-go before version 1.2.0. When applications configure verification policies using WithTransparencyLog(N>1) or WithSignedCertificateTimestamps(N>1), the library incorrectly counts verified witnesses per log entry or validation path instead of counting distinct transparency log or certificate transparency log authorities. As a result, one compromised, malicious, or incorrectly trusted log can appear to satisfy a policy that was intended to require independent confirmation from multiple logs. The practical impact is integrity failure: a forged or improperly logged signature/certificate validation path may be accepted even though the intended multi-party transparency requirement was not actually met.

Why it matters to the business

Organizations relying on sigstore-go for software supply-chain verification may have weaker integrity guarantees than expected. An attacker who can compromise or influence a single trusted transparency or CT log could potentially cause malicious or unauthorized artifacts to pass verification in systems that were configured to require multiple independent logs. This could affect release pipelines, artifact admission controls, provenance checks, or dependency verification workflows. The CVSS score is moderate and EPSS is currently very low, and there is no known KEV listing or public exploit maturity, but the impact is important for organizations that use Sigstore verification as a gate for trusted software delivery.

How an attack unfolds

An attacker first needs a target that uses a vulnerable version of sigstore-go and has configured multi-log threshold verification using WithTransparencyLog with a value greater than 1, or WithSignedCertificateTimestamps with a value greater than 1. The attacker then needs control over, compromise of, or the ability to manipulate one transparency log or CT log authority that is trusted by the verifier. Instead of needing multiple independent log authorities to satisfy the configured threshold, the attacker can rely on multiple entries or validation paths associated with the same compromised authority. Because the vulnerable verifier counts witnesses incorrectly, the verification policy may be satisfied even though the expected independent log diversity was not present. This can allow an artifact, signature, certificate, or provenance chain to be treated as valid when it should have failed the multi-log policy.

How to fix it

Upgrade sigstore-go to version 1.2.0 or later wherever it is used directly or transitively. Rebuild and redeploy applications, CI/CD components, admission controllers, artifact verification services, or release tooling that vendor or statically link sigstore-go. If immediate upgrade is not possible, review verification policy code paths that use WithTransparencyLog(N>1) or WithSignedCertificateTimestamps(N>1), and add compensating checks that enforce distinct log authorities rather than counting entries or validation paths. Consider temporarily reducing reliance on vulnerable multi-log threshold semantics and adding independent validation controls, such as restricting trusted logs, verifying expected log identities explicitly, and requiring additional artifact provenance checks outside the vulnerable verifier path.

How to confirm the fix worked

Confirm the deployed dependency graph includes sigstore-go version 1.2.0 or later. For Go projects, run dependency inventory commands such as `go list -m -json all` or review `go.mod`, `go.sum`, vendored modules, and SBOMs for `github.com/sigstore/sigstore-go` versions earlier than 1.2.0. Rebuild binaries after upgrading, because Go applications commonly statically link dependencies. Validate behavior with a regression test that configures WithTransparencyLog(N>1) or WithSignedCertificateTimestamps(N>1) and verifies that multiple witnesses from the same log authority do not satisfy the threshold. Review deployed container images, release binaries, and internal developer tooling to ensure the fixed library version is present in the artifact actually running in production.

Typical attack path

1. Identify a software, CI/CD, artifact admission, or provenance-verification workflow using sigstore-go before version 1.2.0.
2. Confirm that the verifier is configured with WithTransparencyLog(N>1) or WithSignedCertificateTimestamps(N>1).
3. Gain influence over or compromise one transparency log or CT log authority that the verifier trusts, or otherwise produce log evidence from a single trusted authority.
4. Create or submit signing, certificate, or transparency evidence that produces multiple accepted witnesses from the same authority.
5. Rely on the vulnerable verifier to count those witnesses as satisfying the configured multi-log threshold.
6. Pass verification for an artifact or identity assertion that should have been rejected under the intended independent multi-log policy.

How to detect it

This issue is primarily a verification logic flaw and does not produce a universal runtime indicator of compromise. To determine whether it was already exploited, focus on exposure and decision history. Identify systems that used sigstore-go before 1.2.0 and were configured with multi-log thresholds greater than 1. Review CI/CD, release, artifact repository, deployment admission, and provenance-verification logs for artifacts that passed verification where the supporting transparency log or CT evidence came from the same log authority multiple times. Examine Sigstore verification logs, Rekor-related verification output, certificate chain validation logs, policy engine decisions, and deployment admission audit logs for cases where multi-log policy satisfaction did not involve distinct log authorities. Correlate suspicious approvals with artifact publication times, signer identity, certificate issuer details, log IDs, inclusion proofs, SCTs, and any later trust changes or compromise reports involving transparency or CT logs. If available, compare historical verification results using the fixed sigstore-go 1.2.0 verifier; artifacts that previously passed but now fail distinct-log threshold validation should be investigated.

• github.com/sigstore/sigstore-go v1.0
• github.com/sigstore/sigstore-go v1.1
• github.com/sigstore/sigstore-go v1.1.0
• github.com/sigstore/sigstore-go v1.1.1
• WithTransparencyLog(
• WithSignedCertificateTimestamps(
• WithTransparencyLog(2
• WithSignedCertificateTimestamps(2

What your security team should do

• Inventory all repositories, binaries, containers, CI/CD tools, artifact verification services, and admission-control components that use sigstore-go directly or through vendored dependencies.
• Prioritize upgrades to sigstore-go 1.2.0 or later for systems that enforce software signing, provenance, build attestation, deployment admission, or package release controls.
• Search code for WithTransparencyLog and WithSignedCertificateTimestamps usage, especially configurations where the threshold is greater than 1.
• Add or update tests to assert that multi-log thresholds require distinct log authorities, not multiple entries or validation paths from one authority.
• Review recent high-risk artifact approvals or releases that depended on vulnerable multi-log verification semantics, especially where unusual transparency or CT log evidence was present.
• Monitor Sigstore, transparency log, CT log, and package ecosystem advisories for any indication of compromised or distrusted log authorities.
• Where feasible, add defense-in-depth controls such as artifact allowlists, reproducible build checks, provenance policy enforcement, and independent signature verification outside the vulnerable code path.