GHSA-27mf-ghqm-j3j8 CVE-2024-52303 PYSEC-2026-1096
aiohttp has a memory leak when middleware is enabled when requesting a resource with a non-allowed method
- Severity
- 0.0 / 10
- High · CVSS 4.0
- Exploit chance (EPSS)
- 0.59%
- Chance of exploitation in the next 30 days. Higher than 48.29% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-772 Missing Release of Resource after Effective Lifetime
- Fix
3.10.11- Upgrade aiohttp to this version or later
Description
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
Affected versions
PyPI
| Package | Vulnerable | Fixed in |
|---|---|---|
| aiohttp | >= 3.10.6, < 3.10.11 |
3.10.11 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
aiohttp PyPI → 3.10.11
- pip
pip install --upgrade "aiohttp>=3.10.11"- poetry
poetry add "aiohttp>=3.10.11"- uv
uv add "aiohttp>=3.10.11"
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
- Attack vector
- Network
- Attack complexity
- Low
- Attack requirements
- None
- Privileges required
- None
- User interaction
- None
- Confidentiality (vulnerable system)
- None
- Integrity (vulnerable system)
- None
- Availability (vulnerable system)
- Low
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- None
- Availability (subsequent systems)
- None
CVSS 3.1 7.5
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
- Attack vector
- Network
- Attack complexity
- Low
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- None
- Integrity
- None
- Availability
- High
Weakness
CWE-772: Missing Release of Resource after Effective Lifetime
The product does not release a resource after its effective lifetime has ended, i.e., after the resource is no longer needed.
How to prevent it
- Requirements: Use a language that does not allow this weakness to occur or provides constructs that make this weakness easier to avoid. For example, languages such as Java, Ruby, and Lisp perform automatic garbage collection that releases memory for objects that have been deallocated.
- Implementation: It is good practice to be responsible for freeing all resources you allocate and to be consistent with how and where you free resources in a function. If you allocate resources that you intend to free upon completion of the function, you must be sure to free the resources at all exit points for that function including error conditions.
- Operation, Architecture and Design: Use resource-limiting settings provided by the operating system or environment. For example, when managing system resources in POSIX, setrlimit() can be used to set limits for certain types of resources, and getrlimit() can determine how many resources are available. However, these functions are not available on all operating systems. When the current levels get close to the maximum that is defined for the application (see CWE-770), then limit the allocation of further resources to privileged users; alternately, begin releasing resources for less-privileged users. While this mitigation may protect the system from attack, it will not necessarily stop attackers from adversely impacting other users. Ensure that the application performs the appropriate error checks and error handling in case resources become unavailable (CWE-703).
References
Advisories
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-pqxq-w44r-73xw AIOHTTP: Pure-Python parser request smuggling | Medium | Also affects aiohttp |
| GHSA-gx76-c99x-2c96 AIOHTTP: Cookie from subdomain can remove Host-Only Scope from existing cookies | Low | Also affects aiohttp |
| GHSA-f9xw-jh8m-3mwq AIOHTTP: Absolute-form request targets can spoof Request.scheme | Medium | Also affects aiohttp |
| GHSA-9xw5-w5jj-pvcg AIOHTTP: File descriptor exhaustion in multipart requests | High | Also affects aiohttp |
| GHSA-6cjc-53gc-5rqm AIOHTTP: Connector pool exhaustion via Max-Age overflow | Medium | Also affects aiohttp |
| GHSA-5wr8-gcqf-gqf3 aiohttp server lacks an initial request/header timeout | High | Also affects aiohttp |
| GHSA-494j-54xm-rwp3 AIOHTTP: Secure attribute not enforced for shared cookie | Medium | Also affects aiohttp |
| GHSA-2g87-pp6c-29x5 aiohttp: Multiple instances of excessive or unbounded memory/CPU use | High | Also affects aiohttp |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor