jose < v6.0.10 was discovered to contain weak encryption.

gistfile1.txt

CVE: CVE-2025-45767
Description:
we found that the HMAC and RSA key lengths used in your JSON Web Signature (JWS) implementation do not meet recommended security standards(RFC 7518、NIST SP800-117、RFC 2437). According to CWE-326 (Inadequate Encryption Strength), using keys that are too short can lead to serious vulnerabilities and potential attacks.
Affected versions: <= v6.0.10
Reference: https://github.com/panva/jose/security/advisories/GHSA-mwmr-4mj7-4hv7

I've responded to this report back in April and have not heard back from the reporter since.

The report's description is inaccurate and false since the jose module does enforce RSA key sizes and always has for all currently supported major versions.

As far as HMAC key sizes go I responded with the following and would say that symmetric secret key length enforcement is generally put forth on the user, not the module. This exact same report has been received by a number of other libraries in the JOSE ecosystem and my $.02 is they should all be rejected.

My response from back in April follows:

Hello

I've had HMAC key length enforcement at the library level in the past (a number of times actually) and every time it ended up being contentious with users and eventually relaxed because at a library level its enforcement is ineffective at best and only serves to be a nuisance rather than a security measure.

Consider an existing system where the user upgrades the module and now their HMAC secret is rejected. Naturally the thing they'll do is look for workarounds or other libraries (of which there are plenty they can still use and the chances that all libraries would start rejecting short secrets is zero) rather than go around rotating secrets everywhere.

And the workaround they'll employ is rather simple too, users will just pad the secret buffer with zeros to the minimum length and voila, their existing secret looks as if it's the correct minimum size, which it isn't, the library has no ground to reject it anymore, and their HMAC output doesn't change because this minimum padding is a function of the underlying HMAC algorithm in the first place. This is the case for its OpenSSL implementation, Web Cryptography API, and others.

In the meantime the algorithm key requirements clearly state the correct key length and the generateSecret function likewise generates secrets of appropriate length and entropy. So users are guided to use secrets of appropriate lengths every chance they get but if they choose not to, that's clearly on them.

Furthermore the usage of HMAC inside other algorithms prescribed by the JWA spec is also conflicting with this guidance. Namely, in the AES_CBC_HMAC_SHA2 Algorithms JWE algorithm where a 16 byte secret is used for its internal SHA-256 HMAC tag generation (e.g. in A128CBC-HS256)

For the reasons above I am of a strong belief that this shouldn't have been assigned in the first place and have requested this CVE be rejected.

See panva/jose#813

@panva I agree with your remarks.
When this post initially appeared I was a little alarmed since the advisory is not public. Can it be made public but closed?

@simhnna

There is no need to be alarmed which is why I opened panva/jose#813 while also disputing the CVE.