CVE-2026-48758

What it actually does

The flaw is a cryptographic binding weakness in sigstore-js, specifically in @sigstore/core before version 3.2.1. The DSSE pre-authentication encoding routine converts the payload type string using Node.js "ascii" encoding, which can cause different string values to map to the same byte sequence. Because the signature is calculated and verified over this incorrectly encoded representation, an attacker can alter the payloadType field after signing while preserving a valid signature. This weakens DSSE’s guarantee that the signature binds both the payload and its declared type, potentially allowing a signed object to be interpreted as a different kind of artifact or attestation than originally intended.

Why it matters to the business

Organizations relying on sigstore-js to verify signed software artifacts, attestations, provenance, or supply-chain metadata may incorrectly trust a signed object whose declared type has been tampered with. The direct technical severity is moderate, but the business risk is higher in CI/CD, artifact admission, release approval, and software supply-chain control paths where type information determines policy decisions. There is no current CISA KEV listing, no known ransomware association, and EPSS is very low, indicating no broad exploitation signal at this time; however, because Sigstore is commonly used in software integrity workflows, affected deployments should still be updated promptly.

How an attack unfolds

An attacker first obtains or creates a DSSE envelope that is legitimately signed and accepted by systems using vulnerable sigstore-js verification logic. The attacker then modifies the envelope’s payloadType field using character substitutions that are treated equivalently under Node.js ascii encoding during pre-authentication encoding. Because the vulnerable verifier reconstructs the bytes incorrectly, the signature may still validate even though the visible payloadType has changed. If downstream policy, admission, or release logic trusts the altered payloadType, the attacker may cause a signed object to be processed under the wrong semantic category, bypassing controls that depend on strong binding between the payload and its type. Practical exploitation requires an application workflow where a mutable or attacker-supplied DSSE envelope is verified by affected versions of @sigstore/core and where payloadType influences a security decision.

How to fix it

Upgrade @sigstore/core to version 3.2.1 or later, and update any sigstore-js dependency chain that pulls in @sigstore/core. Regenerate lockfiles and rebuild applications or containers so the patched package is actually deployed. If direct upgrading is delayed, mitigate by rejecting DSSE envelopes whose payloadType contains non-ASCII characters or unexpected Unicode, enforcing an allowlist of exact payloadType values, and avoiding security decisions based solely on payloadType until verification is performed by a patched library. Review transitive dependencies because applications may consume @sigstore/core indirectly through higher-level Sigstore packages.

How to confirm the fix worked

Confirm that dependency manifests and resolved lockfiles no longer contain @sigstore/core versions earlier than 3.2.1. Validate deployed artifacts, containers, and serverless bundles, not only source repositories, because vulnerable JavaScript dependencies may be packaged into build outputs. Run package-manager checks such as npm ls @sigstore/core, pnpm why @sigstore/core, or yarn why @sigstore/core and verify the resolved version is 3.2.1 or later. Where practical, add a regression test that verifies DSSE signatures fail if payloadType is modified after signing, including cases involving non-ASCII characters. Confirm CI/CD and artifact-verification services have been rebuilt and redeployed after the dependency update.

Typical attack path

1. Identify a target workflow that uses sigstore-js or @sigstore/core before version 3.2.1 to verify DSSE envelopes.
2. Obtain a legitimately signed DSSE envelope or produce one through an allowed signing workflow.
3. Modify the DSSE payloadType value using non-standard character encodings that collide under Node.js ascii conversion.
4. Submit the altered signed envelope to a vulnerable verifier.
5. The vulnerable verifier validates the signature because it computes the same flawed pre-authentication byte sequence.
6. Abuse downstream policy logic that trusts the modified payloadType to misclassify or accept the artifact, attestation, or metadata.

How to detect it

To assess prior exploitation, review systems that verify DSSE envelopes using sigstore-js or @sigstore/core before 3.2.1. Focus on CI/CD logs, artifact admission controller logs, package publication logs, provenance verification logs, Sigstore verification service logs, and application logs that record DSSE envelope metadata. Look for payloadType values containing non-ASCII characters, escaped Unicode sequences, control characters, visually confusable characters, or values that differ from the small set normally used in the organization’s signing workflows. Compare stored DSSE envelopes against expected artifact types and re-verify suspicious samples with @sigstore/core 3.2.1 or later. Investigate cases where an artifact was accepted by an older verifier but fails verification or policy validation after upgrading. There are no public reports of active exploitation or named threat actors for this issue as of the provided data.

• node_modules/@sigstore/core/package.json
• "@sigstore/core": "3.2.0"
• "@sigstore/core":"3.2.0"
• "@sigstore/core": "3.1.
• "@sigstore/core":"3.1.
• "@sigstore/core": "3.0.
• "@sigstore/core":"3.0.
• "payloadType":"\\u
• "payloadType": "\\u

What your security team should do

• Prioritize updating @sigstore/core to 3.2.1 or later in build, signing, verification, artifact admission, and release automation systems.
• Search source repositories, lockfiles, container images, and deployed bundles for transitive use of vulnerable @sigstore/core versions.
• Enforce strict allowlists for expected DSSE payloadType values, especially in policy engines and release gates.
• Review recent DSSE verification events for unexpected, malformed, or non-ASCII payloadType values.
• Treat any signed artifact or attestation with an unusual payloadType as suspicious until verified with a patched library.
• Because this issue is not currently in KEV and has very low EPSS, handle it as a timely supply-chain integrity fix rather than an emergency internet-wide exploitation event.