CVE-2026-48758: sigstore-js Auth Bypass Vulnerability

CVE-2026-48758 Overview

CVE-2026-48758 affects sigstore-js, the JavaScript library suite for interacting with Sigstore services. The preAuthEncoding function in @sigstore/core uses Node.js ascii encoding when converting the Pre-Authentication Encoding (PAE) string to bytes. This encoding choice allows the payloadType field to be mutated after signing without invalidating the Dead Simple Signing Envelope (DSSE) signature. The flaw breaks the type-binding guarantee that DSSE is designed to enforce [CWE-347: Improper Verification of Cryptographic Signature]. Versions prior to 3.2.1 are affected, and the issue is fixed in @sigstore/core version 3.2.1.

Critical Impact
An attacker with a valid signature over one payload type can substitute a different payloadType value and have the signature still verify, undermining trust decisions built on DSSE envelopes.

Affected Products

sigstore-js (@sigstore/core) versions prior to 3.2.1
JavaScript and Node.js applications embedding @sigstore/core for DSSE signing or verification
Downstream Sigstore-integrated toolchains that rely on sigstore-js for signature validation

Discovery Timeline

2026-07-14 - CVE-2026-48758 published to the National Vulnerability Database (NVD)
2026-07-15 - Last updated in the NVD database

Technical Details for CVE-2026-48758

Vulnerability Analysis

DSSE relies on PAE to bind a payloadType string to a payload byte sequence before signing. The signer computes a signature over the concatenation of PAE_PREFIX, payloadType, and payload, so any mutation to payloadType should invalidate the signature. In vulnerable sigstore-js releases, preAuthEncoding constructs the prefix using JavaScript string concatenation and then converts the result with Buffer.from(prefix, 'ascii'). Node.js ascii encoding is defined as Latin-1 truncated to seven bits, discarding the high bit of every byte. Multi-byte UTF-8 sequences in payloadType collapse into different byte sequences that can collide with alternate payloadType values. An attacker can craft two distinct payloadType strings that hash to identical PAE bytes, allowing a signature produced for one type to verify against another.

Root Cause

The root cause is the use of a lossy character encoding when serializing signed data. ascii encoding is not injective for arbitrary Unicode input, so different payloadType values may produce the same signing input. This violates the DSSE requirement that the signed byte string uniquely identifies the payload type.

Attack Vector

Exploitation requires an attacker who can influence the payloadType presented to a verifier and who possesses or can obtain a valid signature over a colliding PAE representation. The attacker submits a DSSE envelope where payloadType is swapped to a value that a downstream consumer interprets differently, for example switching a benign attestation type to one that grants build provenance or policy assertions.

typescript

// DSSE Pre-Authentication Encoding
export function preAuthEncoding(payloadType: string, payload: Buffer): Buffer {
-  const prefix = [
-    PAE_PREFIX,
-    payloadType.length,
-    payloadType,
-    payload.length,
-    '',
-  ].join(' ');
+  const typeBytes = Buffer.from(payloadType, 'utf-8');

-  return Buffer.concat([Buffer.from(prefix, 'ascii'), payload]);
+  return Buffer.concat([
+    Buffer.from(`${PAE_PREFIX} ${typeBytes.length} `, 'ascii'),
+    typeBytes,
+    Buffer.from(` ${payload.length} `, 'ascii'),
+    payload,
+  ]);
}

Source: sigstore-js commit b5aa4f1. The patch encodes payloadType as UTF-8 bytes and uses the byte length rather than the JavaScript string length, preserving injectivity between payloadType values and PAE bytes.

Detection Methods for CVE-2026-48758

Indicators of Compromise

DSSE envelopes containing payloadType values with non-ASCII characters or unusual Unicode code points that fold under ascii encoding
Attestations where the declared payloadType does not match the internal _type field or schema of the decoded payload
Repeated signature verifications succeeding across attestation streams that reference the same signature bytes but differing payloadType strings

Detection Strategies

Inventory Node.js applications and CI/CD pipelines using @sigstore/core and compare installed versions against 3.2.1
Scan software bills of materials (SBOMs) and lockfiles (package-lock.json, pnpm-lock.yaml, yarn.lock) for vulnerable @sigstore/core ranges
Re-verify archived DSSE attestations with a patched verifier to surface signatures that only validated under the ASCII-lossy encoding

Monitoring Recommendations

Log every DSSE verification outcome along with the exact payloadType string and payload hash for later replay analysis
Alert on attestation consumers that accept payloadType values outside an allowlist of expected in-toto or SLSA predicate types
Track dependency changes in build systems so downgrades of @sigstore/core below 3.2.1 trigger a review

How to Mitigate CVE-2026-48758

Immediate Actions Required

Upgrade @sigstore/core to version 3.2.1 or later across all projects, container images, and build agents
Rebuild and republish any application bundling sigstore-js so consumers pull the patched transitive dependency
Re-verify recently accepted DSSE attestations using the patched library and reject any that fail

Patch Information

The fix is delivered in @sigstore/core version 3.2.1. It replaces the ascii encoding of the PAE prefix with an explicit UTF-8 byte conversion of payloadType and computes lengths in bytes rather than JavaScript UTF-16 code units. Refer to the sigstore-js GitHub Security Advisory GHSA-jfc7-64v2-mr8c, the pull request #1657, and the @sigstore/core 3.2.1 release notes.

Workarounds

Enforce a strict allowlist of expected payloadType values at the verifier and reject envelopes containing non-ASCII characters in payloadType
Perform a secondary check that the decoded payload's internal _type matches the outer payloadType before trusting attestation contents
Pin @sigstore/core to >=3.2.1 in dependency manifests to prevent accidental downgrade through transitive resolution

bash

# Configuration example: upgrade and verify installed version
npm install @sigstore/core@^3.2.1
npm ls @sigstore/core

# Fail CI if a vulnerable version is present
npm ls @sigstore/core --json | \
  jq -e '[.. | .version? // empty] | all(. as $v | $v | split(".") | (.[0]|tonumber) > 3 or ((.[0]|tonumber)==3 and ((.[1]|tonumber) > 2 or ((.[1]|tonumber)==2 and (.[2]|tonumber)>=1))))'