Joserfc
Monthly
Authentication bypass in the joserfc Python library before 1.7.4 lets remote, unauthenticated attackers submit a JWS General JSON Serialization whose "signatures" array is empty and have joserfc.jws.deserialize_json() accept it as authenticated, so relying applications can be fooled into treating an arbitrary attacker-chosen payload as a signed, trustworthy message. Exposure is scoped: only the General JSON Serialization code path is affected - compact JWS, JWT decoding, Flattened JSON serialization, and JWE JSON processing do not reach the vulnerable logic - but where the vulnerable API is used and its success is treated as proof of authenticity, the integrity impact is high (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N per the independent assessment; the published base score is 9.1). No public exploit code or confirmed active exploitation has been identified at time of analysis; the fix commit, tests, and security advisory are publicly available.
Joserfc versions 1.6.2 and earlier fail to validate the PBES2 iteration count parameter in JWE tokens, allowing unauthenticated attackers to trigger CPU exhaustion by specifying arbitrarily large values in the p2c header field. An attacker can exploit this resource exhaustion vulnerability to cause denial of service against any system using the library to decrypt JWE tokens. Public exploit code exists for this vulnerability, and a patch is available.
JWT malleability in joserfc versions 1.7.1 and prior allows a low-privileged user holding a valid token to craft alternate byte-distinct representations by exploiting the library's acceptance of non-conforming trailing Base64 padding (==), which violates the JOSE specification. Applications using deny-list-based token revocation or anti-replay protection are at risk of bypass, since a padding-modified token hashes to a different value that will not match the stored revoked-token record. No public exploit code has been identified and this vulnerability is not listed in CISA KEV; the vendor-released fix is joserfc 1.7.2.
Resource exhaustion in joserfc (versions 1.3.4-1.6.5) is possible because the RFC7797 unencoded-payload (b64=false) JWS code path skips the configured JWSRegistry.max_payload_length check, while the standard compact and flattened JSON paths correctly raise ExceededSizeError. Remotely submitted, cryptographically valid b64=false JWS tokens with arbitrarily large payloads are deserialized without size enforcement, consuming memory or CPU on the verifying server. No public exploit has been identified and the vulnerability is not in the CISA KEV catalog; a vendor-released fix is available in version 1.6.7.
joserfc is a Python library that provides an implementation of several JSON Object Signing and Encryption (JOSE) standards. Rated critical severity (CVSS 9.2), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.
Authentication bypass in the joserfc Python library before 1.7.4 lets remote, unauthenticated attackers submit a JWS General JSON Serialization whose "signatures" array is empty and have joserfc.jws.deserialize_json() accept it as authenticated, so relying applications can be fooled into treating an arbitrary attacker-chosen payload as a signed, trustworthy message. Exposure is scoped: only the General JSON Serialization code path is affected - compact JWS, JWT decoding, Flattened JSON serialization, and JWE JSON processing do not reach the vulnerable logic - but where the vulnerable API is used and its success is treated as proof of authenticity, the integrity impact is high (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N per the independent assessment; the published base score is 9.1). No public exploit code or confirmed active exploitation has been identified at time of analysis; the fix commit, tests, and security advisory are publicly available.
Joserfc versions 1.6.2 and earlier fail to validate the PBES2 iteration count parameter in JWE tokens, allowing unauthenticated attackers to trigger CPU exhaustion by specifying arbitrarily large values in the p2c header field. An attacker can exploit this resource exhaustion vulnerability to cause denial of service against any system using the library to decrypt JWE tokens. Public exploit code exists for this vulnerability, and a patch is available.
JWT malleability in joserfc versions 1.7.1 and prior allows a low-privileged user holding a valid token to craft alternate byte-distinct representations by exploiting the library's acceptance of non-conforming trailing Base64 padding (==), which violates the JOSE specification. Applications using deny-list-based token revocation or anti-replay protection are at risk of bypass, since a padding-modified token hashes to a different value that will not match the stored revoked-token record. No public exploit code has been identified and this vulnerability is not listed in CISA KEV; the vendor-released fix is joserfc 1.7.2.
Resource exhaustion in joserfc (versions 1.3.4-1.6.5) is possible because the RFC7797 unencoded-payload (b64=false) JWS code path skips the configured JWSRegistry.max_payload_length check, while the standard compact and flattened JSON paths correctly raise ExceededSizeError. Remotely submitted, cryptographically valid b64=false JWS tokens with arbitrarily large payloads are deserialized without size enforcement, consuming memory or CPU on the verifying server. No public exploit has been identified and the vulnerability is not in the CISA KEV catalog; a vendor-released fix is available in version 1.6.7.
joserfc is a Python library that provides an implementation of several JSON Object Signing and Encryption (JOSE) standards. Rated critical severity (CVSS 9.2), this vulnerability is remotely exploitable, no authentication required, low attack complexity. Public exploit code available.