GHSA-XGJW-PM74-86Q4

Vulnerability from github – Published: 2026-07-01 19:57 – Updated: 2026-07-01 19:57
VLAI
Summary
sigstore-js has Insufficient Verification of Data Authenticity
Details

sigstore-js derives a transparency-log timestamp from tlogEntries[].integratedTime and uses it to validate certificate validity windows and satisfy timestampThreshold. For bundle v0.2, a tlog entry can be inclusionProof-only (no signed inclusionPromise/set), and the inclusion proof path does not cryptographically bind integratedTime. As a result, an attacker who can supply an untrusted bundle can influence time-based verification decisions by choosing integratedTime.

impact

If a consumer accepts attacker-provided bundle v0.2 inputs and relies on tlog-derived timestamps for certificate validity checks, verification can be influenced by an unauthenticated timestamp value. This is a trust gap: integratedTime is treated as a trusted observer timestamp under inclusionProof-only mode even though only the signed inclusionPromise/set path binds it.

affected code

  • packages/verify/src/bundle/index.ts (adds a transparency-log timestamp whenever integratedTime != 0)
  • packages/verify/src/timestamp/index.ts (converts integratedTime to a Date)
  • packages/verify/src/verifier.ts (verifies timestamps before verifying tlog inclusion)
  • packages/verify/src/tlog/index.ts + packages/verify/src/tlog/set.ts (only the inclusionPromise/set path binds integratedTime)

proof of concept

The attached poc.zip contains a self-contained harness that reproduces the behavior on the pinned commit and includes both a canonical test and a negative control.

repro: 1) extract poc.zip into a fresh directory and run the make targets:

unzip poc.zip -d poc
cd poc/poc-F-SIG-JS-TLOGTIME-001
make canonical
make control

2) confirm canonical.log includes:

[CALLSITE_HIT]:
[PROOF_MARKER]:

3) confirm control.log includes:

[NC_MARKER]:

suggested fix

Only treat integratedTime as a trusted timestamp when it is cryptographically bound (for example, via a verified signed inclusionPromise/set). For inclusionProof-only entries, do not count integratedTime toward timestampThreshold, and do not use it for certificate validity decisions unless there is another signed time source (for example, an rfc3161 timestamp).

poc.zip PR_DESCRIPTION.md SUBMISSION.md

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@sigstore/verify"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.1.0"
            },
            {
              "fixed": "3.1.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "3.1.0"
      ]
    }
  ],
  "aliases": [
    "CVE-2026-48816"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-345"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-01T19:57:45Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "sigstore-js derives a transparency-log timestamp from `tlogEntries[].integratedTime` and uses it to validate certificate validity windows and satisfy `timestampThreshold`. For bundle v0.2, a tlog entry can be inclusionProof-only (no signed inclusionPromise/set), and the inclusion proof path does not cryptographically bind `integratedTime`. As a result, an attacker who can supply an untrusted bundle can influence time-based verification decisions by choosing `integratedTime`.\n\n## impact\nIf a consumer accepts attacker-provided bundle v0.2 inputs and relies on tlog-derived timestamps for certificate validity checks, verification can be influenced by an unauthenticated timestamp value. This is a trust gap: `integratedTime` is treated as a trusted observer timestamp under inclusionProof-only mode even though only the signed inclusionPromise/set path binds it.\n\n## affected code\n- `packages/verify/src/bundle/index.ts` (adds a transparency-log timestamp whenever `integratedTime != 0`)\n- `packages/verify/src/timestamp/index.ts` (converts `integratedTime` to a `Date`)\n- `packages/verify/src/verifier.ts` (verifies timestamps before verifying tlog inclusion)\n- `packages/verify/src/tlog/index.ts` + `packages/verify/src/tlog/set.ts` (only the inclusionPromise/set path binds `integratedTime`)\n\n## proof of concept\nThe attached `poc.zip` contains a self-contained harness that reproduces the behavior on the pinned commit and includes both a canonical test and a negative control.\n\nrepro:\n1) extract `poc.zip` into a fresh directory and run the make targets:\n\n```bash\nunzip poc.zip -d poc\ncd poc/poc-F-SIG-JS-TLOGTIME-001\nmake canonical\nmake control\n```\n\n2) confirm `canonical.log` includes:\n\n```\n[CALLSITE_HIT]:\n[PROOF_MARKER]:\n```\n\n3) confirm `control.log` includes:\n\n```\n[NC_MARKER]:\n```\n\n## suggested fix\nOnly treat `integratedTime` as a trusted timestamp when it is cryptographically bound (for example, via a verified signed inclusionPromise/set). For inclusionProof-only entries, do not count `integratedTime` toward `timestampThreshold`, and do not use it for certificate validity decisions unless there is another signed time source (for example, an rfc3161 timestamp).\n\n[poc.zip](https://github.com/user-attachments/files/25643656/poc.zip)\n[PR_DESCRIPTION.md](https://github.com/user-attachments/files/25643660/PR_DESCRIPTION.md)\n[SUBMISSION.md](https://github.com/user-attachments/files/25643662/SUBMISSION.md)",
  "id": "GHSA-xgjw-pm74-86q4",
  "modified": "2026-07-01T19:57:45Z",
  "published": "2026-07-01T19:57:45Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/sigstore/sigstore-js/security/advisories/GHSA-xgjw-pm74-86q4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/sigstore/sigstore-js"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "sigstore-js has Insufficient Verification of Data Authenticity"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.


Detection rules are retrieved from Rulezet.