Updated constraints due security reasons (triggered on 2025-11-10T12:11:59+00:00 by 533a6517ab17aac72a3f1a5f3fb7f2508ec19770)

[github-actions]

Dependency issues not solved for Python 3.7

Name	Version	ID	Fix Versions	Description
aiohttp	3.8.6	PYSEC-2024-24	3.9.2	aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. 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 reading a file 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. Disabling follow_symlinks and using a reverse proxy are encouraged mitigations. Version 3.9.2 fixes this issue.
aiohttp	3.8.6	PYSEC-2023-250	3.9.0	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	3.8.6	PYSEC-2023-251	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	3.8.6	PYSEC-2024-26	3.9.2	aiohttp is an asynchronous HTTP client/server framework for asyncio and Python. 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. Being more lenient than internet standards require could, depending on deployment environment, assist in request smuggling. The unhandled exception could cause excessive resource consumption on the application server and/or its logging facilities. This vulnerability exists due to an incomplete fix for CVE-2023-47627. Version 3.9.2 fixes this vulnerability.
aiohttp	3.8.6	GHSA-7gpw-8wmc-pm8g	3.9.4	### 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
aiohttp	3.8.6	GHSA-5m98-qgg9-wh84	3.9.4	### 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: aio-libs/aiohttp@cebe526 aio-libs/aiohttp@7eecdff aio-libs/aiohttp@f21c6f2
aiohttp	3.8.6	GHSA-8495-4g3g-x7pr	3.10.11	### 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
aiohttp	3.8.6	GHSA-9548-qrrj-x5pj	3.12.14	### Summary The Python parser is vulnerable to a request smuggling vulnerability due to not parsing trailer sections of an HTTP request. ### 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@e8d774f
protobuf	4.24.4	GHSA-8qvm-5x2c-j2w7	4.25.8,5.29.5,6.31.1	### Summary Any project that uses Protobuf pure-Python backend to parse untrusted Protocol Buffers data containing an arbitrary number of recursive groups, recursive messages or a series of SGROUP tags can be corrupted by exceeding the Python recursion limit. Reporter: Alexis Challande, Trail of Bits Ecosystem Security Team [email protected] Affected versions: This issue only affects the pure-Python implementation of protobuf-python backend. This is the implementation when PROTOCOL_BUFFERS_PYTHON_IMPLEMENTATION=python environment variable is set or the default when protobuf is used from Bazel or pure-Python PyPi wheels. CPython PyPi wheels do not use pure-Python by default. This is a Python variant of a previous issue affecting protobuf-java. ### Severity This is a potential Denial of Service. Parsing nested protobuf data creates unbounded recursions that can be abused by an attacker. ### Proof of Concept For reproduction details, please refer to the unit tests decoder_test.py and message_test ### Remediation and Mitigation A mitigation is available now. Please update to the latest available versions of the following packages: * protobuf-python(4.25.8, 5.29.5, 6.31.1)
requests	2.31.0	GHSA-9wx4-h78v-vm56	2.32.0	When making requests through a Requests Session, if the first request is made with verify=False to disable cert verification, all subsequent requests to the same origin will continue to ignore cert verification regardless of changes to the value of verify. This behavior will continue for the lifecycle of the connection in the connection pool. ### Remediation Any of these options can be used to remediate the current issue, we highly recommend upgrading as the preferred mitigation. * Upgrade to requests>=2.32.0. * For requests<2.32.0, avoid setting verify=False for the first request to a host while using a Requests Session. * For requests<2.32.0, call close() on Session objects to clear existing connections if verify=False is used. ### Related Links * psf/requests#6655
requests	2.31.0	GHSA-9hjg-9r4m-mvj7	2.32.4	### Impact Due to a URL parsing issue, Requests releases prior to 2.32.4 may leak .netrc credentials to third parties for specific maliciously-crafted URLs. ### Workarounds For older versions of Requests, use of the .netrc file can be disabled with trust_env=False on your Requests Session (docs). ### References psf/requests#6965 https://seclists.org/fulldisclosure/2025/Jun/2
urllib3	1.26.20	GHSA-pq67-6m6q-mj2v	2.5.0	urllib3 handles redirects and retries using the same mechanism, which is controlled by the Retry object. The most common way to disable redirects is at the request level, as follows: python resp = urllib3.request("GET", "https://httpbin.org/redirect/1", redirect=False) print(resp.status) # 302 However, it is also possible to disable redirects, for all requests, by instantiating a PoolManager and specifying retries in a way that disable redirects: python import urllib3 http = urllib3.PoolManager(retries=0) # should raise MaxRetryError on redirect http = urllib3.PoolManager(retries=urllib3.Retry(redirect=0)) # equivalent to the above http = urllib3.PoolManager(retries=False) # should return the first response resp = http.request("GET", "https://httpbin.org/redirect/1") However, the retries parameter is currently ignored, which means all the above examples don't disable redirects. ## Affected usages Passing retries on PoolManager instantiation to disable redirects or restrict their number. By default, requests and botocore users are not affected. ## Impact Redirects are often used to exploit SSRF vulnerabilities. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. ## Remediation You can remediate this vulnerability with the following steps: * Upgrade to a patched version of urllib3. If your organization would benefit from the continued support of urllib3 1.x, please contact [email protected] to discuss sponsorship or contribution opportunities. * Disable redirects at the request() level instead of the PoolManager() level.
zipp	3.15.0	GHSA-jfmj-5v4g-7637	3.19.1	A Denial of Service (DoS) vulnerability exists in the jaraco/zipp library, affecting all versions prior to 3.19.1. The vulnerability is triggered when processing a specially crafted zip file that leads to an infinite loop. This issue also impacts the zipfile module of CPython, as features from the third-party zipp library are later merged into CPython, and the affected code is identical in both projects. The infinite loop can be initiated through the use of functions affecting the Path module in both zipp and zipfile, such as joinpath, the overloaded division operator, and iterdir. Although the infinite loop is not resource exhaustive, it prevents the application from responding. The vulnerability was addressed in version 3.19.1 of jaraco/zipp.

