aiohttp known bugs

### Summary A zip bomb can be used to execute a DoS against the aiohttp server. ### Impact An attacker may be able to send a compressed request that when decompressed by aiohttp could exhaust the host's memory. ------ Patch: https://github.com/aio-libs/aiohttp/commit/2b920c39002cee0ec5b402581779bbaaf7c9138a

### Summary An attacker can send a specially crafted POST (multipart/form-data) request. When the aiohttp server processes it, the server will enter an infinite loop and be unable to process any further requests. ### Impact An attacker can stop the application from serving requests after sending a single request. ------- For anyone needing to patch older versions of aiohttp, the minimum diff needed to resolve the issue is (located in `_read_chunk_from_length()`): ```diff diff --git a/aiohttp/multipart.py b/aiohttp/multipart.py index 227be605c..71fc2654a 100644 --- a/aiohttp/multipart.py +++ b/aiohttp/multipart.py @@ -338,6 +338,8 @@ class BodyPartReader: assert self._length is not None, "Content-Length required for chunked read" chunk_size = min(size, self._length - self._read_bytes) chunk = await self._content.read(chunk_size) + if self._content.at_eof(): + self._at_eof = True return chunk async def _read_chunk_from_stream(self, size: int) -> bytes: ``` This does however introduce some very minor issues with handling form data. So, if possible, it would be recommended to also backport the changes in: https://github.com/aio-libs/aiohttp/commit/cebe526b9c34dc3a3da9140409db63014bc4cf19 https://github.com/aio-libs/aiohttp/commit/7eecdff163ccf029fbb1ddc9de4169d4aaeb6597 https://github.com/aio-libs/aiohttp/commit/f21c6f2ca512a026ce7f0f6c6311f62d6a638866

### Summary Improperly configuring static resource resolution in aiohttp when used as a web server can result in the unauthorized reading of arbitrary files on the system. ### Details When using aiohttp as a web server and configuring static routes, it is necessary to specify the root path for static files. Additionally, the option 'follow_symlinks' can be used to determine whether to follow symbolic links outside the static root directory. When 'follow_symlinks' is set to True, there is no validation to check if a given file path is within the root directory.This can lead to directory traversal vulnerabilities, resulting in unauthorized access to arbitrary files on the system, even when symlinks are not present. i.e. An application is only vulnerable with setup code like: ``` app.router.add_routes([ web.static("/static", "static/", follow_symlinks=True), # Remove follow_symlinks to avoid the vulnerability ]) ``` ### Impact This is a directory traversal vulnerability with CWE ID 22. When using aiohttp as a web server and enabling static resource resolution with `follow_symlinks` set to True, it can lead to this vulnerability. This vulnerability has been present since the introduction of the `follow_symlinks` parameter. ### Workaround Even if upgrading to a patched version of aiohttp, we recommend following these steps regardless. If using `follow_symlinks=True` outside of a restricted local development environment, disable the option immediately. This option is NOT needed to follow symlinks which point to a location _within_ the static root directory, it is _only_ intended to allow a symlink to break out of the static directory. Even with this CVE fixed, there is still a substantial risk of misconfiguration when using this option on a server that accepts requests from remote users. Additionally, aiohttp has always recommended using a reverse proxy server (such as nginx) to handle static resources and _not_ to use these static resources in aiohttp for production environments. Doing so also protects against this vulnerability, and is why we expect the number of affected users to be very low. ----- Patch: https://github.com/aio-libs/aiohttp/pull/8079/files

aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. Security-sensitive parts of the Python HTTP parser retained minor differences in allowable character sets, that must trigger error handling to robustly match frame boundaries of proxies in order to protect against injection of additional requests. Additionally, validation could trigger exceptions that were not handled consistently with processing of other malformed input. Being more lenient than internet standards require could, depending on deployment environment, assist in request smuggling. The unhandled exception could cause excessive resource consumption on the application server and/or its logging facilities. This vulnerability exists due to an incomplete fix for CVE-2023-47627. Version 3.9.2 fixes this vulnerability.

aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. When using aiohttp as a web server and configuring static routes, it is necessary to specify the root path for static files. Additionally, the option 'follow_symlinks' can be used to determine whether to follow symbolic links outside the static root directory. When 'follow_symlinks' is set to True, there is no validation to check if reading a file is within the root directory. This can lead to directory traversal vulnerabilities, resulting in unauthorized access to arbitrary files on the system, even when symlinks are not present. Disabling follow_symlinks and using a reverse proxy are encouraged mitigations. Version 3.9.2 fixes this issue.

aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. Improper validation makes it 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). This issue has been patched in version 3.9.0.

aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. Improper validation made it possible for an attacker to modify the HTTP request (e.g. to insert a new header) or create a new HTTP request if the attacker controls the HTTP version. The vulnerability only occurs if the attacker can control the HTTP version of the request. This issue has been patched in version 3.9.0.

aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. Affected versions of aiohttp have a security vulnerability regarding the inconsistent interpretation of the http protocol. HTTP/1.1 is a persistent protocol, if both Content-Length(CL) and Transfer-Encoding(TE) header values are present it can lead to incorrect interpretation of two entities that parse the HTTP and we can poison other sockets with this incorrect interpretation. A possible Proof-of-Concept (POC) would be a configuration with a reverse proxy(frontend) that accepts both CL and TE headers and aiohttp as backend. As aiohttp parses anything with chunked, we can pass a chunked123 as TE, the frontend entity will ignore this header and will parse Content-Length. The impact of this vulnerability is that it is possible to bypass any proxy rule, poisoning sockets to other users like passing Authentication Headers, also if it is present an Open Redirect an attacker could combine it to redirect random users to another website and log the request. This vulnerability has been addressed in release 3.8.0 of aiohttp. Users are advised to upgrade. There are no known workarounds for this vulnerability.

aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. The HTTP parser in AIOHTTP has numerous problems with header parsing, which could lead to request smuggling. This parser is only used when AIOHTTP_NO_EXTENSIONS is enabled (or not using a prebuilt wheel). These bugs have been addressed in commit `d5c12ba89` which has been included in release version 3.8.6. Users are advised to upgrade. There are no known workarounds for these issues.

### Impact aiohttp v3.8.4 and earlier are [bundled with llhttp v6.0.6](https://github.com/aio-libs/aiohttp/blob/v3.8.4/.gitmodules) which is vulnerable to CVE-2023-30589. The vulnerable code is used by aiohttp for its HTTP request parser when available which is the default case when installing from a wheel. This vulnerability only affects users of aiohttp as an HTTP server (ie `aiohttp.Application`), you are not affected by this vulnerability if you are using aiohttp as an HTTP client library (ie `aiohttp.ClientSession`). ### Reproducer ```python from aiohttp import web async def example(request: web.Request): headers = dict(request.headers) body = await request.content.read() return web.Response(text=f"headers: {headers} body: {body}") app = web.Application() app.add_routes([web.post('/', example)]) web.run_app(app) ``` Sending a crafted HTTP request will cause the server to misinterpret one of the HTTP header values leading to HTTP request smuggling. ```console $ printf "POST / HTTP/1.1\r\nHost: localhost:8080\r\nX-Abc: \rxTransfer-Encoding: chunked\r\n\r\n1\r\nA\r\n0\r\n\r\n" \ | nc localhost 8080 Expected output: headers: {'Host': 'localhost:8080', 'X-Abc': '\rxTransfer-Encoding: chunked'} body: b'' Actual output (note that 'Transfer-Encoding: chunked' is an HTTP header now and body is treated differently) headers: {'Host': 'localhost:8080', 'X-Abc': '', 'Transfer-Encoding': 'chunked'} body: b'A' ``` ### Patches Upgrade to the latest version of aiohttp to resolve this vulnerability. It has been fixed in v3.8.5: [`pip install aiohttp >= 3.8.5`](https://pypi.org/project/aiohttp/3.8.5/) ### Workarounds If you aren't able to upgrade you can reinstall aiohttp using `AIOHTTP_NO_EXTENSIONS=1` as an environment variable to disable the llhttp HTTP request parser implementation. The pure Python implementation isn't vulnerable to request smuggling: ```console $ python -m pip uninstall --yes aiohttp $ AIOHTTP_NO_EXTENSIONS=1 python -m pip install --no-binary=aiohttp --no-cache aiohttp ``` ### References * https://nvd.nist.gov/vuln/detail/CVE-2023-30589 * https://hackerone.com/reports/2001873

aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. In aiohttp before version 3.7.4 there is an open redirect vulnerability. A maliciously crafted link to an aiohttp-based web-server could redirect the browser to a different website. It is caused by a bug in the `aiohttp.web_middlewares.normalize_path_middleware` middleware. This security problem has been fixed in 3.7.4. Upgrade your dependency using pip as follows "pip install aiohttp >= 3.7.4". If upgrading is not an option for you, a workaround can be to avoid using `aiohttp.web_middlewares.normalize_path_middleware` in your applications.

### Summary Insufficient restrictions in header/trailer handling could cause uncapped memory usage. ### Impact An application could cause memory exhaustion when receiving an attacker controlled request or response. A vulnerable web application could mitigate these risks with a typical reverse proxy configuration. ----- Patch: https://github.com/aio-libs/aiohttp/commit/0c2e9da51126238a421568eb7c5b53e5b5d17b36

### Summary Improper validation makes it 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. ### Details The vulnerability occurs only if the attacker can control the HTTP method (GET, POST etc.) of the request. Previous releases performed no validation on the provided value. If an attacker controls the HTTP method it will be used as is and can lead to HTTP request smuggling. ### PoC A minimal example can be found here: https://gist.github.com/jnovikov/7f411ae9fe6a9a7804cf162a3bdbb44b ### Impact If the attacker can control the HTTP version of the request it will be able to modify the request (request smuggling). ### Workaround If unable to upgrade and using user-provided values for the request method, perform manual validation of the user value (e.g. by restricting it to a few known values like GET, POST etc.). Patch: https://github.com/aio-libs/aiohttp/pull/7806/files

### Summary Improper validation make it possible for an attacker to modify the HTTP request (e.g. to insert a new header) or even create a new HTTP request if the attacker controls the HTTP version. ### Details The vulnerability only occurs if the attacker can control the HTTP version of the request (including its type). For example if an unvalidated JSON value is used as a version and the attacker is then able to pass an array as the `version` parameter. Furthermore, the vulnerability only occurs when the `Connection` header is passed to the `headers` parameter. At this point, the library will use the parsed value to create the request. If a list is passed, then it bypasses validation and it is possible to perform CRLF injection. ### PoC The POC below shows an example of providing an unvalidated array as a version: https://gist.github.com/jnovikov/184afb593d9c2114d77f508e0ccd508e ### Impact CRLF injection leading to Request Smuggling. ### Workaround If these specific conditions are met and you are unable to upgrade, then validate the user input to the `version` parameter to ensure it is a `str`. Patch: https://github.com/aio-libs/aiohttp/pull/7835/files

### Summary llhttp 8.1.1 is vulnerable to two request smuggling vulnerabilities. Details have not been disclosed yet, so refer to llhttp for future information. The issue is resolved by using llhttp 9+ (which is included in aiohttp 3.8.6+).

### Summary On Windows the static resource handler may expose information about a NTLMv2 remote path. ### Impact If an application is running on Windows, and using aiohttp's static resource handler (not recommended in production), then it may be possible for an attacker to extract the hash from an NTLMv2 path and then extract the user's credentials from there. ----- Patch: https://github.com/aio-libs/aiohttp/commit/0ae2aa076c84573df83fc1fdc39eec0f5862fe3d

### Summary A response with an excessive number of multipart headers may be allowed to use more memory than intended, potentially allowing a DoS vulnerability. ### Impact Multipart headers were not subject to the same size restrictions in place for normal headers, potentially allowing substantially more data to be loaded into memory than intended. However, other restrictions in place limit the impact of this vulnerability. ----- Patch: https://github.com/aio-libs/aiohttp/commit/8a74257b3804c9aac0bf644af93070f68f6c5a6f

