Vulnerability-Lookup

GHSA-F9J6-8P6X-R9J6

Vulnerability from github – Published: 2026-11-02 17:54 – Updated: 2026-11-02 17:54

Summary

SD JWT JS: Tampered disclosures silently dropped instead of rejected

Details

Summary

When one Disclosure in an SD-JWT presentation is tampered so its digest no longer matches the Issuer-signed _sd array, @sd-jwt/decode 0.19.0 does not reject the presentation. It silently drops the unmatched Disclosure and returns a reduced claim set, reporting success. The Issuer signature is untouched and valid.

This is a downgrade/omission primitive. A malicious or curious holder can present a tampered Disclosure and have the relying party receive fewer claims than the credential carries, with no error surfaced. Where the relying party does not enforce key binding, an in-transit (on-path) attacker can achieve the same by mangling one Disclosure's bytes; where key binding is enforced, on-path tampering instead breaks the holder's KB-JWT sd_hash binding (so it is rejected), and the downgrade is then exercisable by the key-bound holder — confirmed end-to-end with KB required.

Two distinct tampering inputs converge on the same silent-drop sink:

Genuinely non-decodable Disclosure (broken base64url -> bytes that are not valid UTF-8, e.g. an injected 0xF2 lead byte). RFC 9901 §7.1 step 3 / §4.2.1 require rejection. @sd-jwt/decode instead lossy-decodes it: the TextDecoder/Buffer path substitutes U+FFFD (REPLACEMENT CHARACTER) for the invalid byte and recovers a syntactically valid disclosure (the salt gains a U+FFFD, claim family_name = "Smith"). The recovered Disclosure then hashes to a digest absent from the signed _sd array, so it is silently skipped.
Tampered-but-still-valid-JSON Disclosure (digest no longer matches _sd): same end state — the unmatched Disclosure is silently skipped.

Two RFC 9901 MUSTs compound: - §7.1 step 5 (primary): "If any Disclosure was not referenced by digest value in the Issuer-signed JWT (directly or recursively via other Disclosures), the SD-JWT MUST be rejected." — instead silently dropped. - §7.1 step 3 / §4.2.1 (secondary): a non-base64url-JSON Disclosure MUST be rejected — the lenient lossy decode skips this check.

Confirmed end-to-end through SDJwtInstance.verify() with a real ES256 issuer key, and again with key binding REQUIRED (a valid holder ES256 KB-JWT over aud+nonce+sd_hash).

Impact

Silent claim-set reduction is a downgrade/omission primitive. If a relying party's authorization logic is "default-allow when a constraining claim is absent" (an age / role / restriction attribute), dropping that one Disclosure flips the decision, with no error surfaced. The decoder reporting success on a tampered presentation is the core problem; tampering should be a hard reject. Because SD-JWT VC and the EU EUDIW ARF profiles reuse this disclosure layer, the exposure is to wallet/verifier deployments built on @sd-jwt/*.

Proof of concept (minimized — NOT a weaponized exploit)

A clean single-mutation credential: lowercase _sd_alg: "sha-256", an honest Issuer body whose _sd digests are computed over the valid wire Disclosures, and exactly one wire byte-segment tampered — the family_name Disclosure made genuinely non-decodable (an invalid-UTF-8 0xF2 byte injected into its base64url). Everything else is byte-for-byte valid.

The byte-exact credential cannot be faithfully pasted as text (it deliberately contains the invalid 0xF2 byte that triggers the lossy decode). It is provided as bug3_clean_tampered.cred with an untampered twin bug3_clean_control.cred, plus the minting script mint_bug3_clean.py and a three-oracle harness run_three_oracles.py — shared privately with the maintainer on first reply. Structure: 5 Disclosures, only index 1 (family_name) tampered; all other segments byte-for-byte valid.

Observed on the byte-identical credential (three independent oracles):

Oracle	Version	Verdict	Detail
RFC 9901 reference (pure Python)	reference impl	REJECT	`R_DISCLOSURE_DECODE`
`sd-jwt` (Daniel Fett's reference impl)	pip 0.10.4	REJECT	`UnicodeDecodeError: 0xf2 ... invalid continuation byte`
`@sd-jwt/decode` (this package)	0.19.0	ACCEPT	reduced set `{given_name, email, vct, iss}` — `family_name` silently dropped, no error

Control (untampered, same body): all three oracles ACCEPT the full 5-claim set including family_name: "Smith" — confirming the single tampered byte is the only difference. Liveness: the @sd-jwt/decode harness REJECTs pure garbage ("not-a-jwt", "~~~~", "aaa.bbb.ccc~ZZZZ~", "") and ACCEPTs the clean control, so the ACCEPT above is a genuine behavioral divergence, not an accept-everything stub. No ready-to-run exploit against any deployed verifier is included.

Suggested fix

In the disclosure-decode loop of @sd-jwt/decode: 1. Enforce §7.1 step 5: if any provided Disclosure is not referenced by a digest in the signed _sd array (directly or recursively), reject the entire presentation — do not silently skip it. 2. Enforce §7.1 step 3 / §4.2.1: treat a Disclosure that fails base64url/JSON decode, or that is not a 3-element [salt, claimName, claimValue] array, as a fatal error. Replace the lenient TextDecoder/Buffer decode with a strict UTF-8 decode that throws on invalid bytes (do not substitute U+FFFD). 3. Surface both rejections from the public verify() / decodeSdJwt() entry points, not only from an internal helper.

Related findings in the same library (MEDIUM — context for one combined patch)

Reserved claim name _sd accepted (§7.1 step 3). MEDIUM (conformance, issuer-side). Fix: reject if the claim name is a reserved key (_sd, _sd_alg, ...).
_sd_alg not validated case-sensitively / against the registry (§4.1.1, §7.1 step 2). MEDIUM (defense-in-depth). Accepts sha-1 and SHA-256 (wrong case, silently normalized to sha-256). Fix: exact, case-sensitive membership test against the supported registered set; no case normalization, no silent default.

The maintainer may prefer to address all three in one advisory/patch.

Credit

Found and reported by Anton Sokolov, Tyche Institute (Tallinn, Estonia), ORCID 0000-0003-2452-7096. Discovered via differential fuzzing of the SD-JWT disclosure layer against an RFC 9901 reference oracle and two reference libraries.

Severity

7.1 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@sd-jwt/decode"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.19.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.19.0"
      },
      "package": {
        "ecosystem": "npm",
        "name": "@sd-jwt/core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.20.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-62374"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-176"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-11-02T17:54:39Z",
    "nvd_published_at": "2026-10-29T17:18:10Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\nWhen one Disclosure in an SD-JWT presentation is tampered so its digest no longer matches the Issuer-signed `_sd` array, `@sd-jwt/decode` 0.19.0 does **not** reject the presentation. It silently drops the unmatched Disclosure and returns a **reduced claim set**, reporting success. The Issuer signature is untouched and valid.\n\nThis is a downgrade/omission primitive. A malicious or curious **holder** can present a tampered Disclosure and have the relying party receive *fewer* claims than the credential carries, with no error surfaced. Where the relying party does **not** enforce key binding, an **in-transit (on-path) attacker** can achieve the same by mangling one Disclosure\u0027s bytes; where key binding **is** enforced, on-path tampering instead breaks the holder\u0027s KB-JWT `sd_hash` binding (so it is rejected), and the downgrade is then exercisable by the key-bound holder \u2014 confirmed end-to-end with KB required.\n\nTwo distinct tampering inputs converge on the same silent-drop sink:\n\n1. **Genuinely non-decodable Disclosure** (broken base64url -\u003e bytes that are not valid UTF-8, e.g. an injected `0xF2` lead byte). RFC 9901 \u00a77.1 step 3 / \u00a74.2.1 require rejection. `@sd-jwt/decode` instead **lossy-decodes** it: the `TextDecoder`/`Buffer` path substitutes U+FFFD (REPLACEMENT CHARACTER) for the invalid byte and recovers a syntactically valid disclosure (the `salt` gains a U+FFFD, claim `family_name` = `\"Smith\"`). The recovered Disclosure then hashes to a digest **absent** from the signed `_sd` array, so it is silently skipped.\n2. **Tampered-but-still-valid-JSON Disclosure** (digest no longer matches `_sd`): same end state \u2014 the unmatched Disclosure is silently skipped.\n\nTwo RFC 9901 MUSTs compound:\n- **\u00a77.1 step 5 (primary):** \"If any Disclosure was not referenced by digest value in the Issuer-signed JWT (directly or recursively via other Disclosures), the SD-JWT MUST be rejected.\" \u2014 instead silently dropped.\n- **\u00a77.1 step 3 / \u00a74.2.1 (secondary):** a non-base64url-JSON Disclosure MUST be rejected \u2014 the lenient lossy decode skips this check.\n\nConfirmed end-to-end through `SDJwtInstance.verify()` with a real ES256 issuer key, and again with **key binding REQUIRED** (a valid holder ES256 KB-JWT over `aud`+`nonce`+`sd_hash`).\n\n## Impact\n\nSilent claim-set reduction is a downgrade/omission primitive. If a relying party\u0027s authorization logic is \"default-allow when a constraining claim is absent\" (an age / role / restriction attribute), dropping that one Disclosure flips the decision, with no error surfaced. The decoder reporting **success** on a tampered presentation is the core problem; tampering should be a hard reject. Because SD-JWT VC and the EU EUDIW ARF profiles reuse this disclosure layer, the exposure is to wallet/verifier deployments built on `@sd-jwt/*`.\n\n## Proof of concept (minimized \u2014 NOT a weaponized exploit)\n\nA clean single-mutation credential: lowercase `_sd_alg: \"sha-256\"`, an honest Issuer body whose `_sd` digests are computed over the valid wire Disclosures, and exactly one wire byte-segment tampered \u2014 the `family_name` Disclosure made genuinely non-decodable (an invalid-UTF-8 `0xF2` byte injected into its base64url). Everything else is byte-for-byte valid.\n\nThe byte-exact credential cannot be faithfully pasted as text (it deliberately contains the invalid `0xF2` byte that triggers the lossy decode). It is provided as `bug3_clean_tampered.cred` with an untampered twin `bug3_clean_control.cred`, plus the minting script `mint_bug3_clean.py` and a three-oracle harness `run_three_oracles.py` \u2014 shared privately with the maintainer on first reply. Structure: 5 Disclosures, only index 1 (`family_name`) tampered; all other segments byte-for-byte valid.\n\nObserved on the byte-identical credential (three independent oracles):\n\n| Oracle | Version | Verdict | Detail |\n|---|---|---|---|\n| RFC 9901 reference (pure Python) | reference impl | **REJECT** | `R_DISCLOSURE_DECODE` |\n| `sd-jwt` (Daniel Fett\u0027s reference impl) | pip 0.10.4 | **REJECT** | `UnicodeDecodeError: 0xf2 ... invalid continuation byte` |\n| `@sd-jwt/decode` (this package) | 0.19.0 | **ACCEPT** | reduced set `{given_name, email, vct, iss}` \u2014 `family_name` silently dropped, no error |\n\n**Control (untampered, same body):** all three oracles ACCEPT the full 5-claim set including `family_name: \"Smith\"` \u2014 confirming the single tampered byte is the only difference. **Liveness:** the `@sd-jwt/decode` harness REJECTs pure garbage (`\"not-a-jwt\"`, `\"~~~~\"`, `\"aaa.bbb.ccc~ZZZZ~\"`, `\"\"`) and ACCEPTs the clean control, so the ACCEPT above is a genuine behavioral divergence, not an accept-everything stub. No ready-to-run exploit against any deployed verifier is included.\n\n## Suggested fix\n\nIn the disclosure-decode loop of `@sd-jwt/decode`:\n1. **Enforce \u00a77.1 step 5:** if any provided Disclosure is not referenced by a digest in the signed `_sd` array (directly or recursively), reject the entire presentation \u2014 do not silently skip it.\n2. **Enforce \u00a77.1 step 3 / \u00a74.2.1:** treat a Disclosure that fails base64url/JSON decode, or that is not a 3-element `[salt, claimName, claimValue]` array, as a fatal error. Replace the lenient `TextDecoder`/`Buffer` decode with a strict UTF-8 decode that throws on invalid bytes (do not substitute U+FFFD).\n3. Surface both rejections from the public `verify()` / `decodeSdJwt()` entry points, not only from an internal helper.\n\n## Related findings in the same library (MEDIUM \u2014 context for one combined patch)\n\n- **Reserved claim name `_sd` accepted** (\u00a77.1 step 3). MEDIUM (conformance, issuer-side). Fix: reject if the claim name is a reserved key (`_sd`, `_sd_alg`, ...).\n- **`_sd_alg` not validated case-sensitively / against the registry** (\u00a74.1.1, \u00a77.1 step 2). MEDIUM (defense-in-depth). Accepts `sha-1` and `SHA-256` (wrong case, silently normalized to `sha-256`). Fix: exact, case-sensitive membership test against the supported registered set; no case normalization, no silent default.\n\nThe maintainer may prefer to address all three in one advisory/patch.\n\n## Credit\n\nFound and reported by **Anton Sokolov, Tyche Institute** (Tallinn, Estonia), ORCID 0000-0003-2452-7096. Discovered via differential fuzzing of the SD-JWT disclosure layer against an RFC 9901 reference oracle and two reference libraries.",
  "id": "GHSA-f9j6-8p6x-r9j6",
  "modified": "2026-11-02T17:54:39Z",
  "published": "2026-11-02T17:54:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openwallet-foundation/sd-jwt-js/security/advisories/GHSA-f9j6-8p6x-r9j6"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-62374"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openwallet-foundation/sd-jwt-js/pull/380"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openwallet-foundation/sd-jwt-js/commit/3d8a72a0a279d67439db038c9c2b52621568b866"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openwallet-foundation/sd-jwt-js"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "SD JWT JS: Tampered disclosures silently dropped instead of rejected"
}

