Update dependency aiohttp to v3.10.11 [SECURITY] - autoclosed #36

renovate · 2025-06-18T13:13:40Z

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
aiohttp	`==3.8.5` -> `==3.10.11`

GitHub Vulnerability Alerts

CVE-2023-47627

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 printfing into nc)

Impact

Each of these bugs can be used for request smuggling.

GHSA-pjjw-qhg8-p2p9

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

CVE-2023-49082

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

CVE-2023-49081

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

CVE-2024-23829

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:

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)).
The HTTP version was permitting Unicode digits, where only ASCII digits are standards-compliant.
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:

behind a proxy: Being more lenient than internet standards require could, depending on deployment environment, assist in request smuggling.
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

CVE-2024-23334

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

CVE-2024-27306

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

CVE-2024-30251

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 --git a/aiohttp/multipart.py b/aiohttp/multipart.py
index 227be605c..71fc2654a 100644
--- a/aiohttp/multipart.py
+++ b/aiohttp/multipart.py
@&#8203;@&#8203; -338,6 +338,8 @&#8203;@&#8203; 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:
aio-libs/aiohttp@cebe526
aio-libs/aiohttp@7eecdff
aio-libs/aiohttp@f21c6f2

CVE-2024-52304

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: aio-libs/aiohttp@259edc3

Release Notes

aio-libs/aiohttp (aiohttp)

Update dependency aiohttp to v3.10.11 [SECURITY] - autoclosed #36

Update dependency aiohttp to v3.10.11 [SECURITY] - autoclosed #36

Uh oh!

Conversation

renovate bot commented Jun 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

GitHub Vulnerability Alerts

Summary

Details

Bug 1: Bad parsing of Content-Length values

Description

Examples

Suggested action

Bug 2: Improper handling of NUL, CR, and LF in header values

Description

Examples

Suggested action

Bug 3: Improper stripping of whitespace before colon in HTTP headers

Description

Example

Suggested action

PoC

Impact

Summary

Summary

Details

PoC

Impact

Workaround

Summary

Details

PoC

Impact

Workaround

Summary

Details

PoC

Impact

Summary

Details

Impact

Workaround

Summary

Details

Workaround

Summary

Impact

Summary

Impact

Release Notes

Bug fixes

Removals and backward incompatible breaking changes

Miscellaneous internal changes

Bug fixes

Features

Miscellaneous internal changes

Bug fixes

Removals and backward incompatible breaking changes

Miscellaneous internal changes

Bug fixes

Bug fixes

Miscellaneous internal changes

Bug fixes

Features

Removals and backward incompatible breaking changes

Improved documentation

Packaging updates and notes for downstreams

Miscellaneous internal changes

Bug fixes

Miscellaneous internal changes

Bug fixes

Improved documentation

Miscellaneous internal changes

Bug fixes

Miscellaneous internal changes

Bug fixes

Removals and backward incompatible breaking changes

Contributor-facing changes

Miscellaneous internal changes

Bug fixes

renovate bot commented Jun 18, 2025 •

edited

Loading

Bug 1: Bad parsing of `Content-Length` values