### Summary Static routes which contain files with compressed variants (`.gz` or `.br` extension) were vulnerable to path traversal outside the root directory if those variants are symbolic links. ### Details The server protects static routes from path traversal outside the root directory when `follow_symlinks=False` (default). It does this by resolving the requested URL to an absolute path and then checking that path relative to the root. However, these checks are not performed when looking for compressed variants in the `FileResponse` class, and symbolic links are then automatically followed when performing `Path.stat()` and `Path.open()` to send the file. ### Impact Servers with static routes that contain compressed variants as symbolic links, pointing outside the root directory, or that permit users to upload or create such links, are impacted. ---- Patch: https://github.com/aio-libs/aiohttp/pull/8653/files

### Summary When assert statements are bypassed, an infinite loop can occur, resulting in a DoS attack when processing a POST body. ### Impact If optimisations are enabled (`-O` or `PYTHONOPTIMIZE=1`), and the application includes a handler that uses the `Request.post()` method, then an attacker may be able to execute a DoS attack with a specially crafted message. ------ Patch: https://github.com/aio-libs/aiohttp/commit/bc1319ec3cbff9438a758951a30907b072561259

# Summary The HTTP parser in AIOHTTP has numerous problems with header parsing, which could lead to request smuggling. This parser is only used when `AIOHTTP_NO_EXTENSIONS` is enabled (or not using a prebuilt wheel). # Details ## Bug 1: Bad parsing of `Content-Length` values ### Description RFC 9110 says this: > `Content-Length = 1*DIGIT` AIOHTTP does not enforce this rule, presumably because of an incorrect usage of the builtin `int` constructor. Because the `int` constructor accepts `+` and `-` prefixes, and digit-separating underscores, using `int` to parse CL values leads AIOHTTP to significant misinterpretation. ### Examples ``` GET / HTTP/1.1\r\n Content-Length: -0\r\n \r\n X ``` ``` GET / HTTP/1.1\r\n Content-Length: +0_1\r\n \r\n X ``` ### Suggested action Verify that a `Content-Length` value consists only of ASCII digits before parsing, as the standard requires. ## Bug 2: Improper handling of NUL, CR, and LF in header values ### Description RFC 9110 says this: > Field values containing CR, LF, or NUL characters are invalid and dangerous, due to the varying ways that implementations might parse and interpret those characters; a recipient of CR, LF, or NUL within a field value MUST either reject the message or replace each of those characters with SP before further processing or forwarding of that message. AIOHTTP's HTTP parser does not enforce this rule, and will happily process header values containing these three forbidden characters without replacing them with SP. ### Examples ``` GET / HTTP/1.1\r\n Header: v\x00alue\r\n \r\n ``` ``` GET / HTTP/1.1\r\n Header: v\ralue\r\n \r\n ``` ``` GET / HTTP/1.1\r\n Header: v\nalue\r\n \r\n ``` ### Suggested action Reject all messages with NUL, CR, or LF in a header value. The translation to space thing, while technically allowed, does not seem like a good idea to me. ## Bug 3: Improper stripping of whitespace before colon in HTTP headers ### Description RFC 9112 says this: > No whitespace is allowed between the field name and colon. In the past, differences in the handling of such whitespace have led to security vulnerabilities in request routing and response handling. A server MUST reject, with a response status code of 400 (Bad Request), any received request message that contains whitespace between a header field name and colon. AIOHTTP does not enforce this rule, and will simply strip any whitespace before the colon in an HTTP header. ### Example ``` GET / HTTP/1.1\r\n Content-Length : 1\r\n \r\n X ``` ### Suggested action Reject all messages with whitespace before a colon in a header field, as the standard requires. # PoC Example requests are embedded in the previous section. To reproduce these bugs, start an AIOHTTP server without llhttp (i.e. `AIOHTTP_NO_EXTENSIONS=1`) and send the requests given in the previous section. (e.g. by `printf`ing into `nc`) # Impact Each of these bugs can be used for request smuggling.

### Summary Handling of chunked messages can result in excessive blocking CPU usage when receiving a large number of chunks. ### Impact If an application makes use of the `request.read()` method in an endpoint, it may be possible for an attacker to cause the server to spend a moderate amount of blocking CPU time (e.g. 1 second) while processing the request. This could potentially lead to DoS as the server would be unable to handle other requests during that time. ----- Patch: https://github.com/aio-libs/aiohttp/commit/dc3170b56904bdf814228fae70a5501a42a6c712 Patch: https://github.com/aio-libs/aiohttp/commit/4ed97a4e46eaf61bd0f05063245f613469700229

### Summary Multiple Host headers were allowed in aiohttp. ### Impact Mostly this doesn't affect aiohttp security itself, but if a reverse proxy is applying security rules depending on the target Host, it is theoretically possible that the proxy and aiohttp could process different host names, possibly resulting in bypassing a security check on the proxy and getting a request processed by aiohttp in a privileged sub app when using `Application.add_domain()`. ----- Patch: https://github.com/aio-libs/aiohttp/commit/e00ca3cca92c465c7913c4beb763a72da9ed8349 Patch: https://github.com/aio-libs/aiohttp/commit/53e2e6fc58b89c6185be7820bd2c9f40216b3000

### Summary Security-sensitive parts of the *Python HTTP parser* retained minor differences in allowable character sets, that must trigger error handling to robustly match frame boundaries of proxies in order to protect against injection of additional requests. Additionally, validation could trigger exceptions that were not handled consistently with processing of other malformed input. ### Details These problems are rooted in pattern matching protocol elements, previously improved by PR #3235 and GHSA-gfw2-4jvh-wgfg: 1. The expression `HTTP/(\d).(\d)` lacked another backslash to clarify that the separator should be a literal dot, not just *any* Unicode code point (result: `HTTP/(\d)\.(\d)`). 2. The HTTP version was permitting Unicode digits, where only ASCII digits are standards-compliant. 3. Distinct regular expressions for validating HTTP Method and Header field names were used - though both should (at least) apply the common restrictions of rfc9110 `token`. ### PoC `GET / HTTP/1ö1` `GET / HTTP/1.𝟙` `GET/: HTTP/1.1` `Content-Encoding?: chunked` ### Impact Primarily concerns running an aiohttp server without llhttp: 1. **behind a proxy**: Being more lenient than internet standards require could, depending on deployment environment, assist in request smuggling. 2. **directly accessible** or exposed behind proxies relaying malformed input: the unhandled exception could cause excessive resource consumption on the application server and/or its logging facilities. ----- Patch: https://github.com/aio-libs/aiohttp/pull/8074/files

### Summary The Python parser parses newlines in chunk extensions incorrectly which can lead to request smuggling vulnerabilities under certain conditions. ### Impact 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. ----- Patch: https://github.com/aio-libs/aiohttp/commit/259edc369075de63e6f3a4eaade058c62af0df71

### Summary A XSS vulnerability exists on index pages for static file handling. ### Details When using `web.static(..., show_index=True)`, the resulting index pages do not escape file names. If users can upload files with arbitrary filenames to the static directory, the server is vulnerable to XSS attacks. ### Workaround We have always recommended using a reverse proxy server (e.g. nginx) for serving static files. Users following the recommendation are unaffected. Other users can disable `show_index` if unable to upgrade. ----- Patch: https://github.com/aio-libs/aiohttp/pull/8319/files

### Summary A request can be crafted in such a way that an aiohttp server's memory fills up uncontrollably during processing. ### Impact If an application includes a handler that uses the `Request.post()` method, an attacker may be able to freeze the server by exhausting the memory. ----- Patch: https://github.com/aio-libs/aiohttp/commit/b7dbd35375aedbcd712cbae8ad513d56d11cce60

### Impact aiohttp v3.8.4 and earlier are [bundled with llhttp v6.0.6](https://github.com/aio-libs/aiohttp/blob/v3.8.4/.gitmodules) which is vulnerable to CVE-2023-30589. The vulnerable code is used by aiohttp for its HTTP request parser when available which is the default case when installing from a wheel. This vulnerability only affects users of aiohttp as an HTTP server (ie `aiohttp.Application`), you are not affected by this vulnerability if you are using aiohttp as an HTTP client library (ie `aiohttp.ClientSession`). ### Reproducer ```python from aiohttp import web async def example(request: web.Request): headers = dict(request.headers) body = await request.content.read() return web.Response(text=f"headers: {headers} body: {body}") app = web.Application() app.add_routes([web.post('/', example)]) web.run_app(app) ``` Sending a crafted HTTP request will cause the server to misinterpret one of the HTTP header values leading to HTTP request smuggling. ```console $ printf "POST / HTTP/1.1\r\nHost: localhost:8080\r\nX-Abc: \rxTransfer-Encoding: chunked\r\n\r\n1\r\nA\r\n0\r\n\r\n" \ | nc localhost 8080 Expected output: headers: {'Host': 'localhost:8080', 'X-Abc': '\rxTransfer-Encoding: chunked'} body: b'' Actual output (note that 'Transfer-Encoding: chunked' is an HTTP header now and body is treated differently) headers: {'Host': 'localhost:8080', 'X-Abc': '', 'Transfer-Encoding': 'chunked'} body: b'A' ``` ### Patches Upgrade to the latest version of aiohttp to resolve this vulnerability. It has been fixed in v3.8.5: [`pip install aiohttp >= 3.8.5`](https://pypi.org/project/aiohttp/3.8.5/) ### Workarounds If you aren't able to upgrade you can reinstall aiohttp using `AIOHTTP_NO_EXTENSIONS=1` as an environment variable to disable the llhttp HTTP request parser implementation. The pure Python implementation isn't vulnerable to request smuggling: ```console $ python -m pip uninstall --yes aiohttp $ AIOHTTP_NO_EXTENSIONS=1 python -m pip install --no-binary=aiohttp --no-cache aiohttp ``` ### References * https://nvd.nist.gov/vuln/detail/CVE-2023-30589 * https://hackerone.com/reports/2001873

### Summary A memory leak can occur when a request produces a `MatchInfoError`. This was caused by adding an entry to a cache on each request, due to the building of each `MatchInfoError` producing a unique cache entry. ### Impact If the user is making use of any middlewares with `aiohttp.web` then it is advisable to upgrade immediately. An attacker may be able to exhaust the memory resources of a server by sending a substantial number (100,000s to millions) of such requests. ----- Patch: https://github.com/aio-libs/aiohttp/commit/bc15db61615079d1b6327ba42c682f758fa96936

### Impact Aiohttp has a security vulnerability regarding the inconsistent interpretation of the http protocol. As we know that HTTP/1.1 is persistent, if we have both Content-Length(CL) and Transfer-Encoding(TE) it can lead to incorrect interpretation of two entities that parse the HTTP and we can poison other sockets with this incorrect interpretation. A possible Proof-of-Concept (POC) would be a configuration with a reverse proxy(frontend) that accepts both CL and TE headers and aiohttp as backend. As aiohttp parses anything with chunked, we can pass a chunked123 as TE, the frontend entity will ignore this header and will parse Content-Length. I can give a Dockerfile with the configuration if you want. The impact of this vulnerability is that it is possible to bypass any proxy rule, poisoning sockets to other users like passing Authentication Headers, also if it is present an Open Redirect (just like CVE-2021-21330) we can combine it to redirect random users to our website and log the request. ### References - https://github.com/aio-libs/aiohttp/commit/f016f0680e4ace6742b03a70cb0382ce86abe371

### Impact Open redirect vulnerability — a maliciously crafted link to an aiohttp-based web-server could redirect the browser to a different website. It is caused by a bug in the `aiohttp.web_middlewares.normalize_path_middleware` middleware. ### Patches This security problem has been fixed in v3.7.4. Upgrade your dependency as follows: [`pip install aiohttp >= 3.7.4`] ### Workarounds If upgrading is not an option for you, a workaround can be to avoid using `aiohttp.web_middlewares.normalize_path_middleware` in your applications. ### References * [aiohttp @ PyPI] * [GHSA-v6wp-4m6f-gcjg] * [OWASP page on open redirects] ### For more information If you have any questions or comments about this advisory: * Open an issue in the [aiohttp repo](https://github.com/aio-libs/aiohttp/issues/new/choose) * Email us at [email protected] and/or [email protected] Credit: [Jelmer Vernooij] and [Beast Glatisant]. [aiohttp @ PyPI]: https://pypi.org/p/aiohttp [`pip install aiohttp >= 3.7.4`]: https://pypi.org/project/aiohttp/3.7.4/ [GHSA-v6wp-4m6f-gcjg]: https://github.com/aio-libs/aiohttp/security/advisories/GHSA-v6wp-4m6f-gcjg [OWASP page on open redirects]: https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html [Jelmer Vernooij]: https://jelmer.uk [Beast Glatisant]: https://github.com/g147

### Summary An attacker who controls the `reason` parameter when creating a `Response` may be able to inject extra headers or similar exploits. ### Impact In the unlikely situation that an application allows untrusted data to be used in the response's `reason` parameter, then an attacker could manipulate the response to send something different from what the developer intended. ----- Patch: https://github.com/aio-libs/aiohttp/commit/53b35a2f8869c37a133e60bf1a82a1c01642ba2b

### Summary The parser allows non-ASCII decimals to be present in the Range header. ### Impact There is no known impact, but there is the possibility that there's a method to exploit a request smuggling vulnerability. ---- Patch: https://github.com/aio-libs/aiohttp/commit/c7b7a044f88c71cefda95ec75cdcfaa4792b3b96

### Summary An unbounded DNS cache could result in excessive memory usage possibly resulting in a DoS situation. ### Impact If an application makes requests to a very large number of hosts, this could cause the DNS cache to continue growing and slowly use excessive amounts of memory. ----- Patch: https://github.com/aio-libs/aiohttp/commit/c4d77c3533122be353b8afca8e8675e3b4cbda98

### Summary Reading multiple invalid cookies can lead to a logging storm. ### Impact If the ``cookies`` attribute is accessed in an application, then an attacker may be able to trigger a storm of warning-level logs using a specially crafted Cookie header. ---- Patch: https://github.com/aio-libs/aiohttp/commit/64629a0834f94e46d9881f4e99c41a137e1f3326

### Summary When following redirects to a different origin, aiohttp drops the Authorization header, but retains the Cookie and Proxy-Authorization headers. ### Impact The Cookie and Proxy-Authorizations headers could contain sensitive information which may be leaked to an unintended party after following a redirect. ----- Patch: https://github.com/aio-libs/aiohttp/commit/5351c980dcec7ad385730efdf4e1f4338b24fdb6

### Summary The Python parser is vulnerable to a request smuggling vulnerability due to not parsing trailer sections of an HTTP request. ### Impact 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. ---- Patch: https://github.com/aio-libs/aiohttp/commit/e8d774f635dc6d1cd3174d0e38891da5de0e2b6a

### Summary The Python HTTP parser may allow a request smuggling attack with the presence of non-ASCII characters. ### Impact 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. ------ Patch: https://github.com/aio-libs/aiohttp/commit/32677f2adfd907420c078dda6b79225c6f4ebce0

### Summary The C parser (the default for most installs) accepted null bytes and control characters is response headers. ### Impact An attacker could send header values that are interpreted differently than expected due to the presence of control characters. For example, `request.url.origin()` may return a different value than the raw Host header, or what a reverse proxy interpreted it as., potentially resulting in some kind of security bypass. ----- Patch: https://github.com/aio-libs/aiohttp/commit/9370b9714a7a56003cacd31a9b4ae16eab109ba4

### Summary Path normalization for static files prevents path traversal, but opens up the ability for an attacker to ascertain the existence of absolute path components. ### Impact If an application uses `web.static()` (not recommended for production deployments), it may be possible for an attacker to ascertain the existence of path components. ------ Patch: https://github.com/aio-libs/aiohttp/commit/f2a86fd5ac0383000d1715afddfa704413f0711e

### Summary For some multipart form fields, aiohttp read the entire field into memory before checking client_max_size. ### Impact If an application uses `Request.post()` an attacker can send a specially crafted multipart request to force significant temporary memory allocation even when the request is ultimately rejected. ----- Patch: https://github.com/aio-libs/aiohttp/commit/cbb774f38330563422ca0c413a71021d7b944145

### Summary An attacker who controls the `content_type` parameter in aiohttp could use this to inject extra headers or similar exploits. ### Impact If an application allows untrusted data to be used for the multipart `content_type` parameter when constructing a request, an attacker may be able to manipulate the request to send something other than what the developer intended. ----- Patch: https://github.com/aio-libs/aiohttp/commit/9a6ada97e2c6cf1ce31727c6c9fcea17c21f6f06