Dependency issues not solved for Python 3.8

Name	Version	ID	Fix Versions	Description
aiohttp	3.10.11	GHSA-9548-qrrj-x5pj	3.12.14	### Summary The Python parser is vulnerable to a request smuggling vulnerability due to not parsing trailer sections of an HTTP request. ### 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@e8d774f
urllib3	1.26.20	GHSA-pq67-6m6q-mj2v	2.5.0	urllib3 handles redirects and retries using the same mechanism, which is controlled by the Retry object. The most common way to disable redirects is at the request level, as follows: python resp = urllib3.request("GET", "https://httpbin.org/redirect/1", redirect=False) print(resp.status) # 302 However, it is also possible to disable redirects, for all requests, by instantiating a PoolManager and specifying retries in a way that disable redirects: python import urllib3 http = urllib3.PoolManager(retries=0) # should raise MaxRetryError on redirect http = urllib3.PoolManager(retries=urllib3.Retry(redirect=0)) # equivalent to the above http = urllib3.PoolManager(retries=False) # should return the first response resp = http.request("GET", "https://httpbin.org/redirect/1") However, the retries parameter is currently ignored, which means all the above examples don't disable redirects. ## Affected usages Passing retries on PoolManager instantiation to disable redirects or restrict their number. By default, requests and botocore users are not affected. ## Impact Redirects are often used to exploit SSRF vulnerabilities. An application attempting to mitigate SSRF or open redirect vulnerabilities by disabling redirects at the PoolManager level will remain vulnerable. ## Remediation You can remediate this vulnerability with the following steps: * Upgrade to a patched version of urllib3. If your organization would benefit from the continued support of urllib3 1.x, please contact [email protected] to discuss sponsorship or contribution opportunities. * Disable redirects at the request() level instead of the PoolManager() level.