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
5 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The fix for GHSA-j857-7rvv-vj97 in v1.5.6 is weak in that it does not allow to fully control the amount of plaintext the receiver is willing to deal with and provides just a weak upper bound. The patch limits input token size to 250KB but does not validate the decompressed output size. An unauthenticated attacker can craft a JWE token under the 250KB input limit that decompresses to very large data that may exceed small devices memory availability, causing Denial of Service via memory exhaustion. Although this is technically not unbounded I do recognize that it may be too much for devices and is something that could be surprising to developers, and we can do better than that. NOTE: the original report was sloppy (probably AI slop) and claimed arbitrary memory consumption, but simple testing showed that while 100MB could be decompressed a 1GB output was denied because the token exceeded the 250K compressed serialization. NOTE WELL: The proposed solution was also sloppy,…
Recommended action: Upgrade to 1.5.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Affected version Vendor: https://github.com/latchset/jwcrypto Version: 1.5.5 Description An attacker can cause a DoS attack by passing in a malicious JWE Token with a high compression ratio. When the server processes this Token, it will consume a lot of memory and processing time. Poc It can be found that when processing Tokens with similar lengths, the processing time of compressed tokens is significantly longer. <img width="172" alt="image" src="https://github.com/latchset/jwcrypto/assets/133195620/23193327-3cd7-499a-b5aa-28c56af92785" Mitigation To mitigate this vulnerability, it is recommended to limit the maximum token length to 250K. This approach has also been adopted by the JWT library System.IdentityModel.Tokens.Jwt used in Microsoft Azure [1], effectively preventing attackers from exploiting this vulnerability with high compression ratio tokens. References [1] CVE-2024-21319
Recommended action: Upgrade to 1.5.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Denial of Service, Applications that allow the use of the PBKDF2 algorithm. Patches A patch is available that sets the maximum number of default rounds. Workarounds Applications that do not need to use PBKDF2 should simply specify the algorithms use and exclude it from the list. Applications that need to use the algorithm should upgrade to the new version that allows to set a maximum rounds number. Acknowledgement The issues was reported by Jingcheng Yang and Jianjun Chen from Sichuan University and Zhongguancun Lab
Recommended action: Upgrade to 1.5.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The JWT code can auto-detect the type of token being provided, and this can lead the application to incorrect conclusions about the trustworthiness of the token. Quoting the private disclosure we received : "Under certain circumstances, it is possible to substitute a [..] signed JWS with a JWE that is encrypted with the public key that is normally used for signature validation." This substitution attack can occur only if the validating application also have access to the private key, normally used to sign the tokens, available during validation of the received JWT. The significance of this attacks depends on the use of the token, it may lead to authentication bypass or authorization bypass (respectively if claims are used to authenticate or authorize certain actions), because the attacker has full control of the data placed in the JWE and can inject any desired claim value. Several mitigating factors exist that can protect applications from this issue: - If the private key…
Recommended action: Upgrade to 1.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The Rsa15 class in the RSA 1.5 algorithm implementation in jwa.py in jwcrypto before 0.3.2 lacks the Random Filling protection mechanism, which makes it easier for remote attackers to obtain cleartext data via a Million Message Attack (MMA).
Recommended action: Upgrade to 0.3.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.