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
6 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
joserfc 1.7.4 defines compact-JWS header, payload, and signature limits, but calls `value.split(b".")` before validating them. Python `bytes.split()` copies the attacker-controlled segments, so the current guard allocates roughly one complete payload before rejecting it. Reproduction ```bash .venv-research/bin/python 06-practical-testing/preauth-memory-profile.py ``` The input is resident before a fork-isolated verifier runs, and every signature is invalid. | Input | Peak RSS delta | Amplification | Result | |---:|---:|---:|---| | 1 MiB | 1.11 MiB | 1.11× | size rejected | | 4 MiB | 4.04 MiB | 1.01× | size rejected | | 8 MiB | 8.04 MiB | 1.01× | size rejected | | 16 MiB | 16.04 MiB | 1.00× | size rejected | | 32 MiB | 31.74 MiB | 0.99× | size rejected | | 64 MiB | 63.80 MiB | 1.00× | size rejected | The unconstrained profile is the primary evidence: joserfc allocates an additional attacker-sized object before producing its intended `ExceededSizeError`. A separate…
Recommended action: Upgrade to 1.7.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
`joserfc.jwe.decrypt_json()`, the library's public parser for JWE General JSON Serialization, accepts an attacker-controlled `recipients` array of unbounded length and performs one full private-key decryption operation (`decrypt_cek`) for every recipient present in the input, with no cap on recipient count. An unauthenticated network attacker who can send a JWE General JSON document to any endpoint that decrypts it with an RSA key (e.g. RSA-OAEP) can force the victim to perform an arbitrary, attacker-chosen number of RSA private-key decryption operations from a single, relatively small HTTP request. This gives the attacker a highly asymmetric CPU-exhaustion (Denial of Service) primitive: local reproduction shows request size growing linearly with recipient count (~396 bytes/recipient) while server-side CPU time grows in lock-step (near 1:1 ratio between recipient-count growth and decrypt-time growth), and the library's only documented mitigation knob,…
Recommended action: Upgrade to 1.7.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
joserfc.jwt.decode accepts attacker-forged HMAC-signed tokens when the caller-supplied verification key is the empty string or None. HMACAlgorithm.sign and HMACAlgorithm.verify in src/joserfc/rfc7518/jwsalgs.py:62-70 feed whatever OctKey.getopkey(...) produced into hmac.new(...), and OctKey.importkey only emits a SecurityWarning when the raw key is shorter than 14 bytes without rejecting zero-length input. Any application whose JWT secret is sourced from an unset environment variable, an unset Redis / DB row, a key finder fallback that returns "", or a Hash.new("")-style default verifies attacker tokens forged with HMAC(key=b"", signinginput) because the attacker trivially reproduces the same digest with no secret knowledge. This is a cross-language sibling of jwt/ruby-jwt GHSA-c32j-vqhx-rx3x / CVE-2026-45363 (HS256/HS384/HS512 verify accepted an empty/nil HMAC key, filed 2026-05-13). ruby-jwt v3.2.0 added an ensurevalidkey! precondition that rejects empty keys at both sign…
Recommended action: Upgrade to 1.6.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
RFC7797 b64=false JWS payloads bypass JWSRegistry payload-size limits during deserialization Summary Testing revealed that joserfc accepts oversized RFC7797 b64=false JWS payloads without applying JWSRegistry.maxpayloadlength. 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.maxpayloadlength. This creates a moderate availability/resource-exhaustion risk for applications that accept lower-trust JWS values and rely on joserfc to reject oversized token content during verification. Affected Product - Package: joserfc - Ecosystem: pip - Audited release: 1.6.5 - Audit tag: 1.6.5 - Audit commit: 881712980934fb601bed26fe3ae1ec0b7780e6f7 - Tested affected releases: 1.3.4, 1.3.5, 1.4.2, 1.6.2, 1.6.3, 1.6.4, 1.6.5 - Fixed release:…
Recommended action: Upgrade to 1.6.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details Vulnerable file: src/joserfc/rfc7518/jwealgs.py Vulnerable function: PBES2HSAlgKeyEncryption.decryptcek() Lines: 283 The p2c value is then passed to computederivedkey : Impact on JWT…
Recommended action: Upgrade to 1.6.3 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. Details 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 per se. It is therefore the responsibility of the underlying web server…
Recommended action: Upgrade to 1.4.2 or 1.3.5 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.