See how aiohttp compares to other vendors in security performance
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
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 'followsymlinks' can be used to determine whether to follow symbolic links outside the static root directory. When 'followsymlinks' 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.addroutes([ web.static("/static", "static/", followsymlinks=True), # Remove followsymlinks 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 followsymlinks set to True, it can lead to this vulnerability. This vulnerability has been present since the introduction of the followsymlinks parameter.
Workaround Even if upgrading to a patched version of aiohttp, we recommend following these steps regardless.
If using followsymlinks=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
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 readchunkfromlength()):
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" chunksize = min(size, self.length - self.readbytes) chunk = await self.content.read(chunksize) + if self.content.ateof(): + self.ateof = True return chunk async def readchunkfromstream(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 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
Impact
aiohttp v3.8.4 and earlier are bundled with llhttp v6.0.6 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.addroutes([web.post('/', example)]) web.runapp(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
Workarounds
If you aren't able to upgrade you can reinstall aiohttp using AIOHTTPNOEXTENSIONS=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 $ AIOHTTPNOEXTENSIONS=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 The HTTP parser in AIOHTTP has numerous problems with header parsing, which could lead to request smuggling. This parser is only used when AIOHTTPNOEXTENSIONS is enabled (or not using a prebuilt wheel). Details
Bug 1: Bad parsing of Content-Length values
Description RFC 9110 says this: Content-Length = 1DIGIT
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: +01\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. AIOHTTPNOEXTENSIONS=1) and send the requests given in the previous section. (e.g. by printfing into nc)
Impact Each of these bugs can be used for request smuggling.
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 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
An out-of-bounds heap read could occur in the C response parser while building an error message for a malformed response.
Impact
An attacker controlled server, or possibly an accidental response could trigger a DoS in the client.
Workaround
If unable to upgrade, the Python parser is unaffected and can be used with AIOHTTPNOEXTENSIONS=1.
---
Patch: https://github.com/aio-libs/aiohttp/commit/49f65d54150397892f7bcc4aae887767d51c322d
AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.14.0, using CookieJar.load() with untrusted input may allow arbitrary code execution. Most applications using this function will be doing so with the user's own data, so this is unlikely to affect many applications. Version 3.14.0 patches the issue. If an application does allow attacker controlled files to be loaded, a workaround on older releases would be to sanitize the files before loading.
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
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 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 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
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
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
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
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
It is possible to bypass the maxlinesize 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
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
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 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 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 AIOHTTPNOEXTENSIONS 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
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
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 AIOHTTPNOEXTENSIONS 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 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
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.adddomain().
-----
Patch: https://github.com/aio-libs/aiohttp/commit/e00ca3cca92c465c7913c4beb763a72da9ed8349 Patch: https://github.com/aio-libs/aiohttp/commit/53e2e6fc58b89c6185be7820bd2c9f40216b3000
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 followredirects if this is a concern.
-----
Patch: https://github.com/aio-libs/aiohttp/commit/38d16060037e1bfcd6d677abababa3c2a4bb58fa
Summary
A XSS vulnerability exists on index pages for static file handling.
Details
When using web.static(..., showindex=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 showindex if unable to upgrade.
-----
Patch: https://github.com/aio-libs/aiohttp/pull/8319/files