CVE-2025-69227 is a medium severity vulnerability in aiohttp versions prior to 3.13.3 that can cause an infinite loop leading to a denial-of-service (DoS) attack. The flaw arises when Python optimizations are enabled (using -O or PYTHONOPTIMIZE=1), which bypass assert statements in aiohttp's handling of POST requests. An attacker can send a specially crafted POST request to trigger this infinite loop, causing the server to hang and become unresponsive. No authentication or user interaction is required, and the attack can be executed remotely over the network. This vulnerability affects asynchronous Python applications using aiohttp for HTTP client/server functionality. The issue is fixed in aiohttp version 3.13.3.
CVE-2025-69226 is a medium severity path traversal vulnerability in aiohttp versions prior to 3.13.3, an asynchronous HTTP client/server framework for Python. The flaw allows attackers to infer the existence of absolute path components via the path normalization logic used for serving static files, specifically when using the web.static() method, which is not recommended for production. Exploitation does not require authentication or user interaction and can leak information about the file system structure, potentially aiding further attacks. The vulnerability has a CVSS 4.0 base score of 6.3, indicating moderate risk. No known exploits are currently reported in the wild.
CVE-2025-69224 is a medium severity HTTP request smuggling vulnerability in aiohttp versions prior to 3.13.3. It affects the Python HTTP parser when non-ASCII characters are present and the pure Python implementation is used (i.e. , without C extensions or when AIOHTTP_NO_EXTENSIONS is enabled). This flaw allows attackers to bypass certain firewalls or proxy protections by crafting malicious HTTP requests that are inconsistently interpreted by intermediaries and the server. Exploitation does not require authentication or user interaction but does require network access to the vulnerable server. No known exploits are currently reported in the wild. The vulnerability impacts confidentiality and integrity by enabling request smuggling attacks that can lead to unauthorized request execution or data leakage.
AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Versions 3.13.2 and below allow a zip bomb to be used to execute a DoS against the AIOHTTP server. An attacker may be able to send a compressed request that when decompressed by AIOHTTP could exhaust the host's memory. This issue is fixed in version 3.13.3.
### 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
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
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
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.
A path traversal vulnerability exists in aiohttp versions prior to 3.8.5 when serving static routes with compressed file variants (.gz or .br) that are symbolic links. The server's default protection against path traversal does not apply to these compressed variants, allowing symbolic links to be followed outside the root directory. This can lead to unauthorized file access if such symbolic links point outside the intended directory or if users can create/upload them.
### 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. Prior to version 3.10.11, the Python parser parses newlines in chunk extensions incorrectly which can lead to request smuggling vulnerabilities under certain conditions. 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.10.11 fixes the issue.
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. 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. 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.
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.