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 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.