CVE-2026-62374 (GCVE-0-2026-62374)

Vulnerability from cvelistv5 – Published: 2026-10-29 16:27 – Updated: 2026-11-04 01:30

Title

SD JWT JS: Tampered disclosures silently dropped instead of rejected

Summary

SD JWT JS is a JavaScript implementation of the Selective Disclosure JWT (SD-JWT) specification. In version 0.19.0 and earlier, `@sd-jwt/decode`, also used by `@sd-jwt/core`, silently drops a tampered Disclosure whose digest no longer matches the Issuer-signed `_sd` array and returns a reduced claim set, reporting success while the Issuer signature remains valid. Both a tampered Disclosure that remains valid JSON and a Disclosure containing invalid UTF-8 bytes reach this silent-drop behavior. In the latter case, the `TextDecoder / Buffer` decoding path substitutes U+FFFD replacement characters, recovering syntactically valid disclosure data instead of rejecting the malformed input. This violates RFC 9901 section 7.1 step 5, which requires rejection of unreferenced Disclosures, and section 7.1 step 3 / section 4.2.1, which require rejection of invalid Disclosures. A malicious holder can exploit this omission primitive, including through `SDJwtInstance.verify()` when key binding is required. An on-path attacker can also tamper with a Disclosure when the relying party does not enforce key binding; enforced key binding rejects on-path tampering because it invalidates the KB-JWT `sd_hash` binding. If the relying party defaults to allowing access when a constraining age, role, or restriction claim is absent, the silent claim reduction can change an authorization decision without an error. This issue is fixed in `@sd-jwt/core` version 0.20.0; no patched version of the standalone `@sd-jwt/decode` package is identified.

