### Summary
The client accepts and decompresses frames with the RSV1 bit set even when the `permessage-deflate` extension was not negotiated.
### Impact
A client may unexpectedly decompress WebSocket frames when explicitly opted out. This could lead to additional CPU/memory consumption, but is unlikely to be a significant issue unless a zip bomb vulnerability or similar is also present.
---
Patch: https://github.com/aio-libs/aiohttp/commit/47fb6ae354d4fa22048f4dbe7dbf82b625f0a2f6
### Summary
Payload resources are not closed correctly when a client disconnects in the middle of a write.
### Impact
If a payload is using an open file or similar limited resource, then an attacker may be able to cause resource starvation temporarily until garbage collection or similar closes the file.
-----
Patch: https://github.com/aio-libs/aiohttp/commit/a762eda5242f6490d6ba667533193f8b473ad587
### Summary
Host-only cookies that are saved with ``CookieJar.save()`` and then restored later with ``CookieJar.load()`` lose their host-only status.
### Impact
Host-only cookies that have been loaded from disk may get sent to subdomains that previously should have been disallowed.
-----
Patch: https://github.com/aio-libs/aiohttp/commit/a329a7aacad5284f087af36103aff778746da0f2
### Summary
During cleanup it is possible for a compressed request body to be decompressed into memory in one chunk.
### Impact
An attacker may be able to send a compressed payload in specific situations that could be decompressed into memory, potentially leading to DoS (a zip bomb edge case).
### Workaround
Disable compression if unable to upgrade.
-----
Patch: https://github.com/aio-libs/aiohttp/commit/4f7480e474cccc6a8cc2c92ad3f17a31dedf8232
### Summary
It is possible to bypass the max_line_size check in parts of an HTTP request in the C parser.
### Impact
If using the optimised C parser (the default in pre-built wheels), then an attacker may be able to send oversized lines through the HTTP parser and use an excessive amount of memory, potentially leading to DoS.
-----
Patch: https://github.com/aio-libs/aiohttp/commit/5ab61bb4cd88f19b712f12c7c9295fe262bf804d
### Summary
``DigestAuthMiddleware`` can send an authentication response after following a cross-origin redirect.
### Impact
If the client follows a redirect (the default option) to an attacker controlled domain, the attacker may be able to extract the auth digest.
This likely requires an open redirect vulnerability or similar on the target domain for an attacker to be able to execute. Further, the attacker is only receiving the digest, so should only be able to extract the user's credentials if the cryptography is weak or there is some kind of password reuse.
### Workaround
Disable ``follow_redirects`` if this is a concern.
-----
Patch: https://github.com/aio-libs/aiohttp/commit/38d16060037e1bfcd6d677abababa3c2a4bb58fa
### Summary
The `server_hostname` TLS SNI check can be bypassed when an existing connection is reused.
### Impact
If an application makes multiple requests to the same domain, but with different per-request `server_hostname` parameters, then the later calls may succeed by reusing the existing connection when they should have been rejected due to the TLS SNI check.
### Workaround
Disable keep_alive if you need to change the `server_hostname` check between requests.
-----
Patch: https://github.com/aio-libs/aiohttp/commit/0ca2b6c28a25726527a8b60f25960262a91ed0e0
### Summary
If an attacker sends large incomplete websocket frame payloads, it may be possible to bypass the usual size limits on memory use.
### Impact
If a web application has WebSocket endpoints, it may be possible for an attacker to execute a DoS attack through excessive memory use.
-----
Patch: https://github.com/aio-libs/aiohttp/commit/14b6ee851fb16ec199acb950de0c82d476799e7d
### Summary
No limit was present on the number of pipelined requests that could be queued.
### Impact
An attacker may be able to use pipelined requests to use excessive amounts of memory, potentially leading to DoS.
-----
Patch: https://github.com/aio-libs/aiohttp/commit/dfdfa9d5aad5d21f91c79fb2ceeba0f8046cb6cf
### Summary
Attacker-controlled input included into multipart/payload headers can be used to modify a request to inject additional headers or similar.
### Impact
In the unlikely situation that an application is passing user-controlled strings into `MultipartWriter.append(headers=...)` or `Payload.headers`, then an attacker may be able to modify the request to inject headers or change the contents of the request.
### Workaround
Sanitise such user input.
-----
Patch: https://github.com/aio-libs/aiohttp/commit/bf88077ebb14f4c29924b8e8904cba20c55c28b8
### Summary
Cookies set with the `cookies` parameter on requests are sent after following a cross-origin redirect.
### Impact
If a developer uses the `cookies` parameter on a per-request basis then sensitive data might be leaked to an attacker if they manage to control a redirect.
### Workaround
If unable to upgrade, using a `Cookie` header in the `headers` parameter is not vulnerable.
-----
Patch: https://github.com/aio-libs/aiohttp/commit/f54c40851b0d6c4bbdab97ba518a223adda32478
### Summary
Using ``CookieJar.load()`` with untrusted input may allow arbitrary code execution.
### Impact
Most applications using this function will be doing so with the user's own data, so this is unlikely to affect many applications.
### Workaround
If an application does allow attacker controlled files to be loaded, a workaround on older releases would be to sanitise the files before loading.
-----
Patch: https://github.com/aio-libs/aiohttp/commit/dcf40f30637e8752c76781cf6703b5a236749a00
### 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
The C parser (the default for most installs) accepted null bytes and control characters in request 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
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
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
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
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
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
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