CVE-2026-62374 in sd-jwt-js
Summary
by MITRE • 10/29/2026
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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/29/2026
The Selective Disclosure JWT specification, defined in RFC 9901, enables holders to selectively reveal claims from an issuer-signed document while maintaining cryptographic integrity through disclosure objects and hash chains. The JavaScript implementation known as SD JWT JS provides tools for parsing and verifying these documents. In versions prior to 0.20.0 of the core package, a critical logic flaw exists within the decoding mechanism that compromises the security guarantees of selective disclosure. Specifically, when processing disclosures associated with an issuer-signed _sd array, the library fails to strictly validate whether each disclosed claim actually corresponds to a hash entry in the signed structure. Instead of rejecting malformed or tampered inputs as mandated by the standard, the implementation silently discards such invalid disclosures and proceeds to return a reduced set of claims that appear valid because they are derived from the remaining correct entries. This behavior creates a scenario where an attacker can manipulate the payload without triggering verification errors, effectively bypassing integrity checks designed to prevent unauthorized data modification.
The technical root cause lies in how the library handles both syntactically tampered disclosures and those containing invalid character encodings. When a disclosure is altered such that its digest no longer matches the corresponding entry in the issuer-signed _sd array, or when it contains bytes that do not form valid UTF-8 sequences, the decoder does not raise an exception. For cases involving invalid UTF-8, the underlying TextDecoder or Buffer decoding paths substitute replacement characters (U+FFFD), allowing the system to recover syntactically valid JSON data from malformed input. This leniency violates specific requirements of RFC 9901 section 7.1 step 5, which explicitly requires the rejection of unreferenced disclosures that do not match any entry in the _sd array. Furthermore it contravenes sections regarding the validation of disclosure structures themselves. By treating these invalid inputs as valid but empty or filtered out rather than fatal errors, the library undermines the fundamental trust model of SD-JWT where every disclosed claim must be cryptographically bound to the original issuance context.
The operational impact of this vulnerability is significant for applications relying on precise authorization decisions based on selective disclosure claims. An attacker who can intercept and modify traffic between a holder and a relying party may exploit this omission primitive to alter access control outcomes. If the application logic defaults to granting access when specific constraining claims such as age, role, or restrictions are absent rather than denying it, an attacker could strip these critical constraints from the payload by causing them to be silently dropped during decoding. This results in a successful verification of the issuer signature while simultaneously changing the semantic meaning of the presented credentials. The vulnerability is particularly dangerous when key binding is not enforced because standard SD-JWT verification alone does detect on-path tampering if the holder's proof-of-possession mechanism, such as a KB-JWT with an sd_hash binding, is properly implemented and validated by the relying party. However in environments where key binding is optional or incorrectly configured, this flaw allows for undetected privilege escalation or policy bypass.
This issue maps directly to CWE-20 Improper Input Validation within the Common Weakness Enumeration framework, as the system fails to adequately validate input data against expected structural and cryptographic constraints. From an ATT&CK perspective, it facilitates Defense Evasion techniques where attackers manipulate authentication artifacts to maintain access without detection. The vulnerability affects both the standalone sd-jwt/decode package and is utilized by the broader sd-jwt/core library. Mitigation requires upgrading to version 0.20.0 of @sd-jwt/core which corrects the validation logic to strictly reject disclosures that do not match their corresponding hashes in the _sd array or contain invalid encoding sequences. Organizations relying on earlier versions should implement strict input validation at the application layer and ensure that key binding mechanisms are consistently enforced by all relying parties to prevent exploitation through tampered payloads. Until a patched version of the standalone decode package is released, developers must treat any SD-JWT processing using affected libraries as potentially compromised if it does not include additional external verification steps for disclosure integrity.