Severity

7.1 (High)


                        
                          CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

SSVC

Exploitation: poc Automatable: yes Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-11-04 01:30 UTC

CWE

CWE-754 - Improper Check for Unusual or Exceptional Conditions
CWE-176 - Improper Handling of Unicode Encoding

Assigner

GitHub_M CNA under the mitre root

CNA scorecard C 72/100 over 7868 records in the last 180 days details

References

1 reference

URL	Tags
https://github.com/openwallet-foundation/sd-jwt-j…	x_refsource_CONFIRM

Impacted products

2 products

Vendor	Product	Version
openwallet-foundation	@sd-jwt/core	Affected: <= 0.19.0
openwallet-foundation	@sd-jwt/decode	Affected: <= 0.19.0

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-62374",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "yes"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-11-04T01:30:21.510953Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-11-04T01:30:47.511Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/openwallet-foundation/sd-jwt-js/security/advisories/GHSA-f9j6-8p6x-r9j6"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "@sd-jwt/core",
          "vendor": "openwallet-foundation",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c= 0.19.0"
            }
          ]
        },
        {
          "product": "@sd-jwt/decode",
          "vendor": "openwallet-foundation",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c= 0.19.0"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "SD JWT JS is a JavaScript implementation of the Selective Disclosure JWT (SD-JWT) specification. In version 0.19.0 and earlier, `@sd-jwt/decode`, also used by\u00a0`@sd-jwt/core`, silently drops a tampered Disclosure whose digest no longer matches the Issuer-signed `_sd` array and returns a reduced claim set, reporting success while the Issuer signature remains valid. Both a tampered Disclosure that remains valid JSON and a Disclosure containing invalid UTF-8 bytes reach this silent-drop behavior. In the latter case, the `TextDecoder\u00a0/\u00a0Buffer` decoding path substitutes U+FFFD replacement characters, recovering syntactically valid disclosure data instead of rejecting the malformed input. This violates RFC 9901 section 7.1 step 5, which requires rejection of unreferenced Disclosures, and section 7.1 step 3 / section 4.2.1, which require rejection of invalid Disclosures. A malicious holder can exploit this omission primitive, including through `SDJwtInstance.verify()` when key binding is required. An on-path attacker can also tamper with a Disclosure when the relying party does not enforce key binding; enforced key binding rejects on-path tampering because it invalidates the KB-JWT `sd_hash` binding. If the relying party defaults to allowing access when a constraining age, role, or restriction claim is absent, the silent claim reduction can change an authorization decision without an error. This issue is fixed in `@sd-jwt/core` version 0.20.0; no patched version of the standalone `@sd-jwt/decode` package is identified."
        }
      ],
      "metrics": [
        {
          "cvssV4_0": {
            "attackComplexity": "LOW",
            "attackRequirements": "NONE",
            "attackVector": "NETWORK",
            "baseScore": 7.1,
            "baseSeverity": "HIGH",
            "privilegesRequired": "LOW",
            "subAvailabilityImpact": "NONE",
            "subConfidentialityImpact": "NONE",
            "subIntegrityImpact": "NONE",
            "userInteraction": "NONE",
            "vectorString": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N",
            "version": "4.0",
            "vulnAvailabilityImpact": "NONE",
            "vulnConfidentialityImpact": "NONE",
            "vulnIntegrityImpact": "HIGH"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-754",
              "description": "CWE-754: Improper Check for Unusual or Exceptional Conditions",
              "lang": "en",
              "type": "CWE"
            }
          ]
        },
        {
          "descriptions": [
            {
              "cweId": "CWE-176",
              "description": "CWE-176: Improper Handling of Unicode Encoding",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-29T16:27:40.825Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/openwallet-foundation/sd-jwt-js/security/advisories/GHSA-f9j6-8p6x-r9j6",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/openwallet-foundation/sd-jwt-js/security/advisories/GHSA-f9j6-8p6x-r9j6"
        }
      ],
      "source": {
        "advisory": "GHSA-f9j6-8p6x-r9j6",
        "discovery": "UNKNOWN"
      },
      "title": "SD JWT JS: Tampered disclosures silently dropped instead of rejected"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-62374",
    "datePublished": "2026-10-29T16:27:40.825Z",
    "dateReserved": "2026-07-13T22:04:59.678Z",
    "dateUpdated": "2026-11-04T01:30:47.511Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

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.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

How durations are calculated

Following the VTEM framework (Black Hat USA 2015), time to patch starts when the vendor or a coordinator was informed, total time to patch at discovery, and disclosure to patch at public disclosure; vendor response time runs from the report to its acknowledgement. Time to exploit and time unpatched start at the earliest discovery or report, falling back to public disclosure. Unpatched time ends at the first recorded patch, or the calculation time when no patch is recorded. Exploitation to patch shows the interval between those two events; a published proof of concept is a public exploit, not exploitation.

Each result shows its source dates. A negative interval means the end event came first; when date-only inputs leave the order open, the result says so. Date-only inputs are approximate. The earliest evidence wins: KEV report dates and sightings are labelled as such. Records describing another vulnerability are listed but never calculated from, and a PoC alone does not establish exploitation. Missing patch evidence does not prove that no patch exists. Filters below change the event list only.

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

GHSA-F9J6-8P6X-R9J6

Summary

Impact

Proof of concept (minimized — NOT a weaponized exploit)

Suggested fix

Related findings in the same library (MEDIUM — context for one combined patch)

Credit

CVE-2026-62374 (GCVE-0-2026-62374)

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour