Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
55 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
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+).
Recommended action: Upgrade to 3.8.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 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…
Recommended action: Upgrade to 3.8.6 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 3.8.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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 Sending a crafted HTTP request will cause the server to misinterpret one of the HTTP header values leading to HTTP request smuggling. 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:…
Recommended action: Upgrade to 3.8.5 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.webmiddlewares.normalizepathmiddleware 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.webmiddlewares.normalizepathmiddleware 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 Email us at wk+aio-libs-security@sydorenko.org.ua and/or andrew.svetlov+aio-libs-security@gmail.com 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]:…
Recommended action: Upgrade to 3.7.4 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.