Affected versions of the cbor2 package are vulnerable to Denial of Service (DoS) due to uncontrolled recursion when decoding deeply nested CBOR data. The cbor2.loads() function creates a CBORDecoder and calls decode(), which dispatches nested Array and Map values to recursive handlers such as decode_array and decode_map without an independent depth-tracking limit in cbor2/decoder.py and source/decoder.c.

Affected versions of the wheel package are vulnerable to Path Traversal due to applying extracted file permissions using an unsanitized archive pathname. The vulnerable logic is in wheel.cli.unpack.unpack (and setuptools._vendor.wheel.cli.unpack.unpack), where the code calls wf.extract(zinfo, destination) but then performs destination.joinpath(zinfo.filename).chmod(permissions) using zinfo.filename directly, allowing dot-dot-slash sequences to escape the intended directory.

Affected versions of the tornado package are vulnerable to Cookie Attribute Injection due to incomplete validation of values passed to the domain, path, and samesite arguments of the RequestHandler.set_cookie method. Specifically, semicolons are not rejected in these parameters, allowing crafted input to inject additional cookie attributes into the Set-Cookie header. An attacker who can influence cookie attribute values can override security-relevant attributes such as Secure, HttpOnly, or SameSite, potentially enabling session fixation or weakening cookie-based access controls.

Affected versions of the Tornado package are vulnerable to Denial of Service (DoS) due to uncontrolled multipart parsing complexity. The vulnerable multipart/form-data parser processes request bodies synchronously on the main thread, and before version 6.5.5 the only effective constraint on the number of multipart sections was max_body_size, which allows an attacker to submit a very large body containing an excessive number of parts and force expensive parsing work.

Affected versions of the tornado package are vulnerable to Improper Input Validation due to incomplete validation of cookie attribute values. The RequestHandler.set_cookie method does not completely validate the domain, path, and samesite arguments, allowing semicolons in these fields that can inject unintended cookie attributes into the resulting Set-Cookie header.

Affected versions of the urllib3 package are vulnerable to Denial of Service (DoS) due to redirect handling that drains connections by decompressing redirect response bodies without enforcing streaming read limits. The issue occurs when using urllib3’s streaming mode (for example, preload_content=False) while allowing redirects, because urllib3.response.HTTPResponse.drain_conn() would call HTTPResponse.read() in a way that decoded/decompressed the entire redirect response body even before any streaming reads were performed, effectively bypassing decompression-bomb safeguards.

Affected versions of the aiohttp package are vulnerable to HTTP Request Smuggling due to the acceptance of duplicate Host headers in incoming HTTP requests. The C extension HTTP parser failed to reject duplicate singleton headers such as Host, Content-Type, and Content-Length, creating parser differentials between the C and pure-Python implementations that could lead to inconsistent request interpretation. An attacker could send a crafted HTTP request containing multiple Host headers to bypass host-based access controls or poison routing decisions in upstream proxies and intermediaries.

Affected versions of the aiohttp package are vulnerable to HTTP Response Splitting due to the default C parser (llhttp) accepting null bytes and control characters in response header values. Specifically, the parser fails to neutralise CRLF sequences and other control characters before including them in outgoing HTTP headers, which means methods such as request.url.origin() may return values that differ from the raw Host header or from what a reverse proxy interpreted. An attacker can craft malicious response headers containing embedded control characters to trigger inconsistent header interpretation, potentially leading to a Security Bypass.

Affected versions of the aiohttp package are vulnerable to HTTP Response Splitting due to improper neutralisation of carriage return characters in the reason phrase of HTTP responses. The Response class does not sanitise the reason parameter, allowing injection of CRLF sequences that can manipulate outgoing HTTP headers. An attacker who controls the reason parameter can inject arbitrary headers into the HTTP response, potentially enabling cache poisoning or response manipulation.

