Affected versions of `aiohttp` are vulnerable to an infinite loop condition. This occurs when an attacker sends a specially crafted POST (multipart/form-data) request. Upon processing, the `aiohttp` server enters an infinite loop, preventing it from processing further requests. This results in a denial-of-service (DoS) attack, allowing an attacker to stop the application from serving requests after a single request. Users are advised to upgrade to version 3.9.4 or manually apply a patch to their systems as per the linked GHSA instructions.

Affected versions of `aiohttp` are vulnerable to an Improper Validation vulnerability. It is possible for an attacker to modify the HTTP request (e.g. insert a new header) or even create a new HTTP request if the attacker controls the HTTP method. The vulnerability occurs only if the attacker can control the HTTP method (GET, POST etc.) of the request. If the attacker can control the HTTP version of the request it will be able to modify the request (request smuggling).

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 Improper Input Validation due to insufficient checks on the HTTP version of incoming requests. The vulnerability arises because the HTTP request handling mechanism does not adequately validate the HTTP version, allowing manipulation if controlled by an attacker. An attacker with the ability to influence the HTTP version can exploit this flaw to inject new headers or craft entirely new HTTP requests, potentially leading to unauthorized actions or data exposure.

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

AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.12.14, the Python parser is vulnerable to a request smuggling vulnerability due to not parsing trailer sections of an HTTP request. If a pure Python version of aiohttp is installed (i.e. without the usual C extensions) or AIOHTTP_NO_EXTENSIONS is enabled, then an attacker may be able to execute a request smuggling attack to bypass certain firewalls or proxy protections. Version 3.12.14 contains a patch for this issue.

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 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 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 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 Cross-site Scripting (XSS) due to improper sanitization of user input on index pages for static file handling. The vulnerability exists because the `show_index` option, when enabled, allows unsanitized user input to be rendered directly into the HTML content of directory listings. An attacker can exploit this vulnerability by crafting a malicious URL that, when accessed, executes arbitrary JavaScript in the context of the user's browser, potentially leading to session hijacking or data theft.

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 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 aiohttp are vulnerable to HTTP Request Smuggling (CWE-444). This vulnerability allows attackers to inject malicious HTTP messages by including line feeds (LF) in chunk extensions, potentially bypassing security controls and executing unauthorized actions. The attack vector involves sending specially crafted chunked HTTP requests to exploit the improper parsing in the HttpPayloadParser class. To mitigate, upgrade to aiohttp version which validates chunk extensions by rejecting any containing unexpected LFs, thereby preventing request smuggling attacks.

The vulnerability lies in the improper configuration of static resource resolution when aiohttp is used as a web server. It occurs when the follow_symlinks option is enabled without proper validation, leading to directory traversal vulnerabilities. Unauthorized access to arbitrary files on the system could potentially occur. The affected versions are >1.0.5, and the issue was patched in version 3.9.2. As a workaround, it is advised to disable the follow_symlinks option outside of a restricted local development environment, especially in a server accepting requests from remote users. Using a reverse proxy server to handle static resources is also recommended.
https://github.com/aio-libs/aiohttp/commit/1c335944d6a8b1298baf179b7c0b3069f10c514b

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.

The aiohttp versions minor than 3.9. has a vulnerability that affects the Python HTTP parser used in the aiohttp library. It allows for minor differences in allowable character sets, which could lead to robust frame boundary matching of proxies to protect against the injection of additional requests. The vulnerability also allows 
 exceptions during validation that aren't handled consistently with other malformed inputs.

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 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 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 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 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 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 `aiohttp` are vulnerable to an infinite loop condition. This occurs when an attacker sends a specially crafted POST (multipart/form-data) request. Upon processing, the `aiohttp` server enters an infinite loop, preventing it from processing further requests. This results in a denial-of-service (DoS) attack, allowing an attacker to stop the application from serving requests after a single request. Users are advised to upgrade to version 3.9.4 or manually apply a patch to their systems as per the linked GHSA instructions.

Affected versions of `aiohttp` are vulnerable to an Improper Validation vulnerability. It is possible for an attacker to modify the HTTP request (e.g. insert a new header) or even create a new HTTP request if the attacker controls the HTTP method. The vulnerability occurs only if the attacker can control the HTTP method (GET, POST etc.) of the request. If the attacker can control the HTTP version of the request it will be able to modify the request (request smuggling).

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 Improper Input Validation due to insufficient checks on the HTTP version of incoming requests. The vulnerability arises because the HTTP request handling mechanism does not adequately validate the HTTP version, allowing manipulation if controlled by an attacker. An attacker with the ability to influence the HTTP version can exploit this flaw to inject new headers or craft entirely new HTTP requests, potentially leading to unauthorized actions or data exposure.

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

AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.12.14, the Python parser is vulnerable to a request smuggling vulnerability due to not parsing trailer sections of an HTTP request. If a pure Python version of aiohttp is installed (i.e. without the usual C extensions) or AIOHTTP_NO_EXTENSIONS is enabled, then an attacker may be able to execute a request smuggling attack to bypass certain firewalls or proxy protections. Version 3.12.14 contains a patch for this issue.

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 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 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 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 Cross-site Scripting (XSS) due to improper sanitization of user input on index pages for static file handling. The vulnerability exists because the `show_index` option, when enabled, allows unsanitized user input to be rendered directly into the HTML content of directory listings. An attacker can exploit this vulnerability by crafting a malicious URL that, when accessed, executes arbitrary JavaScript in the context of the user's browser, potentially leading to session hijacking or data theft.

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 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 aiohttp are vulnerable to HTTP Request Smuggling (CWE-444). This vulnerability allows attackers to inject malicious HTTP messages by including line feeds (LF) in chunk extensions, potentially bypassing security controls and executing unauthorized actions. The attack vector involves sending specially crafted chunked HTTP requests to exploit the improper parsing in the HttpPayloadParser class. To mitigate, upgrade to aiohttp version which validates chunk extensions by rejecting any containing unexpected LFs, thereby preventing request smuggling attacks.

The vulnerability lies in the improper configuration of static resource resolution when aiohttp is used as a web server. It occurs when the follow_symlinks option is enabled without proper validation, leading to directory traversal vulnerabilities. Unauthorized access to arbitrary files on the system could potentially occur. The affected versions are >1.0.5, and the issue was patched in version 3.9.2. As a workaround, it is advised to disable the follow_symlinks option outside of a restricted local development environment, especially in a server accepting requests from remote users. Using a reverse proxy server to handle static resources is also recommended.
https://github.com/aio-libs/aiohttp/commit/1c335944d6a8b1298baf179b7c0b3069f10c514b

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.

The aiohttp versions minor than 3.9. has a vulnerability that affects the Python HTTP parser used in the aiohttp library. It allows for minor differences in allowable character sets, which could lead to robust frame boundary matching of proxies to protect against the injection of additional requests. The vulnerability also allows 
 exceptions during validation that aren't handled consistently with other malformed inputs.

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 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 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 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 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 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 `aiohttp` are vulnerable to an infinite loop condition. This occurs when an attacker sends a specially crafted POST (multipart/form-data) request. Upon processing, the `aiohttp` server enters an infinite loop, preventing it from processing further requests. This results in a denial-of-service (DoS) attack, allowing an attacker to stop the application from serving requests after a single request. Users are advised to upgrade to version 3.9.4 or manually apply a patch to their systems as per the linked GHSA instructions.

Affected versions of `aiohttp` are vulnerable to an Improper Validation vulnerability. It is possible for an attacker to modify the HTTP request (e.g. insert a new header) or even create a new HTTP request if the attacker controls the HTTP method. The vulnerability occurs only if the attacker can control the HTTP method (GET, POST etc.) of the request. If the attacker can control the HTTP version of the request it will be able to modify the request (request smuggling).

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 Improper Input Validation due to insufficient checks on the HTTP version of incoming requests. The vulnerability arises because the HTTP request handling mechanism does not adequately validate the HTTP version, allowing manipulation if controlled by an attacker. An attacker with the ability to influence the HTTP version can exploit this flaw to inject new headers or craft entirely new HTTP requests, potentially leading to unauthorized actions or data exposure.

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

AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.12.14, the Python parser is vulnerable to a request smuggling vulnerability due to not parsing trailer sections of an HTTP request. If a pure Python version of aiohttp is installed (i.e. without the usual C extensions) or AIOHTTP_NO_EXTENSIONS is enabled, then an attacker may be able to execute a request smuggling attack to bypass certain firewalls or proxy protections. Version 3.12.14 contains a patch for this issue.

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 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 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 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 Cross-site Scripting (XSS) due to improper sanitization of user input on index pages for static file handling. The vulnerability exists because the `show_index` option, when enabled, allows unsanitized user input to be rendered directly into the HTML content of directory listings. An attacker can exploit this vulnerability by crafting a malicious URL that, when accessed, executes arbitrary JavaScript in the context of the user's browser, potentially leading to session hijacking or data theft.

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 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 aiohttp are vulnerable to HTTP Request Smuggling (CWE-444). This vulnerability allows attackers to inject malicious HTTP messages by including line feeds (LF) in chunk extensions, potentially bypassing security controls and executing unauthorized actions. The attack vector involves sending specially crafted chunked HTTP requests to exploit the improper parsing in the HttpPayloadParser class. To mitigate, upgrade to aiohttp version which validates chunk extensions by rejecting any containing unexpected LFs, thereby preventing request smuggling attacks.

The vulnerability lies in the improper configuration of static resource resolution when aiohttp is used as a web server. It occurs when the follow_symlinks option is enabled without proper validation, leading to directory traversal vulnerabilities. Unauthorized access to arbitrary files on the system could potentially occur. The affected versions are >1.0.5, and the issue was patched in version 3.9.2. As a workaround, it is advised to disable the follow_symlinks option outside of a restricted local development environment, especially in a server accepting requests from remote users. Using a reverse proxy server to handle static resources is also recommended.
https://github.com/aio-libs/aiohttp/commit/1c335944d6a8b1298baf179b7c0b3069f10c514b

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.

The aiohttp versions minor than 3.9. has a vulnerability that affects the Python HTTP parser used in the aiohttp library. It allows for minor differences in allowable character sets, which could lead to robust frame boundary matching of proxies to protect against the injection of additional requests. The vulnerability also allows 
 exceptions during validation that aren't handled consistently with other malformed inputs.

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 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 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 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 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 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 `aiohttp` are vulnerable to an infinite loop condition. This occurs when an attacker sends a specially crafted POST (multipart/form-data) request. Upon processing, the `aiohttp` server enters an infinite loop, preventing it from processing further requests. This results in a denial-of-service (DoS) attack, allowing an attacker to stop the application from serving requests after a single request. Users are advised to upgrade to version 3.9.4 or manually apply a patch to their systems as per the linked GHSA instructions.

Affected versions of `aiohttp` are vulnerable to an Improper Validation vulnerability. It is possible for an attacker to modify the HTTP request (e.g. insert a new header) or even create a new HTTP request if the attacker controls the HTTP method. The vulnerability occurs only if the attacker can control the HTTP method (GET, POST etc.) of the request. If the attacker can control the HTTP version of the request it will be able to modify the request (request smuggling).

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 Improper Input Validation due to insufficient checks on the HTTP version of incoming requests. The vulnerability arises because the HTTP request handling mechanism does not adequately validate the HTTP version, allowing manipulation if controlled by an attacker. An attacker with the ability to influence the HTTP version can exploit this flaw to inject new headers or craft entirely new HTTP requests, potentially leading to unauthorized actions or data exposure.

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

AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.12.14, the Python parser is vulnerable to a request smuggling vulnerability due to not parsing trailer sections of an HTTP request. If a pure Python version of aiohttp is installed (i.e. without the usual C extensions) or AIOHTTP_NO_EXTENSIONS is enabled, then an attacker may be able to execute a request smuggling attack to bypass certain firewalls or proxy protections. Version 3.12.14 contains a patch for this issue.

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 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 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 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 Cross-site Scripting (XSS) due to improper sanitization of user input on index pages for static file handling. The vulnerability exists because the `show_index` option, when enabled, allows unsanitized user input to be rendered directly into the HTML content of directory listings. An attacker can exploit this vulnerability by crafting a malicious URL that, when accessed, executes arbitrary JavaScript in the context of the user's browser, potentially leading to session hijacking or data theft.

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 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 aiohttp are vulnerable to HTTP Request Smuggling (CWE-444). This vulnerability allows attackers to inject malicious HTTP messages by including line feeds (LF) in chunk extensions, potentially bypassing security controls and executing unauthorized actions. The attack vector involves sending specially crafted chunked HTTP requests to exploit the improper parsing in the HttpPayloadParser class. To mitigate, upgrade to aiohttp version which validates chunk extensions by rejecting any containing unexpected LFs, thereby preventing request smuggling attacks.

The vulnerability lies in the improper configuration of static resource resolution when aiohttp is used as a web server. It occurs when the follow_symlinks option is enabled without proper validation, leading to directory traversal vulnerabilities. Unauthorized access to arbitrary files on the system could potentially occur. The affected versions are >1.0.5, and the issue was patched in version 3.9.2. As a workaround, it is advised to disable the follow_symlinks option outside of a restricted local development environment, especially in a server accepting requests from remote users. Using a reverse proxy server to handle static resources is also recommended.
https://github.com/aio-libs/aiohttp/commit/1c335944d6a8b1298baf179b7c0b3069f10c514b

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.

The aiohttp versions minor than 3.9. has a vulnerability that affects the Python HTTP parser used in the aiohttp library. It allows for minor differences in allowable character sets, which could lead to robust frame boundary matching of proxies to protect against the injection of additional requests. The vulnerability also allows 
 exceptions during validation that aren't handled consistently with other malformed inputs.

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 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 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 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 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 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 `aiohttp` are vulnerable to an infinite loop condition. This occurs when an attacker sends a specially crafted POST (multipart/form-data) request. Upon processing, the `aiohttp` server enters an infinite loop, preventing it from processing further requests. This results in a denial-of-service (DoS) attack, allowing an attacker to stop the application from serving requests after a single request. Users are advised to upgrade to version 3.9.4 or manually apply a patch to their systems as per the linked GHSA instructions.

