Skip to main content

sigstore-go EUVDEUVD-2026-45287

| CVE-2026-49834 HIGH
Insufficient Verification of Data Authenticity (CWE-345)
2026-07-09 https://github.com/sigstore/sigstore-go GHSA-9vcr-p3rj-q5q6
7.5
CVSS 3.1 · NVD
Share

Severity by source

NVD PRIMARY
7.5 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
vuln.today AI
5.9 MEDIUM

AV:N and PR:N since no privileges on the verifier are needed, but AC:H because exploitation requires a non-default N>1 config plus a compromised trusted log; impact is integrity-only (I:H, C:N, A:N).

3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
4.0 AV:N/AC:H/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N
SUSE
5.9 MEDIUM
AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
Red Hat
5.9 MEDIUM
qualitative

Primary rating from NVD.

CVSS VectorNVD

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
High
Availability
None

Lifecycle Timeline

6
Source Code Evidence Fetched
Jul 30, 2026 - 13:32 vuln.today
Analysis Updated
Jul 30, 2026 - 13:32 vuln.today
v2 (cvss_changed)
Re-analysis Queued
Jul 30, 2026 - 13:22 vuln.today
cvss_changed
Severity Changed
Jul 30, 2026 - 13:22 NVD
MEDIUM HIGH
CVSS changed
Jul 30, 2026 - 13:22 NVD
5.9 (MEDIUM) 7.5 (HIGH)
Analysis Generated
Jul 09, 2026 - 23:53 vuln.today

DescriptionNVD

Impact

_What kind of vulnerability is it? Who is impacted?_

A verifier configured with WithTransparencyLog(N>1) or WithSignedCertificateTimestamps(N>1) expected defense-in-depth against the compromise of a single log instance. However, threshold counting counted verified witnesses per-entry or per-validation-path rather than per-log-authority.

As a result, a single compromised transparency log could forge multiple entries with different indices, and a single compromised CT log could verify multiple times (either across multiple certificate chains or via multiple embedded SCTs), fully satisfying the multi-log threshold requirements and defeating the multi-log policy.

Note that this does not affect Cosign, as Cosign sets a threshold of 1.

Patches

_Has the problem been patched? What versions should users upgrade to?_

Upgrade to v1.1.5.

Workarounds

_Is there a way for users to fix or remediate the vulnerability without upgrading?_

There is no workaround, beyond relying on trusted logs.

AnalysisAI

Multi-log verification bypass in sigstore-go (< 1.2.0) lets a single compromised transparency log or CT log satisfy a multi-log threshold intended as defense-in-depth. Verifiers configured with WithTransparencyLog(N>1) or WithSignedCertificateTimestamps(N>1) counted verified entries or validation paths rather than distinct log authorities, so one malicious log could forge multiple entries (different indices) or present multiple SCTs and meet the N-of-N policy alone. There is no public exploit identified at time of analysis, EPSS is low (0.17%), and SSVC lists exploitation as none; Cosign is unaffected because it uses a threshold of 1.

Technical ContextAI

sigstore-go is the Go implementation of Sigstore artifact-signature verification, checking inclusion in Rekor transparency logs and validating Certificate Transparency (CT) Signed Certificate Timestamps (SCTs) embedded in Fulcio-issued certificates. The multi-log feature is meant to provide defense-in-depth: requiring N independent log authorities to attest an entry so that compromising a single log is insufficient. The root cause is CWE-345 (Insufficient Verification of Data Authenticity): in pkg/verify/tlog.go the code incremented a scalar logEntriesVerified per verified entry, and in pkg/verify/sct.go it incremented a scalar 'verified' per SCT/validation path, neither keyed by the log's identity. The fix replaces these counters with sets keyed by log key ID (verifiedLogIDsMap and verifiedLogs map[string]bool), skipping additional SCTs from an already-counted log and comparing the count of distinct log authorities against the threshold.

RemediationAI

Vendor-released patch: upgrade sigstore-go to the fixed release identified by the vendor. NOTE A DATA CONFLICT - the advisory prose states 'Upgrade to v1.1.5', while the GHSA structured 'fixed in' field, the ENISA EUVD range (< 1.2.0), and the referenced release tag all indicate v1.2.0; treat v1.2.0 as the safe target and confirm with the vendor advisory before pinning. The fix is delivered in commit dbb07e62623edd5b175fb9dd5a41dcb85a159207 (PR #633, release https://github.com/sigstore/sigstore-go/releases/tag/v1.2.0). The vendor states there is no workaround beyond relying on trusted logs. As a compensating control, ensure every configured transparency and CT log in your trust root is one you actually trust and independently operate/monitor, since the multi-log threshold provides no protection until patched; alternatively, until upgrade, do not rely on N>1 thresholds as a security boundary (they collapse to a single-log trust assumption), and prioritize monitoring/alerting on log-key compromise. Advisory: https://github.com/sigstore/sigstore-go/security/advisories/GHSA-9vcr-p3rj-q5q6.

Vendor StatusVendor

SUSE

Severity: Moderate
Product Status
SUSE Linux Enterprise Desktop 15 SP7 Not-Affected
SUSE Linux Enterprise Desktop 15 SP7 Affected
SUSE Linux Enterprise High Performance Computing 12 Not-Affected
SUSE Linux Enterprise High Performance Computing 15 SP7 Not-Affected
SUSE Linux Enterprise High Performance Computing 15 SP7 Affected

Share

EUVD-2026-45287 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy