Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2026-49834

CVE-2026-49834: sigstore-go Auth Bypass Vulnerability

CVE-2026-49834 is an authentication bypass flaw in sigstore-go that allows a single compromised transparency log to bypass multi-log verification policies. This article covers technical details, affected versions, and mitigation.

Published:

CVE-2026-49834 Overview

CVE-2026-49834 is a signature verification flaw in sigstore-go, a Go library used for Sigstore signing and verification workflows. Versions prior to 1.2.0 incorrectly count verified witnesses when consumers configure WithTransparencyLog(N>1) or WithSignedCertificateTimestamps(N>1). The library tallies witnesses per entry or per validation path rather than per distinct log authority. A single compromised transparency log or Certificate Transparency (CT) log can therefore satisfy multi-log threshold requirements on its own, defeating the multi-log policy intended to distribute trust. The issue is fixed in version 1.2.0 and is categorized under [CWE-347: Improper Verification of Cryptographic Signature].

Critical Impact

A single compromised Sigstore transparency log or CT log can forge artifact provenance that passes multi-log threshold verification, undermining supply-chain integrity guarantees.

Affected Products

  • sigstore/sigstore-go versions prior to 1.2.0
  • Go applications using WithTransparencyLog(N>1) verification options
  • Go applications using WithSignedCertificateTimestamps(N>1) verification options

Discovery Timeline

  • 2026-07-17 - CVE-2026-49834 published to the National Vulnerability Database (NVD)
  • 2026-07-21 - CVE-2026-49834 last updated in NVD

Technical Details for CVE-2026-49834

Vulnerability Analysis

Sigstore relies on multiple independent transparency logs and CT logs to distribute trust across separate authorities. Consumers can request a threshold of N>1 distinct witnesses to raise the bar against a single-authority compromise. In sigstore-go prior to 1.2.0, the verification routines in pkg/verify/sct.go and pkg/verify/tlog.go counted each successfully validated entry toward the threshold. They did not deduplicate entries by their originating log identifier. An attacker in control of one log could therefore emit multiple valid signed entries and satisfy the requested threshold alone.

The library treats identical log authorities as separate witnesses, converting an N-of-N policy into a 1-of-1 policy in practice. This nullifies the security benefit of configuring multi-log verification.

Root Cause

The root cause is an incorrect counting model in the witness aggregation logic. Instead of tracking the set of unique log key identifiers that produced valid proofs, the code incremented a scalar counter per verified entry or per validation path. Multiple entries or Signed Certificate Timestamps (SCTs) from the same log key were credited independently toward the threshold.

Attack Vector

An adversary who compromises a single Sigstore Rekor transparency log or a single CT log signing key can issue multiple valid log entries or SCTs for a malicious artifact. When a downstream verifier configured with a multi-log threshold processes the bundle, the duplicate-log entries pass the count check. The verifier accepts the artifact as multi-log attested even though only one authority signed it. Exploitation is network-based with high attack complexity because it requires prior compromise of a log signing key.

go
// Patch excerpt from pkg/verify/sct.go
// Source: https://github.com/sigstore/sigstore-go/commit/dbb07e62623edd5b175fb9dd5a41dcb85a159207

-	verified := 0
+	verifiedLogs := make(map[string]bool)
 	for _, sct := range scts {
 		encodedKeyID := hex.EncodeToString(sct.LogID.KeyID[:])
+		if verifiedLogs[encodedKeyID] {
+			// Skip verification of SCTs from the same log after one successful verification.
+			continue
+		}
 		key, ok := ctlogs[encodedKeyID]
 		if !ok {
-			// skip entries the trust root cannot verify
+			// Skip entries the trust root cannot verify
 			continue
 		}

The fix replaces the scalar verified counter with a verifiedLogs map keyed by the hex-encoded log key identifier. A parallel change in pkg/verify/tlog.go introduces verifiedLogIDsMap and hasTimestampMap to deduplicate transparency log entries and their timestamps by log identifier.

Detection Methods for CVE-2026-49834

Indicators of Compromise

  • Sigstore bundles containing multiple Rekor entries whose logID values collide when hex-decoded.
  • Verification bundles with multiple SCTs sharing the same LogID.KeyID presented as satisfying an N>1 threshold.
  • Artifact provenance that references only one distinct transparency log authority despite claiming multi-log coverage.

Detection Strategies

  • Inventory Go build artifacts and services that import github.com/sigstore/sigstore-go at versions below 1.2.0 using software composition analysis.
  • Inspect signature verification bundles offline and count unique log key identifiers rather than raw entry counts.
  • Audit code that calls WithTransparencyLog or WithSignedCertificateTimestamps with a threshold greater than one to confirm the dependency is patched.

Monitoring Recommendations

  • Log the set of distinct transparency log authorities that contributed to each successful signature verification and alert on single-authority verifications where policy requires multiple.
  • Track dependency updates for sigstore-go across CI/CD pipelines and container images.
  • Monitor upstream Sigstore trust root changes and correlate them with unexpected verification outcomes in build and admission pipelines.

How to Mitigate CVE-2026-49834

Immediate Actions Required

  • Upgrade github.com/sigstore/sigstore-go to version 1.2.0 or later in all Go modules.
  • Rebuild and redeploy any binaries, admission controllers, and CI/CD verifiers that embed the vulnerable library.
  • Re-verify recently accepted artifacts using the patched library where multi-log policy was expected to apply.

Patch Information

The fix is available in sigstore-gov1.2.0. See the GitHub Security Advisory GHSA-9vcr-p3rj-q5q6, the merged pull request #633, the remediation commit dbb07e6, and the v1.2.0 release notes.

Workarounds

  • If upgrading is not immediately possible, treat multi-log verification results as single-log until the library is patched and layer additional out-of-band provenance checks.
  • Restrict trust root configuration to log authorities under independent operational control and validate log identifier diversity in application code.
  • Gate deployments behind admission policies that reject bundles containing duplicate log key identifiers within the witness set.
bash
# Upgrade sigstore-go to the patched release
go get github.com/sigstore/sigstore-go@v1.2.0
go mod tidy

# Confirm the resolved version
go list -m github.com/sigstore/sigstore-go

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.