CVE-2026-62374: SD JWT JS: Tampered disclosures silently dropped instead of rejected
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 sdhash 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.
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
@sd-jwt/coreto a version that resolves this vulnerability.Fixed in 0.20.0 - Configuration
Require and enforce key binding during verification to reject on-path Disclosure tampering through the KB-JWT sd_hash binding.
SD JWT relying party key binding = required/enforced
Event History
Frequently Asked Questions
Which applications are affected?
Applications using @sd-jwt/decode are affected through version 0.19.0. Applications using @sd-jwt/core are also affected because it uses @sd-jwt/decode.
Who can exploit this behavior?
A malicious holder can exploit the omission primitive, including when SDJwtInstance.verify() requires key binding. An on-path attacker can tamper with a Disclosure only when the relying party does not enforce key binding.
Does enforcing key binding prevent network tampering?
Yes. Enforced key binding rejects on-path Disclosure tampering because the modification invalidates the KB-JWT sd_hash. It does not prevent exploitation by a malicious holder.