Affected versions of the aiohttp package are vulnerable to Information Disclosure due to improper handling of sensitive headers during cross-origin redirects. When following a redirect to a different origin, the library correctly strips the Authorization header but fails to remove the Cookie and Proxy-Authorization headers, allowing them to be forwarded to the unintended destination. An attacker controlling or observing the redirect target can capture these leaked credentials and session tokens, potentially gaining unauthorised access to user accounts or upstream proxies.

Affected versions of the aiohttp package are vulnerable to Denial of Service due to late enforcement of the client_max_size limit on non-file multipart form fields. When an application uses Request.post() to parse multipart data, the entire field content is read into memory before the size check is applied, allowing oversized payloads to cause significant temporary memory allocation. An attacker can exploit this by sending specially crafted multipart requests to exhaust server memory and degrade service availability.

Affected versions of the aiohttp package are vulnerable to Denial of Service due to insufficient size restrictions on multipart headers. Multipart headers were not subject to the same memory limits enforced for standard HTTP headers, allowing an attacker to send a response containing an excessive number of multipart headers that consume significantly more memory than intended. An attacker could exploit this by crafting a specially formed multipart response to exhaust server memory resources, potentially degrading or disrupting service availability.

Affected versions of the aiohttp package are vulnerable to Server-Side Request Forgery (SSRF) and Information Disclosure due to insufficient path validation in the static resource handler on Windows. The static file serving component fails to properly neutralise UNC path sequences, allowing crafted requests to trigger outbound connections to attacker-controlled SMB servers and leak NTLMv2 credential hashes. An attacker can exploit this by sending a specially crafted request that references a remote UNC path, exposing hashed user credentials and enabling the attacker to read local files on the host system.

Affected versions of the aiohttp package are vulnerable to CRLF Injection due to insufficient sanitization of the content_type parameter during multipart request header construction. An attacker who controls the content_type value passed to a multipart part can embed carriage-return and line-feed characters, allowing arbitrary HTTP headers to be injected into the outgoing request. This can be exploited to manipulate request semantics and perform HTTP Request Splitting when untrusted data is used for the multipart content type.

Affected versions of the aiohttp package are vulnerable to Denial of Service (DoS) due to an unbounded DNS cache in TCPConnector that grows without limit. When an application issues requests to a large number of distinct hosts, the internal DNS resolution cache accumulates entries indefinitely because no maximum size or eviction policy is enforced. An attacker capable of triggering requests to many unique hostnames can cause steadily increasing memory consumption, ultimately degrading or exhausting available resources on the host system.

Affected versions of aiohttp are vulnerable to Uncontrolled Resource Consumption due to insufficient restrictions in header and trailer handling. The vulnerability is in header/trailer handling, where unlimited trailer headers can be processed and cause uncapped memory usage. An attacker can trigger memory exhaustion by sending an attacker-controlled request or response, resulting in reduced availability of the affected service.

Affected versions of the aiohttp package are vulnerable to Denial of Service (DoS) due to unbounded decompression of highly compressed HTTP request bodies when the HTTP parser auto_decompress feature is enabled.

Affected versions of the aiohttp package are vulnerable to Denial of Service (DoS) due to excessive warning-level logging when parsing invalid Cookie headers. When server code accesses aiohttp.web_request.Request.cookies, the aiohttp._cookie_helpers.parse_cookie_header() function validates cookie names and can emit a log entry for each illegal cookie name, enabling a single request to generate a large number of warning logs.

Affected versions of the aiohttp package are vulnerable to Denial of Service (DoS) due to improper enforcement of request size limits during multipart form parsing. The aiohttp aiohttp.web_request.Request.post() method in aiohttp/web_request.py iterates over multipart fields but (prior to the fix) resets its running byte counter per part rather than tracking the total size of the entire multipart form, allowing the aggregate payload to grow without being bounded by client_max_size.

Affected versions of the aiohttp package are vulnerable to Information Disclosure due to static-file path normalisation enabling inference of absolute path component existence. In aiohttp, applications that register a static route via aiohttp.web.static() may expose filesystem path information because the static handler’s normalization and response behaviour lets a requester distinguish which absolute path components exist.

