Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
This vulnerability allows an attacker with a trusted public key to cause a Denial-of-Service (DoS) condition by crafting a malicious JSON Web Encryption (JWE) token with an exceptionally high compression ratio. When this token is processed by the recipient, it results in significant memory allocation and processing time during decompression. Details The attacker needs to obtain a valid public key to compress the payload. It needs to be valid so that the recipient can use to successfully decompress the payload. Furthermore in context JWT processing in the v2 versions, the recipient must explicitly allow JWE handling . The attacker then crafts a message with high compression ratio, e.g. a payload with very high frequency of repeating patterns that can decompress to a much larger size. If the payload is large enough, recipient who is decompressing the data will have to allocate a large amount of memory, which then can lead to a denial of service. The original report includes a…
Recommended action: Upgrade to 2.0.21 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Calling jws.Parse with a JSON serialized payload where the signature field is present while protected is absent can lead to a nil pointer dereference. Details This seems to also affect other functions that calls Parse internally, like jws.Verify. My understanding of these functions from the docs is that they are supposed to fail gracefully on invalid input and don't require any prior validation. Based on the stack trace in the PoC, the issue seems to be that the processing done in jws/message.go:UnmarshalJSON() assumes that if a signature field is present, then a protected field is also present. If this is not the case, then the subsequent call to getB64Value(sig.protected) will dereference sig.protected, which is nil. PoC Reproducer: Result: Impact The vulnerability can be used to crash / DOS a system doing JWS verification.
Recommended action: Upgrade to 2.0.19 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
too high p2c parameter in JWE's alg PBES2- could lead to a DOS attack Details The JWE key management algorithms based on PBKDF2 require a JOSE Header Parameter called p2c (PBES2 Count). This parameter dictates the number of PBKDF2 iterations needed to derive a CEK wrapping key. Its primary purpose is to intentionally slow down the key derivation function, making password brute-force and dictionary attacks more resource- intensive. Therefore, if an attacker sets the p2c parameter in JWE to a very large number, it can cause a lot of computational consumption, resulting in a DOS attack PoC Impact It's a kind of Dos attack, the user's environment could potentially utilize an excessive amount of CPU resources.
Recommended action: Upgrade to 2.0.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Decrypting AES-CBC encrypted JWE has Potential Padding Oracle Attack Vulnerability. Details On v2.0.10, decrypting AES-CBC encrypted JWE may return an error "failed to generate plaintext from decrypted blocks: invalid padding": https://github.com/lestrrat-go/jwx/blob/8840ffd4afc5839f591ff0e9ba9034af52b1643e/jwe/internal/aescbc/aescbc.go#L210-L213 Reporting padding error causes Padding Oracle Attack Vulnerability. RFC 7516 JSON Web Encryption (JWE) says that we MUST NOT do this. 11.5. Timing Attacks To mitigate the attacks described in RFC 3218 [RFC3218], the recipient MUST NOT distinguish between format, padding, and length errors of encrypted keys. It is strongly recommended, in the event of receiving an improperly formatted key, that the recipient substitute a randomly generated CEK and proceed to the next step, to mitigate timing attacks. In addition, the time to remove padding depends on the length of the padding. It may leak the length of the padding by Timing Attacks.…
Recommended action: Upgrade to 2.0.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.