Threat Intelligence Database

A vulnerability in the authlib joserfc Python library prior to version 1.7.3 allows issuer-validation bypass due to improper handling of array-valued 'iss' claims in JWT token validation. This can lead to authentication bypass by spoofing the issuer claim. The issue is fixed in version 1.7.3.

The joserfc Python library versions 1.7.1 and earlier accept JSON Web Tokens (JWTs) with trailing padding characters (==), which violates JOSE specifications and causes token malleability. This malleability can potentially allow bypassing token revocation or anti-replay protections that rely on deny lists of tokens or token hashes. The issue has been fixed in version 1.7.2.

This update includes the following RPMs: jaeger: * jaeger-2.19.0-1.2.hum1 (aarch64, x86_64) * jaeger-2.19.0-1.2.hum1.src (src) Security Fix(es): jaeger: * CVE-2026-49852

joserfc is a Python library that provides an implementation of several JSON Object Signing and Encryption (JOSE) standards. In versions 1.3.4 through 1.6.5, joserfc accepts oversized RFC7797 b64=false JWS payloads without applying JWSRegistry.max_payload_length, which can lead to resource exhaustion. The normal JWS compact and flattened JSON paths reject payloads above the configured payload-size limit with ExceededSizeError. The RFC7797 unencoded payload paths do not make the same check. A valid b64=false compact or flattened JSON JWS can therefore deserialize successfully with a payload larger than JWSRegistry.max_payload_length. Applications that accept lower-trust JWS values and rely on joserfc to reject oversized token content during verification have a moderate availability risk. This issue has been fixed in version 1.6.7.

joserfc is a Python library that provides an implementation of several JSON Object Signing and Encryption (JOSE) standards. In 1.6.2 and earlier, a resource exhaustion vulnerability in joserfc allows an unauthenticated attacker to cause a Denial of Service (DoS) via CPU exhaustion. When the library decrypts a JSON Web Encryption (JWE) token using Password-Based Encryption (PBES2) algorithms, it reads the p2c (PBES2 Count) parameter directly from the token's protected header. This parameter defines the number of iterations for the PBKDF2 key derivation function. Because joserfc does not validate or bound this value, an attacker can specify an extremely large iteration count (e.g., 2^31 - 1), forcing the server to expend massive CPU resources processing a single token. This vulnerability exists at the JWA layer and impacts all high-level JWE and JWT decryption interfaces if PBES2 algorithms are allowed by the application's policy.

HighVulnerabilityUnited StatesGermanyUnited Kingdom+7#cve#cve-2026-27932#cwe-770

joserfc is a Python library that provides an implementation of several JSON Object Signing and Encryption (JOSE) standards. In versions from 1.3.3 to before 1.3.5 and from 1.4.0 to before 1.4.2, the ExceededSizeError exception messages are embedded with non-decoded JWT token parts and may cause Python logging to record an arbitrarily large, forged JWT payload. In situations where a misconfigured — or entirely absent — production-grade web server sits in front of a Python web application, an attacker may be able to send arbitrarily large bearer tokens in the HTTP request headers. When this occurs, Python logging or diagnostic tools (e.g., Sentry) may end up processing extremely large log messages containing the full JWT header during the joserfc.jwt.decode() operation. The same behavior also appears when validating claims and signature payload sizes, as the library raises joserfc.errors.ExceededSizeError() with the full payload embedded in the exception message. Since the payload is already fully loaded into memory at this stage, the library cannot prevent or reject it. This issue has been patched in versions 1.3.5 and 1.4.2.

CriticalVulnerabilityGermanyFranceUnited Kingdom+3#cve#cve-2025-65015#cwe-770