CVE-2026-65625 in jose
Zusammenfassung
von VulDB • 26.10.2026
Der rein in Erlang implementierte AES-GCM-Fallback in `jose_jwa_aes` leitet die Anzahl der zu überprüfenden Authentifizierungs-Tag-Bits aus dem vom Angreifer bereitgestellten Tag selbst ab. In der `{aes_gcm, Bits}`-Klausel von `block_decrypt/4` wird das eingehende Tag lediglich durch `is_binary/1` abgesichert, ohne eine Längenprüfung vorzunehmen. Die Verifikation in `gcm_block_decrypt/6` berechnet dann `TBits = bit_size(T)` und überprüft nur diese wenigen Bits des tatsächlichen 128-Bit-Tags. Ein Angreifer, der ein JWE-Token kontrolliert, kann das Authentifizierungs-Tag auf so wenig wie 8 Bit kürzen, sodass tatsächlich nur 8 Bits geprüft werden. Dies reduziert die Widerstandsfähigkeit gegen Fälschungen von 2^-128 auf 2^-8, und ein gefälschter Chiffretext wird innerhalb von 256 Versuchen ohne Kenntnis des Schlüssels zuverlässig als authentisch akzeptiert (eine Authentifizierungs-Tag-Fälschung und Umgehung der Integrität). Die Lieferung eines Tags mit mehr als 128 Bits führt stattdessen zu einem `badmatch`, der den entschlüsselnden Prozess abstürzen lässt. Der Fallback wird über den öffentlichen JWE-Decryption-Pfad erreicht, wenn AES-GCM nicht von einer nativen Crypto NIF bereitgestellt wird, beispielsweise auf FIPS- oder gestrippeden bzw. älteren OTP-Builds.
Dieses Problem betrifft jose: ab Version 1.2.0 bis vor 1.11.13.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.