Affected versions of `aiohttp` are vulnerable to an Improper Validation vulnerability. It is possible for an attacker to modify the HTTP request (e.g. insert a new header) or even create a new HTTP request if the attacker controls the HTTP method. The vulnerability occurs only if the attacker can control the HTTP method (GET, POST etc.) of the request. If the attacker can control the HTTP version of the request it will be able to modify the request (request smuggling).

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 Improper Input Validation due to insufficient checks on the HTTP version of incoming requests. The vulnerability arises because the HTTP request handling mechanism does not adequately validate the HTTP version, allowing manipulation if controlled by an attacker. An attacker with the ability to influence the HTTP version can exploit this flaw to inject new headers or craft entirely new HTTP requests, potentially leading to unauthorized actions or data exposure.

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

AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.12.14, the Python parser is vulnerable to a request smuggling vulnerability due to not parsing trailer sections of an HTTP request. If a pure Python version of aiohttp is installed (i.e. without the usual C extensions) or AIOHTTP_NO_EXTENSIONS is enabled, then an attacker may be able to execute a request smuggling attack to bypass certain firewalls or proxy protections. Version 3.12.14 contains a patch for this issue.

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 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 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 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 Cross-site Scripting (XSS) due to improper sanitization of user input on index pages for static file handling. The vulnerability exists because the `show_index` option, when enabled, allows unsanitized user input to be rendered directly into the HTML content of directory listings. An attacker can exploit this vulnerability by crafting a malicious URL that, when accessed, executes arbitrary JavaScript in the context of the user's browser, potentially leading to session hijacking or data theft.

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 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 aiohttp are vulnerable to HTTP Request Smuggling (CWE-444). This vulnerability allows attackers to inject malicious HTTP messages by including line feeds (LF) in chunk extensions, potentially bypassing security controls and executing unauthorized actions. The attack vector involves sending specially crafted chunked HTTP requests to exploit the improper parsing in the HttpPayloadParser class. To mitigate, upgrade to aiohttp version which validates chunk extensions by rejecting any containing unexpected LFs, thereby preventing request smuggling attacks.

The vulnerability lies in the improper configuration of static resource resolution when aiohttp is used as a web server. It occurs when the follow_symlinks option is enabled without proper validation, leading to directory traversal vulnerabilities. Unauthorized access to arbitrary files on the system could potentially occur. The affected versions are >1.0.5, and the issue was patched in version 3.9.2. As a workaround, it is advised to disable the follow_symlinks option outside of a restricted local development environment, especially in a server accepting requests from remote users. Using a reverse proxy server to handle static resources is also recommended.
https://github.com/aio-libs/aiohttp/commit/1c335944d6a8b1298baf179b7c0b3069f10c514b

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.

The aiohttp versions minor than 3.9. has a vulnerability that affects the Python HTTP parser used in the aiohttp library. It allows for minor differences in allowable character sets, which could lead to robust frame boundary matching of proxies to protect against the injection of additional requests. The vulnerability also allows 
 exceptions during validation that aren't handled consistently with other malformed inputs.

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 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 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 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 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 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 `aiohttp` are vulnerable to an infinite loop condition. This occurs when an attacker sends a specially crafted POST (multipart/form-data) request. Upon processing, the `aiohttp` server enters an infinite loop, preventing it from processing further requests. This results in a denial-of-service (DoS) attack, allowing an attacker to stop the application from serving requests after a single request. Users are advised to upgrade to version 3.9.4 or manually apply a patch to their systems as per the linked GHSA instructions.

Affected versions of `aiohttp` are vulnerable to an Improper Validation vulnerability. It is possible for an attacker to modify the HTTP request (e.g. insert a new header) or even create a new HTTP request if the attacker controls the HTTP method. The vulnerability occurs only if the attacker can control the HTTP method (GET, POST etc.) of the request. If the attacker can control the HTTP version of the request it will be able to modify the request (request smuggling).

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 Improper Input Validation due to insufficient checks on the HTTP version of incoming requests. The vulnerability arises because the HTTP request handling mechanism does not adequately validate the HTTP version, allowing manipulation if controlled by an attacker. An attacker with the ability to influence the HTTP version can exploit this flaw to inject new headers or craft entirely new HTTP requests, potentially leading to unauthorized actions or data exposure.

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

AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.12.14, the Python parser is vulnerable to a request smuggling vulnerability due to not parsing trailer sections of an HTTP request. If a pure Python version of aiohttp is installed (i.e. without the usual C extensions) or AIOHTTP_NO_EXTENSIONS is enabled, then an attacker may be able to execute a request smuggling attack to bypass certain firewalls or proxy protections. Version 3.12.14 contains a patch for this issue.

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 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 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 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 Cross-site Scripting (XSS) due to improper sanitization of user input on index pages for static file handling. The vulnerability exists because the `show_index` option, when enabled, allows unsanitized user input to be rendered directly into the HTML content of directory listings. An attacker can exploit this vulnerability by crafting a malicious URL that, when accessed, executes arbitrary JavaScript in the context of the user's browser, potentially leading to session hijacking or data theft.

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 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 aiohttp are vulnerable to HTTP Request Smuggling (CWE-444). This vulnerability allows attackers to inject malicious HTTP messages by including line feeds (LF) in chunk extensions, potentially bypassing security controls and executing unauthorized actions. The attack vector involves sending specially crafted chunked HTTP requests to exploit the improper parsing in the HttpPayloadParser class. To mitigate, upgrade to aiohttp version which validates chunk extensions by rejecting any containing unexpected LFs, thereby preventing request smuggling attacks.

The vulnerability lies in the improper configuration of static resource resolution when aiohttp is used as a web server. It occurs when the follow_symlinks option is enabled without proper validation, leading to directory traversal vulnerabilities. Unauthorized access to arbitrary files on the system could potentially occur. The affected versions are >1.0.5, and the issue was patched in version 3.9.2. As a workaround, it is advised to disable the follow_symlinks option outside of a restricted local development environment, especially in a server accepting requests from remote users. Using a reverse proxy server to handle static resources is also recommended.
https://github.com/aio-libs/aiohttp/commit/1c335944d6a8b1298baf179b7c0b3069f10c514b

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.

The aiohttp versions minor than 3.9. has a vulnerability that affects the Python HTTP parser used in the aiohttp library. It allows for minor differences in allowable character sets, which could lead to robust frame boundary matching of proxies to protect against the injection of additional requests. The vulnerability also allows 
 exceptions during validation that aren't handled consistently with other malformed inputs.

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 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 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 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 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 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 `aiohttp` are vulnerable to an infinite loop condition. This occurs when an attacker sends a specially crafted POST (multipart/form-data) request. Upon processing, the `aiohttp` server enters an infinite loop, preventing it from processing further requests. This results in a denial-of-service (DoS) attack, allowing an attacker to stop the application from serving requests after a single request. Users are advised to upgrade to version 3.9.4 or manually apply a patch to their systems as per the linked GHSA instructions.

Affected versions of `aiohttp` are vulnerable to an Improper Validation vulnerability. It is possible for an attacker to modify the HTTP request (e.g. insert a new header) or even create a new HTTP request if the attacker controls the HTTP method. The vulnerability occurs only if the attacker can control the HTTP method (GET, POST etc.) of the request. If the attacker can control the HTTP version of the request it will be able to modify the request (request smuggling).

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 Improper Input Validation due to insufficient checks on the HTTP version of incoming requests. The vulnerability arises because the HTTP request handling mechanism does not adequately validate the HTTP version, allowing manipulation if controlled by an attacker. An attacker with the ability to influence the HTTP version can exploit this flaw to inject new headers or craft entirely new HTTP requests, potentially leading to unauthorized actions or data exposure.

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

AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.12.14, the Python parser is vulnerable to a request smuggling vulnerability due to not parsing trailer sections of an HTTP request. If a pure Python version of aiohttp is installed (i.e. without the usual C extensions) or AIOHTTP_NO_EXTENSIONS is enabled, then an attacker may be able to execute a request smuggling attack to bypass certain firewalls or proxy protections. Version 3.12.14 contains a patch for this issue.

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 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 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 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 Cross-site Scripting (XSS) due to improper sanitization of user input on index pages for static file handling. The vulnerability exists because the `show_index` option, when enabled, allows unsanitized user input to be rendered directly into the HTML content of directory listings. An attacker can exploit this vulnerability by crafting a malicious URL that, when accessed, executes arbitrary JavaScript in the context of the user's browser, potentially leading to session hijacking or data theft.

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 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 aiohttp are vulnerable to HTTP Request Smuggling (CWE-444). This vulnerability allows attackers to inject malicious HTTP messages by including line feeds (LF) in chunk extensions, potentially bypassing security controls and executing unauthorized actions. The attack vector involves sending specially crafted chunked HTTP requests to exploit the improper parsing in the HttpPayloadParser class. To mitigate, upgrade to aiohttp version which validates chunk extensions by rejecting any containing unexpected LFs, thereby preventing request smuggling attacks.

The vulnerability lies in the improper configuration of static resource resolution when aiohttp is used as a web server. It occurs when the follow_symlinks option is enabled without proper validation, leading to directory traversal vulnerabilities. Unauthorized access to arbitrary files on the system could potentially occur. The affected versions are >1.0.5, and the issue was patched in version 3.9.2. As a workaround, it is advised to disable the follow_symlinks option outside of a restricted local development environment, especially in a server accepting requests from remote users. Using a reverse proxy server to handle static resources is also recommended.
https://github.com/aio-libs/aiohttp/commit/1c335944d6a8b1298baf179b7c0b3069f10c514b

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.

The aiohttp versions minor than 3.9. has a vulnerability that affects the Python HTTP parser used in the aiohttp library. It allows for minor differences in allowable character sets, which could lead to robust frame boundary matching of proxies to protect against the injection of additional requests. The vulnerability also allows 
 exceptions during validation that aren't handled consistently with other malformed inputs.

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

The `cryptography` library has updated its BoringSSL and OpenSSL dependencies in CI due to a security concern. Specifically, the issue involves the functions `EVP_PKEY_param_check()` and `EVP_PKEY_public_check()`, which are used to check DSA public keys or parameters. These functions can experience significant delays when processing excessively long DSA keys or parameters, potentially leading to a Denial of Service (DoS) if the input is from an untrusted source. The vulnerability arises because the key and parameter check functions do not limit the modulus size during checks, despite OpenSSL not allowing public keys with a modulus over 10,000 bits for signature verification. This issue affects applications that directly call these functions and the OpenSSL `pkey` and `pkeyparam` command-line applications with the `-check` option. The OpenSSL SSL/TLS implementation is not impacted, but the OpenSSL 3.0 and 3.1 FIPS providers are affected by this vulnerability.

Cryptography starting from version 42.0.0 updates its CI configurations to use newer versions of BoringSSL or OpenSSL as a countermeasure to CVE-2023-5678. This vulnerability, affecting the package, could cause Denial of Service through specific DH key generation and verification functions when given overly long parameters.

The cryptography library has updated its OpenSSL dependency in CI due to security concerns. This vulnerability arises when processing maliciously formatted PKCS12 files, which can cause OpenSSL to crash, leading to a potential Denial of Service (DoS) attack. PKCS12 files, often containing certificates and keys, may come from untrusted sources. The PKCS12 specification allows certain fields to be NULL, but OpenSSL does not correctly handle these cases, resulting in a NULL pointer dereference and subsequent crash. Applications using OpenSSL APIs, such as PKCS12_parse(), PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes(), and PKCS12_newpass(), are vulnerable if they process PKCS12 files from untrusted sources. Although a similar issue in SMIME_write_PKCS7() was fixed, it is not considered significant for security as it pertains to data writing. This issue does not affect the FIPS modules in versions 3.2, 3.1, and 3.0.

Cryptography 42.0.0 updates its bundled dependency 'OpenSSL' so to include the commit fix for CVE-2023-6237: Checking excessively long invalid RSA public keys may take a long time.

Affected versions of Cryptography are vulnerable to NULL-dereference when loading PKCS7 certificates. Calling 'load_pem_pkcs7_certificates' or 'load_der_pkcs7_certificates' could lead to a NULL-pointer dereference and segfault. Exploitation of this vulnerability poses a serious risk of Denial of Service (DoS) for any application attempting to deserialize a PKCS7 blob/certificate. The consequences extend to potential disruptions in system availability and stability.

cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. Starting in version 38.0.0 and before version 42.0.4, if `pkcs12.serialize_key_and_certificates` is called with both a certificate whose public key did not match the provided private key and an `encryption_algorithm` with `hmac_hash` set (via `PrivateFormat.PKCS12.encryption_builder().hmac_hash(...)`, then a NULL pointer dereference would occur, crashing the Python process. This has been resolved in version 42.0.4, the first version in which a `ValueError` is properly raised.

Affected versions of Cryptography may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data.

The `cryptography` library updates its BoringSSL and OpenSSL dependencies in CI due to a security concern. Specifically, certain non-default TLS server configurations can cause unbounded memory growth when processing TLSv1.3 sessions, leading to a potential Denial of Service (DoS) attack. The issue arises when the `SSL_OP_NO_TICKET` option is used without early data support and default anti-replay protection. Under these conditions, the session cache can become misconfigured, preventing it from flushing properly and causing it to grow indefinitely. A malicious client can exploit this scenario to trigger a DoS attack, although it can also occur accidentally during normal operations. This vulnerability affects only TLS servers supporting TLSv1.3 and does not impact TLS clients. Additionally, the FIPS modules in versions 3.2, 3.1, and 3.0, as well as OpenSSL 1.0.2, are not affected by this issue.

Cryptography version 42.0.5 introduces a limit on the number of name constraint checks during X.509 path validation to prevent denial of service attacks.
https://github.com/pyca/cryptography/commit/4be53bf20cc90cbac01f5f94c5d1aecc5289ba1f

Affected versions of Cryptography have a vulnerable statically linked copy of OpenSSL included in cryptography wheels.

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.

Versions of Cryptograph starting from 35.0.0 are susceptible to a security flaw in the POLY1305 MAC algorithm on PowerPC CPUs, which allows an attacker to disrupt the application's state. This disruption might result in false calculations or cause a denial of service. The vulnerability's exploitation hinges on the attacker's ability to alter the algorithm's application and the dependency of the software on non-volatile XMM registers.
https://github.com/pyca/cryptography/commit/89d0d56fb104ac4e0e6db63d78fc22b8c53d27e9

Affected versions of `aiohttp` are vulnerable to an infinite loop condition. This occurs when an attacker sends a specially crafted POST (multipart/form-data) request. Upon processing, the `aiohttp` server enters an infinite loop, preventing it from processing further requests. This results in a denial-of-service (DoS) attack, allowing an attacker to stop the application from serving requests after a single request. Users are advised to upgrade to version 3.9.4 or manually apply a patch to their systems as per the linked GHSA instructions.

Affected versions of `aiohttp` are vulnerable to an Improper Validation vulnerability. It is possible for an attacker to modify the HTTP request (e.g. insert a new header) or even create a new HTTP request if the attacker controls the HTTP method. The vulnerability occurs only if the attacker can control the HTTP method (GET, POST etc.) of the request. If the attacker can control the HTTP version of the request it will be able to modify the request (request smuggling).

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 Improper Input Validation due to insufficient checks on the HTTP version of incoming requests. The vulnerability arises because the HTTP request handling mechanism does not adequately validate the HTTP version, allowing manipulation if controlled by an attacker. An attacker with the ability to influence the HTTP version can exploit this flaw to inject new headers or craft entirely new HTTP requests, potentially leading to unauthorized actions or data exposure.

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

AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.12.14, the Python parser is vulnerable to a request smuggling vulnerability due to not parsing trailer sections of an HTTP request. If a pure Python version of aiohttp is installed (i.e. without the usual C extensions) or AIOHTTP_NO_EXTENSIONS is enabled, then an attacker may be able to execute a request smuggling attack to bypass certain firewalls or proxy protections. Version 3.12.14 contains a patch for this issue.

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 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 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 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 Cross-site Scripting (XSS) due to improper sanitization of user input on index pages for static file handling. The vulnerability exists because the `show_index` option, when enabled, allows unsanitized user input to be rendered directly into the HTML content of directory listings. An attacker can exploit this vulnerability by crafting a malicious URL that, when accessed, executes arbitrary JavaScript in the context of the user's browser, potentially leading to session hijacking or data theft.

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 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 aiohttp are vulnerable to HTTP Request Smuggling (CWE-444). This vulnerability allows attackers to inject malicious HTTP messages by including line feeds (LF) in chunk extensions, potentially bypassing security controls and executing unauthorized actions. The attack vector involves sending specially crafted chunked HTTP requests to exploit the improper parsing in the HttpPayloadParser class. To mitigate, upgrade to aiohttp version which validates chunk extensions by rejecting any containing unexpected LFs, thereby preventing request smuggling attacks.

The vulnerability lies in the improper configuration of static resource resolution when aiohttp is used as a web server. It occurs when the follow_symlinks option is enabled without proper validation, leading to directory traversal vulnerabilities. Unauthorized access to arbitrary files on the system could potentially occur. The affected versions are >1.0.5, and the issue was patched in version 3.9.2. As a workaround, it is advised to disable the follow_symlinks option outside of a restricted local development environment, especially in a server accepting requests from remote users. Using a reverse proxy server to handle static resources is also recommended.
https://github.com/aio-libs/aiohttp/commit/1c335944d6a8b1298baf179b7c0b3069f10c514b

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.

The aiohttp versions minor than 3.9. has a vulnerability that affects the Python HTTP parser used in the aiohttp library. It allows for minor differences in allowable character sets, which could lead to robust frame boundary matching of proxies to protect against the injection of additional requests. The vulnerability also allows 
 exceptions during validation that aren't handled consistently with other malformed inputs.

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

The `cryptography` library has updated its BoringSSL and OpenSSL dependencies in CI due to a security concern. Specifically, the issue involves the functions `EVP_PKEY_param_check()` and `EVP_PKEY_public_check()`, which are used to check DSA public keys or parameters. These functions can experience significant delays when processing excessively long DSA keys or parameters, potentially leading to a Denial of Service (DoS) if the input is from an untrusted source. The vulnerability arises because the key and parameter check functions do not limit the modulus size during checks, despite OpenSSL not allowing public keys with a modulus over 10,000 bits for signature verification. This issue affects applications that directly call these functions and the OpenSSL `pkey` and `pkeyparam` command-line applications with the `-check` option. The OpenSSL SSL/TLS implementation is not impacted, but the OpenSSL 3.0 and 3.1 FIPS providers are affected by this vulnerability.

Cryptography starting from version 42.0.0 updates its CI configurations to use newer versions of BoringSSL or OpenSSL as a countermeasure to CVE-2023-5678. This vulnerability, affecting the package, could cause Denial of Service through specific DH key generation and verification functions when given overly long parameters.

The cryptography library has updated its OpenSSL dependency in CI due to security concerns. This vulnerability arises when processing maliciously formatted PKCS12 files, which can cause OpenSSL to crash, leading to a potential Denial of Service (DoS) attack. PKCS12 files, often containing certificates and keys, may come from untrusted sources. The PKCS12 specification allows certain fields to be NULL, but OpenSSL does not correctly handle these cases, resulting in a NULL pointer dereference and subsequent crash. Applications using OpenSSL APIs, such as PKCS12_parse(), PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes(), and PKCS12_newpass(), are vulnerable if they process PKCS12 files from untrusted sources. Although a similar issue in SMIME_write_PKCS7() was fixed, it is not considered significant for security as it pertains to data writing. This issue does not affect the FIPS modules in versions 3.2, 3.1, and 3.0.

Cryptography 42.0.0 updates its bundled dependency 'OpenSSL' so to include the commit fix for CVE-2023-6237: Checking excessively long invalid RSA public keys may take a long time.

Affected versions of Cryptography are vulnerable to NULL-dereference when loading PKCS7 certificates. Calling 'load_pem_pkcs7_certificates' or 'load_der_pkcs7_certificates' could lead to a NULL-pointer dereference and segfault. Exploitation of this vulnerability poses a serious risk of Denial of Service (DoS) for any application attempting to deserialize a PKCS7 blob/certificate. The consequences extend to potential disruptions in system availability and stability.

cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. Starting in version 38.0.0 and before version 42.0.4, if `pkcs12.serialize_key_and_certificates` is called with both a certificate whose public key did not match the provided private key and an `encryption_algorithm` with `hmac_hash` set (via `PrivateFormat.PKCS12.encryption_builder().hmac_hash(...)`, then a NULL pointer dereference would occur, crashing the Python process. This has been resolved in version 42.0.4, the first version in which a `ValueError` is properly raised.

Affected versions of Cryptography may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data.

The `cryptography` library updates its BoringSSL and OpenSSL dependencies in CI due to a security concern. Specifically, certain non-default TLS server configurations can cause unbounded memory growth when processing TLSv1.3 sessions, leading to a potential Denial of Service (DoS) attack. The issue arises when the `SSL_OP_NO_TICKET` option is used without early data support and default anti-replay protection. Under these conditions, the session cache can become misconfigured, preventing it from flushing properly and causing it to grow indefinitely. A malicious client can exploit this scenario to trigger a DoS attack, although it can also occur accidentally during normal operations. This vulnerability affects only TLS servers supporting TLSv1.3 and does not impact TLS clients. Additionally, the FIPS modules in versions 3.2, 3.1, and 3.0, as well as OpenSSL 1.0.2, are not affected by this issue.

Cryptography version 42.0.5 introduces a limit on the number of name constraint checks during X.509 path validation to prevent denial of service attacks.
https://github.com/pyca/cryptography/commit/4be53bf20cc90cbac01f5f94c5d1aecc5289ba1f

Affected versions of Cryptography have a vulnerable statically linked copy of OpenSSL included in cryptography wheels.

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.

Versions of Cryptograph starting from 35.0.0 are susceptible to a security flaw in the POLY1305 MAC algorithm on PowerPC CPUs, which allows an attacker to disrupt the application's state. This disruption might result in false calculations or cause a denial of service. The vulnerability's exploitation hinges on the attacker's ability to alter the algorithm's application and the dependency of the software on non-volatile XMM registers.
https://github.com/pyca/cryptography/commit/89d0d56fb104ac4e0e6db63d78fc22b8c53d27e9

Affected versions of `aiohttp` are vulnerable to an infinite loop condition. This occurs when an attacker sends a specially crafted POST (multipart/form-data) request. Upon processing, the `aiohttp` server enters an infinite loop, preventing it from processing further requests. This results in a denial-of-service (DoS) attack, allowing an attacker to stop the application from serving requests after a single request. Users are advised to upgrade to version 3.9.4 or manually apply a patch to their systems as per the linked GHSA instructions.

Affected versions of `aiohttp` are vulnerable to an Improper Validation vulnerability. It is possible for an attacker to modify the HTTP request (e.g. insert a new header) or even create a new HTTP request if the attacker controls the HTTP method. The vulnerability occurs only if the attacker can control the HTTP method (GET, POST etc.) of the request. If the attacker can control the HTTP version of the request it will be able to modify the request (request smuggling).

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 Improper Input Validation due to insufficient checks on the HTTP version of incoming requests. The vulnerability arises because the HTTP request handling mechanism does not adequately validate the HTTP version, allowing manipulation if controlled by an attacker. An attacker with the ability to influence the HTTP version can exploit this flaw to inject new headers or craft entirely new HTTP requests, potentially leading to unauthorized actions or data exposure.

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

AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.12.14, the Python parser is vulnerable to a request smuggling vulnerability due to not parsing trailer sections of an HTTP request. If a pure Python version of aiohttp is installed (i.e. without the usual C extensions) or AIOHTTP_NO_EXTENSIONS is enabled, then an attacker may be able to execute a request smuggling attack to bypass certain firewalls or proxy protections. Version 3.12.14 contains a patch for this issue.

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 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 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 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 Cross-site Scripting (XSS) due to improper sanitization of user input on index pages for static file handling. The vulnerability exists because the `show_index` option, when enabled, allows unsanitized user input to be rendered directly into the HTML content of directory listings. An attacker can exploit this vulnerability by crafting a malicious URL that, when accessed, executes arbitrary JavaScript in the context of the user's browser, potentially leading to session hijacking or data theft.

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 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 aiohttp are vulnerable to HTTP Request Smuggling (CWE-444). This vulnerability allows attackers to inject malicious HTTP messages by including line feeds (LF) in chunk extensions, potentially bypassing security controls and executing unauthorized actions. The attack vector involves sending specially crafted chunked HTTP requests to exploit the improper parsing in the HttpPayloadParser class. To mitigate, upgrade to aiohttp version which validates chunk extensions by rejecting any containing unexpected LFs, thereby preventing request smuggling attacks.

The vulnerability lies in the improper configuration of static resource resolution when aiohttp is used as a web server. It occurs when the follow_symlinks option is enabled without proper validation, leading to directory traversal vulnerabilities. Unauthorized access to arbitrary files on the system could potentially occur. The affected versions are >1.0.5, and the issue was patched in version 3.9.2. As a workaround, it is advised to disable the follow_symlinks option outside of a restricted local development environment, especially in a server accepting requests from remote users. Using a reverse proxy server to handle static resources is also recommended.
https://github.com/aio-libs/aiohttp/commit/1c335944d6a8b1298baf179b7c0b3069f10c514b

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.

The aiohttp versions minor than 3.9. has a vulnerability that affects the Python HTTP parser used in the aiohttp library. It allows for minor differences in allowable character sets, which could lead to robust frame boundary matching of proxies to protect against the injection of additional requests. The vulnerability also allows 
 exceptions during validation that aren't handled consistently with other malformed inputs.

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

The `cryptography` library has updated its BoringSSL and OpenSSL dependencies in CI due to a security concern. Specifically, the issue involves the functions `EVP_PKEY_param_check()` and `EVP_PKEY_public_check()`, which are used to check DSA public keys or parameters. These functions can experience significant delays when processing excessively long DSA keys or parameters, potentially leading to a Denial of Service (DoS) if the input is from an untrusted source. The vulnerability arises because the key and parameter check functions do not limit the modulus size during checks, despite OpenSSL not allowing public keys with a modulus over 10,000 bits for signature verification. This issue affects applications that directly call these functions and the OpenSSL `pkey` and `pkeyparam` command-line applications with the `-check` option. The OpenSSL SSL/TLS implementation is not impacted, but the OpenSSL 3.0 and 3.1 FIPS providers are affected by this vulnerability.

Cryptography starting from version 42.0.0 updates its CI configurations to use newer versions of BoringSSL or OpenSSL as a countermeasure to CVE-2023-5678. This vulnerability, affecting the package, could cause Denial of Service through specific DH key generation and verification functions when given overly long parameters.

The cryptography library has updated its OpenSSL dependency in CI due to security concerns. This vulnerability arises when processing maliciously formatted PKCS12 files, which can cause OpenSSL to crash, leading to a potential Denial of Service (DoS) attack. PKCS12 files, often containing certificates and keys, may come from untrusted sources. The PKCS12 specification allows certain fields to be NULL, but OpenSSL does not correctly handle these cases, resulting in a NULL pointer dereference and subsequent crash. Applications using OpenSSL APIs, such as PKCS12_parse(), PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes(), and PKCS12_newpass(), are vulnerable if they process PKCS12 files from untrusted sources. Although a similar issue in SMIME_write_PKCS7() was fixed, it is not considered significant for security as it pertains to data writing. This issue does not affect the FIPS modules in versions 3.2, 3.1, and 3.0.

Cryptography 42.0.0 updates its bundled dependency 'OpenSSL' so to include the commit fix for CVE-2023-6237: Checking excessively long invalid RSA public keys may take a long time.

Affected versions of Cryptography are vulnerable to NULL-dereference when loading PKCS7 certificates. Calling 'load_pem_pkcs7_certificates' or 'load_der_pkcs7_certificates' could lead to a NULL-pointer dereference and segfault. Exploitation of this vulnerability poses a serious risk of Denial of Service (DoS) for any application attempting to deserialize a PKCS7 blob/certificate. The consequences extend to potential disruptions in system availability and stability.

cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. Starting in version 38.0.0 and before version 42.0.4, if `pkcs12.serialize_key_and_certificates` is called with both a certificate whose public key did not match the provided private key and an `encryption_algorithm` with `hmac_hash` set (via `PrivateFormat.PKCS12.encryption_builder().hmac_hash(...)`, then a NULL pointer dereference would occur, crashing the Python process. This has been resolved in version 42.0.4, the first version in which a `ValueError` is properly raised.

Affected versions of Cryptography may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data.

The `cryptography` library updates its BoringSSL and OpenSSL dependencies in CI due to a security concern. Specifically, certain non-default TLS server configurations can cause unbounded memory growth when processing TLSv1.3 sessions, leading to a potential Denial of Service (DoS) attack. The issue arises when the `SSL_OP_NO_TICKET` option is used without early data support and default anti-replay protection. Under these conditions, the session cache can become misconfigured, preventing it from flushing properly and causing it to grow indefinitely. A malicious client can exploit this scenario to trigger a DoS attack, although it can also occur accidentally during normal operations. This vulnerability affects only TLS servers supporting TLSv1.3 and does not impact TLS clients. Additionally, the FIPS modules in versions 3.2, 3.1, and 3.0, as well as OpenSSL 1.0.2, are not affected by this issue.

Cryptography version 42.0.5 introduces a limit on the number of name constraint checks during X.509 path validation to prevent denial of service attacks.
https://github.com/pyca/cryptography/commit/4be53bf20cc90cbac01f5f94c5d1aecc5289ba1f

Affected versions of Cryptography have a vulnerable statically linked copy of OpenSSL included in cryptography wheels.

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.

Versions of Cryptograph starting from 35.0.0 are susceptible to a security flaw in the POLY1305 MAC algorithm on PowerPC CPUs, which allows an attacker to disrupt the application's state. This disruption might result in false calculations or cause a denial of service. The vulnerability's exploitation hinges on the attacker's ability to alter the algorithm's application and the dependency of the software on non-volatile XMM registers.
https://github.com/pyca/cryptography/commit/89d0d56fb104ac4e0e6db63d78fc22b8c53d27e9

Affected versions of `aiohttp` are vulnerable to an infinite loop condition. This occurs when an attacker sends a specially crafted POST (multipart/form-data) request. Upon processing, the `aiohttp` server enters an infinite loop, preventing it from processing further requests. This results in a denial-of-service (DoS) attack, allowing an attacker to stop the application from serving requests after a single request. Users are advised to upgrade to version 3.9.4 or manually apply a patch to their systems as per the linked GHSA instructions.

Affected versions of `aiohttp` are vulnerable to an Improper Validation vulnerability. It is possible for an attacker to modify the HTTP request (e.g. insert a new header) or even create a new HTTP request if the attacker controls the HTTP method. The vulnerability occurs only if the attacker can control the HTTP method (GET, POST etc.) of the request. If the attacker can control the HTTP version of the request it will be able to modify the request (request smuggling).

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 Improper Input Validation due to insufficient checks on the HTTP version of incoming requests. The vulnerability arises because the HTTP request handling mechanism does not adequately validate the HTTP version, allowing manipulation if controlled by an attacker. An attacker with the ability to influence the HTTP version can exploit this flaw to inject new headers or craft entirely new HTTP requests, potentially leading to unauthorized actions or data exposure.

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

AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.12.14, the Python parser is vulnerable to a request smuggling vulnerability due to not parsing trailer sections of an HTTP request. If a pure Python version of aiohttp is installed (i.e. without the usual C extensions) or AIOHTTP_NO_EXTENSIONS is enabled, then an attacker may be able to execute a request smuggling attack to bypass certain firewalls or proxy protections. Version 3.12.14 contains a patch for this issue.

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 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 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 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 Cross-site Scripting (XSS) due to improper sanitization of user input on index pages for static file handling. The vulnerability exists because the `show_index` option, when enabled, allows unsanitized user input to be rendered directly into the HTML content of directory listings. An attacker can exploit this vulnerability by crafting a malicious URL that, when accessed, executes arbitrary JavaScript in the context of the user's browser, potentially leading to session hijacking or data theft.

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 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 aiohttp are vulnerable to HTTP Request Smuggling (CWE-444). This vulnerability allows attackers to inject malicious HTTP messages by including line feeds (LF) in chunk extensions, potentially bypassing security controls and executing unauthorized actions. The attack vector involves sending specially crafted chunked HTTP requests to exploit the improper parsing in the HttpPayloadParser class. To mitigate, upgrade to aiohttp version which validates chunk extensions by rejecting any containing unexpected LFs, thereby preventing request smuggling attacks.

The vulnerability lies in the improper configuration of static resource resolution when aiohttp is used as a web server. It occurs when the follow_symlinks option is enabled without proper validation, leading to directory traversal vulnerabilities. Unauthorized access to arbitrary files on the system could potentially occur. The affected versions are >1.0.5, and the issue was patched in version 3.9.2. As a workaround, it is advised to disable the follow_symlinks option outside of a restricted local development environment, especially in a server accepting requests from remote users. Using a reverse proxy server to handle static resources is also recommended.
https://github.com/aio-libs/aiohttp/commit/1c335944d6a8b1298baf179b7c0b3069f10c514b

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.

The aiohttp versions minor than 3.9. has a vulnerability that affects the Python HTTP parser used in the aiohttp library. It allows for minor differences in allowable character sets, which could lead to robust frame boundary matching of proxies to protect against the injection of additional requests. The vulnerability also allows 
 exceptions during validation that aren't handled consistently with other malformed inputs.

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

The `cryptography` library has updated its BoringSSL and OpenSSL dependencies in CI due to a security concern. Specifically, the issue involves the functions `EVP_PKEY_param_check()` and `EVP_PKEY_public_check()`, which are used to check DSA public keys or parameters. These functions can experience significant delays when processing excessively long DSA keys or parameters, potentially leading to a Denial of Service (DoS) if the input is from an untrusted source. The vulnerability arises because the key and parameter check functions do not limit the modulus size during checks, despite OpenSSL not allowing public keys with a modulus over 10,000 bits for signature verification. This issue affects applications that directly call these functions and the OpenSSL `pkey` and `pkeyparam` command-line applications with the `-check` option. The OpenSSL SSL/TLS implementation is not impacted, but the OpenSSL 3.0 and 3.1 FIPS providers are affected by this vulnerability.

Cryptography starting from version 42.0.0 updates its CI configurations to use newer versions of BoringSSL or OpenSSL as a countermeasure to CVE-2023-5678. This vulnerability, affecting the package, could cause Denial of Service through specific DH key generation and verification functions when given overly long parameters.

The cryptography library has updated its OpenSSL dependency in CI due to security concerns. This vulnerability arises when processing maliciously formatted PKCS12 files, which can cause OpenSSL to crash, leading to a potential Denial of Service (DoS) attack. PKCS12 files, often containing certificates and keys, may come from untrusted sources. The PKCS12 specification allows certain fields to be NULL, but OpenSSL does not correctly handle these cases, resulting in a NULL pointer dereference and subsequent crash. Applications using OpenSSL APIs, such as PKCS12_parse(), PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes(), and PKCS12_newpass(), are vulnerable if they process PKCS12 files from untrusted sources. Although a similar issue in SMIME_write_PKCS7() was fixed, it is not considered significant for security as it pertains to data writing. This issue does not affect the FIPS modules in versions 3.2, 3.1, and 3.0.

Cryptography 42.0.0 updates its bundled dependency 'OpenSSL' so to include the commit fix for CVE-2023-6237: Checking excessively long invalid RSA public keys may take a long time.

Affected versions of Cryptography are vulnerable to NULL-dereference when loading PKCS7 certificates. Calling 'load_pem_pkcs7_certificates' or 'load_der_pkcs7_certificates' could lead to a NULL-pointer dereference and segfault. Exploitation of this vulnerability poses a serious risk of Denial of Service (DoS) for any application attempting to deserialize a PKCS7 blob/certificate. The consequences extend to potential disruptions in system availability and stability.

cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. Starting in version 38.0.0 and before version 42.0.4, if `pkcs12.serialize_key_and_certificates` is called with both a certificate whose public key did not match the provided private key and an `encryption_algorithm` with `hmac_hash` set (via `PrivateFormat.PKCS12.encryption_builder().hmac_hash(...)`, then a NULL pointer dereference would occur, crashing the Python process. This has been resolved in version 42.0.4, the first version in which a `ValueError` is properly raised.

Affected versions of Cryptography may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data.

The `cryptography` library updates its BoringSSL and OpenSSL dependencies in CI due to a security concern. Specifically, certain non-default TLS server configurations can cause unbounded memory growth when processing TLSv1.3 sessions, leading to a potential Denial of Service (DoS) attack. The issue arises when the `SSL_OP_NO_TICKET` option is used without early data support and default anti-replay protection. Under these conditions, the session cache can become misconfigured, preventing it from flushing properly and causing it to grow indefinitely. A malicious client can exploit this scenario to trigger a DoS attack, although it can also occur accidentally during normal operations. This vulnerability affects only TLS servers supporting TLSv1.3 and does not impact TLS clients. Additionally, the FIPS modules in versions 3.2, 3.1, and 3.0, as well as OpenSSL 1.0.2, are not affected by this issue.

Cryptography version 42.0.5 introduces a limit on the number of name constraint checks during X.509 path validation to prevent denial of service attacks.
https://github.com/pyca/cryptography/commit/4be53bf20cc90cbac01f5f94c5d1aecc5289ba1f

Affected versions of Cryptography have a vulnerable statically linked copy of OpenSSL included in cryptography wheels.

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.

Versions of Cryptograph starting from 35.0.0 are susceptible to a security flaw in the POLY1305 MAC algorithm on PowerPC CPUs, which allows an attacker to disrupt the application's state. This disruption might result in false calculations or cause a denial of service. The vulnerability's exploitation hinges on the attacker's ability to alter the algorithm's application and the dependency of the software on non-volatile XMM registers.
https://github.com/pyca/cryptography/commit/89d0d56fb104ac4e0e6db63d78fc22b8c53d27e9

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.

The `cryptography` library has updated its BoringSSL and OpenSSL dependencies in CI due to a security concern. Specifically, the issue involves the functions `EVP_PKEY_param_check()` and `EVP_PKEY_public_check()`, which are used to check DSA public keys or parameters. These functions can experience significant delays when processing excessively long DSA keys or parameters, potentially leading to a Denial of Service (DoS) if the input is from an untrusted source. The vulnerability arises because the key and parameter check functions do not limit the modulus size during checks, despite OpenSSL not allowing public keys with a modulus over 10,000 bits for signature verification. This issue affects applications that directly call these functions and the OpenSSL `pkey` and `pkeyparam` command-line applications with the `-check` option. The OpenSSL SSL/TLS implementation is not impacted, but the OpenSSL 3.0 and 3.1 FIPS providers are affected by this vulnerability.

Cryptography starting from version 42.0.0 updates its CI configurations to use newer versions of BoringSSL or OpenSSL as a countermeasure to CVE-2023-5678. This vulnerability, affecting the package, could cause Denial of Service through specific DH key generation and verification functions when given overly long parameters.

The cryptography library has updated its OpenSSL dependency in CI due to security concerns. This vulnerability arises when processing maliciously formatted PKCS12 files, which can cause OpenSSL to crash, leading to a potential Denial of Service (DoS) attack. PKCS12 files, often containing certificates and keys, may come from untrusted sources. The PKCS12 specification allows certain fields to be NULL, but OpenSSL does not correctly handle these cases, resulting in a NULL pointer dereference and subsequent crash. Applications using OpenSSL APIs, such as PKCS12_parse(), PKCS12_unpack_p7data(), PKCS12_unpack_p7encdata(), PKCS12_unpack_authsafes(), and PKCS12_newpass(), are vulnerable if they process PKCS12 files from untrusted sources. Although a similar issue in SMIME_write_PKCS7() was fixed, it is not considered significant for security as it pertains to data writing. This issue does not affect the FIPS modules in versions 3.2, 3.1, and 3.0.

Cryptography 42.0.0 updates its bundled dependency 'OpenSSL' so to include the commit fix for CVE-2023-6237: Checking excessively long invalid RSA public keys may take a long time.

Affected versions of Cryptography are vulnerable to NULL-dereference when loading PKCS7 certificates. Calling 'load_pem_pkcs7_certificates' or 'load_der_pkcs7_certificates' could lead to a NULL-pointer dereference and segfault. Exploitation of this vulnerability poses a serious risk of Denial of Service (DoS) for any application attempting to deserialize a PKCS7 blob/certificate. The consequences extend to potential disruptions in system availability and stability.

cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. Starting in version 38.0.0 and before version 42.0.4, if `pkcs12.serialize_key_and_certificates` is called with both a certificate whose public key did not match the provided private key and an `encryption_algorithm` with `hmac_hash` set (via `PrivateFormat.PKCS12.encryption_builder().hmac_hash(...)`, then a NULL pointer dereference would occur, crashing the Python process. This has been resolved in version 42.0.4, the first version in which a `ValueError` is properly raised.

Affected versions of Cryptography may allow a remote attacker to decrypt captured messages in TLS servers that use RSA key exchanges, which may lead to exposure of confidential or sensitive data.

The `cryptography` library updates its BoringSSL and OpenSSL dependencies in CI due to a security concern. Specifically, certain non-default TLS server configurations can cause unbounded memory growth when processing TLSv1.3 sessions, leading to a potential Denial of Service (DoS) attack. The issue arises when the `SSL_OP_NO_TICKET` option is used without early data support and default anti-replay protection. Under these conditions, the session cache can become misconfigured, preventing it from flushing properly and causing it to grow indefinitely. A malicious client can exploit this scenario to trigger a DoS attack, although it can also occur accidentally during normal operations. This vulnerability affects only TLS servers supporting TLSv1.3 and does not impact TLS clients. Additionally, the FIPS modules in versions 3.2, 3.1, and 3.0, as well as OpenSSL 1.0.2, are not affected by this issue.

Cryptography version 42.0.5 introduces a limit on the number of name constraint checks during X.509 path validation to prevent denial of service attacks.
https://github.com/pyca/cryptography/commit/4be53bf20cc90cbac01f5f94c5d1aecc5289ba1f

Affected versions of Cryptography have a vulnerable statically linked copy of OpenSSL included in cryptography wheels.

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.

Versions of Cryptograph starting from 35.0.0 are susceptible to a security flaw in the POLY1305 MAC algorithm on PowerPC CPUs, which allows an attacker to disrupt the application's state. This disruption might result in false calculations or cause a denial of service. The vulnerability's exploitation hinges on the attacker's ability to alter the algorithm's application and the dependency of the software on non-volatile XMM registers.
https://github.com/pyca/cryptography/commit/89d0d56fb104ac4e0e6db63d78fc22b8c53d27e9