Affected versions of the aiohttp package are vulnerable to Denial of Service (DoS) due to excessive blocking CPU usage when processing a large number of HTTP chunked messages. When an aiohttp server endpoint calls request.read(), the chunked body handling performs costly per-chunk processing that can consume a moderate amount of blocking CPU time (for example, around one second) when the request contains an unusually large number of chunks.

Affected versions of the aiohttp package are vulnerable to Denial of Service (DoS) due to relying on Python assert statements for malformed request handling, which are removed when interpreter optimizations are enabled. The aiohttp.web_request.Request.post() method can trigger an infinite loop in multipart POST body processing because assertions in multipart parsing paths, such as aiohttp.multipart.BodyPartReader.read_chunk() and _read_chunk_from_stream() are bypassed, preventing the code from enforcing an exit condition on invalid EOF and boundary states.

Affected versions of the aiohttp package are vulnerable to Request Smuggling due to Unicode digit matching in the Range header parser. In aiohttp.web_request.BaseRequest.http_range, the Range header is parsed with the regular expression ^bytes=(\d*)-(\d*)$ via re.findall(...) without restricting \d to ASCII, which allows non-ASCII decimal characters to be accepted as valid byte-range values.

Affected versions of the aiohttp package are vulnerable to Request Smuggling due to inconsistent Unicode processing of non-ASCII HTTP header values. In the pure-Python HTTP parser (used when the C extensions are not installed or when AIOHTTP_NO_EXTENSIONS is enabled), aiohttp.http_parser.parse_headers() and helpers such as _is_supported_upgrade() and HttpParser._is_chunked_te() apply .lower() to Upgrade, Transfer-Encoding, and Content-Encoding values without first enforcing ASCII-only input, allowing certain non-ASCII characters to be transformed during case-folding and creating parsing discrepancies.

Affected versions of the requests package are vulnerable to Insecure Temporary File reuse due to predictable temporary filename generation in extract_zipped_paths(). The requests.utils.extract_zipped_paths() utility extracts files from zip archives into the system temporary directory using a deterministic path, and if that file already exists, the function reuses it without validating that it is the expected extracted content.

Affected versions of the pyOpenSSL package are vulnerable to Improper Input Validation due to a failure to securely handle exceptions in a user-supplied callback. The set_tlsext_servername_callback API accepts a callback that, in affected versions, allows an unhandled exception to cause the TLS connection to be accepted instead of rejected, creating a fail-open condition in any security-sensitive logic implemented in that callback.

Affected versions of the pyOpenSSL package are vulnerable to Classic Buffer Overflow due to missing length validation on DTLS cookie values returned by a user-provided callback. The vulnerability is in the DTLS cookie generation path that uses set_cookie_generate_callback, where pyOpenSSL passes the callback’s return value into an OpenSSL-provided buffer without rejecting values longer than 256 bytes.

Affected versions of the cryptography package are vulnerable to Improper Input Validation due to missing prime-order subgroup validation for SECT elliptic-curve points. The public_key_from_numbers, EllipticCurvePublicNumbers.public_key(), load_der_public_key(), and load_pem_public_key() entry points accept attacker-supplied public keys without verifying that the provided point lies in the expected prime-order subgroup, enabling small-subgroup points to pass as valid.

Affected versions of the cryptography package are vulnerable to Improper Certificate Validation due to incomplete enforcement of DNS name constraints on peer names. The certificate validation logic applied DNS name constraints only to Subject Alternative Name (SAN) entries in child certificates, but did not apply the same checks to the peer name presented during validation, which allowed a mismatch between wildcard certificate matching and excluded subtree constraints.

Pyca/cryptography's wheels include a statically linked copy of OpenSSL. The versions of OpenSSL included in cryptography 42.0.0-44.0.0 are vulnerable to a security issue.