CVE-2026-119283

joserfc is a Python library that provides an implementation of several JSON Object Signing and Encryption (JOSE) standards. Prior to 1.7.5, joserfc.jwe.decrypt_json() accepts a JWE General JSON Serialization recipients array without a count limit and calls decrypt_cek() for every entry. An unauthenticated attacker who can submit a JWE to an endpoint using an RSA key-management algorithm can choose the number of private-key decryption operations performed by one request. The verify_all_recipients option does not reduce this work because the affected loop processes every recipient before consulting that setting, allowing repeated requests to exhaust service CPU without affecting confidentiality or integrity. This issue is fixed in version 1.7.5.

joserfc is a Python library that provides an implementation of several JSON Object Signing and Encryption (JOSE) standards. Prior to 1.7.5, joserfc.jwe.decrypt_json() accepts a JWE General JSON Serialization recipients array without a count limit and calls decrypt_cek() for every entry. An unauthenticated attacker who can submit a JWE to an endpoint using an RSA key-management algorithm can choose the number of private-key decryption operations performed by one request. The verify_all_recipients option does not reduce this work because the affected loop processes every recipient before consulting that setting, allowing repeated requests to exhaust service CPU without affecting confidentiality or integrity. This issue is fixed in version 1.7.5.

Summary

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, verify_all_recipients=False, does not reduce the CPU cost, since the decrypt loop attempts every recipient's decrypt_cek() unconditionally before that flag is ever consulted. This is CWE-400 (Uncontrolled Resource Consumption) with CVSS v3.1 Base Score 7.5 (High).

Details

joserfc validates and caps several structural elements of a JWE (protected header size, encrypted key size, IV size, ciphertext size, and auth-tag size) inside src/joserfc/_rfc7516/registry.py, but performs no validation whatsoever on the number of entries in the recipients array of a JWE General JSON Serialization object.

Data flow (source → sink), verified directly against the repository source at commit 26a10275e88276184f91ae2a6409647bfac7fea5 (joserfc 1.7.4):

1. src/joserfc/jwe.py:214 — public parser entry point decrypt_json(data, private_key, ...). This is a documented, unauthenticated (at the library boundary) API for parsing externally supplied JWE JSON.
2. src/joserfc/jwe.py:238 — if "recipients" is present in the input dict, extract_general_json(...) is invoked.
3. src/joserfc/_rfc7516/json.py:84-86 — iterates for item in data["recipients"]: and appends a Recipient object for every entry, with no upper bound check on len(data["recipients"]):

   for item in data["recipients"]:
       recipient = __extract_recipient(obj, item, registry)
       obj.recipients.append(recipient)
   

4. src/joserfc/jwe.py:252 — the private key is attached to every extracted recipient.
5. src/joserfc/_rfc7516/message.py:103-112 — _perform_decrypt() loops over every recipient in obj.recipients and calls decrypt_recipient(...) for each one, regardless of how many there are:

   cek_set = set()
   for recipient in obj.recipients:
       headers = recipient.headers()
       registry.check_header(headers, True)
       alg = registry.get_alg(headers["alg"])
       try:
           cek = decrypt_recipient(alg, enc, recipient, tag)
           cek_set.add(cek)
   

6. src/joserfc/_rfc7518/jwe_algs.py:74-83 — for RSA-OAEP/RSA1_5 recipients, this dispatches to the sink, a genuine RSA private-key operation:

   def decrypt_cek(self, recipient: Recipient[RSAKey]) -> bytes:
       key = recipient.recipient_key
       assert key is not None
       self.check_key_type(key)
       op_key = key.get_op_key("decrypt")
       try:
           assert recipient.encrypted_key is not None
           cek = op_key.decrypt(recipient.encrypted_key, self.padding)
   

Confirmed by direct inspection of src/joserfc/_rfc7516/registry.py: size caps exist for max_header_length, max_encrypted_key_length, max_iv_length, max_ciphertext_length, and max_auth_tag_length (registry.py:52-62, 103-121), but no max_recipients (or equivalent) field or check exists anywhere in registry.py, json.py, or jwe.py.

Critically, the loop in message.py:103-112 calls decrypt_recipient() for every recipient…

joserfc is a Python library that provides an implementation of several JSON Object Signing and Encryption (JOSE) standards. Prior to 1.7.5, joserfc.jwe.decrypt_json() accepts a JWE General JSON Serialization recipients array without a count limit and calls decrypt_cek() for every entry. An unauthenticated attacker who can submit a JWE to an endpoint using an RSA key-management algorithm can choose the number of private-key decryption operations performed by one request. The verify_all_recipients option does not reduce this work because the affected loop processes every recipient before consulting that setting, allowing repeated requests to exhaust service CPU without affecting confidentiality or integrity. This issue is fixed in version 1.7.5.

joserfc is a Python library that provides an implementation of several JSON Object Signing and Encryption (JOSE) standards. Prior to 1.7.5, joserfc.jwe.decrypt_json() accepts a JWE General JSON Serialization recipients array without a count limit and calls decrypt_cek() for every entry. An unauthenticated attacker who can submit a JWE to an endpoint using an RSA key-management algorithm can choose the number of private-key decryption operations performed by one request. The verify_all_recipients option does not reduce this work because the affected loop processes every recipient before consulting that setting, allowing repeated requests to exhaust service CPU without affecting confidentiality or integrity. This issue is fixed in version 1.7.5.

joserfc is a Python library that provides an implementation of several JSON Object Signing and Encryption (JOSE) standards. Prior to 1.7.5, joserfc.jwe.decrypt_json() accepts a JWE General JSON Serialization recipients array without a count limit and calls decrypt_cek() for every entry. An unauthenticated attacker who can submit a JWE to an endpoint using an RSA key-management algorithm can choose the number of private-key decryption operations performed by one request. The verify_all_recipients option does not reduce this work because the affected loop processes every recipient before consulting that setting, allowing repeated requests to exhaust service CPU without affecting confidentiality or integrity. This issue is fixed in version 1.7.5.

Summary

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, verify_all_recipients=False, does not reduce the CPU cost, since the decrypt loop attempts every recipient's decrypt_cek() unconditionally before that flag is ever consulted. This is CWE-400 (Uncontrolled Resource Consumption) with CVSS v3.1 Base Score 7.5 (High).

Details

joserfc validates and caps several structural elements of a JWE (protected header size, encrypted key size, IV size, ciphertext size, and auth-tag size) inside src/joserfc/_rfc7516/registry.py, but performs no validation whatsoever on the number of entries in the recipients array of a JWE General JSON Serialization object.

Data flow (source → sink), verified directly against the repository source at commit 26a10275e88276184f91ae2a6409647bfac7fea5 (joserfc 1.7.4):

1. src/joserfc/jwe.py:214 — public parser entry point decrypt_json(data, private_key, ...). This is a documented, unauthenticated (at the library boundary) API for parsing externally supplied JWE JSON.
2. src/joserfc/jwe.py:238 — if "recipients" is present in the input dict, extract_general_json(...) is invoked.
3. src/joserfc/_rfc7516/json.py:84-86 — iterates for item in data["recipients"]: and appends a Recipient object for every entry, with no upper bound check on len(data["recipients"]):

   for item in data["recipients"]:
       recipient = __extract_recipient(obj, item, registry)
       obj.recipients.append(recipient)
   

4. src/joserfc/jwe.py:252 — the private key is attached to every extracted recipient.
5. src/joserfc/_rfc7516/message.py:103-112 — _perform_decrypt() loops over every recipient in obj.recipients and calls decrypt_recipient(...) for each one, regardless of how many there are:

   cek_set = set()
   for recipient in obj.recipients:
       headers = recipient.headers()
       registry.check_header(headers, True)
       alg = registry.get_alg(headers["alg"])
       try:
           cek = decrypt_recipient(alg, enc, recipient, tag)
           cek_set.add(cek)
   

6. src/joserfc/_rfc7518/jwe_algs.py:74-83 — for RSA-OAEP/RSA1_5 recipients, this dispatches to the sink, a genuine RSA private-key operation:

   def decrypt_cek(self, recipient: Recipient[RSAKey]) -> bytes:
       key = recipient.recipient_key
       assert key is not None
       self.check_key_type(key)
       op_key = key.get_op_key("decrypt")
       try:
           assert recipient.encrypted_key is not None
           cek = op_key.decrypt(recipient.encrypted_key, self.padding)
   

Confirmed by direct inspection of src/joserfc/_rfc7516/registry.py: size caps exist for max_header_length, max_encrypted_key_length, max_iv_length, max_ciphertext_length, and max_auth_tag_length (registry.py:52-62, 103-121), but no max_recipients (or equivalent) field or check exists anywhere in registry.py, json.py, or jwe.py.

Critically, the loop in message.py:103-112 calls decrypt_recipient() for every recipient…

joserfc is a Python library that provides an implementation of several JSON Object Signing and Encryption (JOSE) standards. Prior to 1.7.5, joserfc.jwe.decrypt_json() accepts a JWE General JSON Serialization recipients array without a count limit and calls decrypt_cek() for every entry. An unauthenticated attacker who can submit a JWE to an endpoint using an RSA key-management algorithm can choose the number of private-key decryption operations performed by one request. The verify_all_recipients option does not reduce this work because the affected loop processes every recipient before consulting that setting, allowing repeated requests to exhaust service CPU without affecting confidentiality or integrity. This issue is fixed in version 1.7.5.