GHSA-f9j6-8p6x-r9j6: 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
Enforce key binding to reject on-path Disclosure tampering that invalidates the KB-JWT sd_hash binding.
SD JWT relying party key binding = enforced
Frequently Asked Questions
Which SD JWT JS components and versions are affected?
The issue affects @sd-jwt/decode in version 0.19.0 and earlier. @sd-jwt/core is also affected because it uses @sd-jwt/decode.
Does requiring key binding prevent exploitation?
Key binding prevents an on-path attacker from modifying a Disclosure because modification invalidates the KB-JWT sd_hash. It does not prevent a malicious holder from exploiting the omission behavior, including through SDJwtInstance.verify() when key binding is required.
What disclosure modifications can trigger the issue?
A tampered Disclosure can be silently dropped if its digest no longer matches the issuer-signed _sd array while the issuer signature remains valid. This includes Disclosures that remain valid JSON and Disclosures containing invalid UTF-8 bytes that are decoded with replacement characters.