A flaw in filelock versions 3.22.0 through 4.2.0 allows a local user with write access to a sticky shared directory (e.g., /tmp) to cause two processes of the lock owner to simultaneously hold the same lock. This occurs due to inode reuse on filesystems like ext4 and xfs, enabling a stale-lock break to remove a live lock file incorrectly. The vulnerability leads to a high integrity impact as concurrent holders can write protected data without detection.
A vulnerability in filelock versions 4.0.0 through 4.2.0 allows a local user who owns the lock's .rw directory tree to interfere with the SoftReadWriteLock holder refresh mechanism. This can cause the lock user's process to hang when writing to a named pipe (FIFO) or overwrite part of its own private file via a hard link under certain kernel configurations. The issue leads to a denial of service by stalling lock acquisition and heartbeat threads, allowing multiple processes to believe they hold the write lock simultaneously. The vulnerability requires local access and specific filesystem conditions, such as permissive hard-link policies or ownership of the lock directory in a sticky or writable directory. A fix is available in version 3.25.2_5.
A vulnerability in the filelock Python package's ReadWriteLock and AsyncReadWriteLock components allows a local user with write access to the lock database file path to cause every acquire operation to stall or hang indefinitely, ignoring timeout and blocking flags. This happens because the SQLite-backed lock runs a PRAGMA statement that loads the entire schema of the database file, and a crafted database file can cause the acquire to consume excessive CPU and memory or never return. The impact is denial of service (availability) only, with no confidentiality or integrity compromise. Versions 3.20.4 through 4.2.0 are affected.
On Windows, the filelock library's ReadWriteLock and AsyncReadWriteLock use SQLite side files for locking. A local user who can create files but not delete others' files in the lock directory can place a specially crafted side file (e.g., -wal or -journal) beside the database. This causes the lock user to encounter disk I/O errors or unexpected file deletions during lock acquisition, resulting in partial denial of service. The issue affects filelock versions 3.20.4 through 4.2.0 on Windows. A fix is available in version 3.25.2_5.
A symlink swap vulnerability in filelock's SoftFileLock writability check allows a local user to leak one bit of information about whether a path exists and is writable by the lock user. This occurs because the check uses os.lstat followed by os.access, which follows symlinks, enabling a time-of-check to time-of-use (TOCTOU) race condition. The vulnerability affects filelock versions 3.32.6 through 4.2.0 and is mitigated on Linux by the fs.protected_symlinks kernel setting in sticky world-writable directories like /tmp. The impact is limited to leaking a single bit of information per lock acquire attempt, with no integrity or availability impact. The vulnerability requires local access, the ability to create entries in the lock directory, and a race condition timing that is complex to achieve.
The vulnerability involves the StrictSoftFileLock and SoftReadWriteLock classes adopting a protocol directory created by another local user before the lock user's first acquire operation. This allows the other user to interfere with the lock state by unlinking claims or redirecting lock operations, potentially causing multiple writers to enter a critical section simultaneously and causing denial of service by spinning or memory exhaustion. The issue affects filelock versions 3.30.0 through 4.2.0 and requires the attacker to create the directory first in a shared sticky directory like /tmp. The CVSS 3.1 score is 6.3 (Medium).
UnixFileLock, used by FileLock and AsyncFileLock on Unix systems, truncates and changes permissions of any regular file that another local user renames or hard-links onto the lock path. This can lead to unintended file truncation and permission changes, allowing the other user to read and modify the file contents thereafter. The vulnerability affects all filelock releases up to and including 4.2.0, with the chmod behavior introduced since version 3.10.2. Exploitation requires local access and the ability to rename or hard-link files in certain directory conditions. The issue is patched in version 3.25.2_5.
The filelock library versions 3.30.0 through 4.2.0 have a vulnerability in the StrictSoftFileLock and AsyncStrictSoftFileLock classes where claim directories are created without proper restrictive permissions. This allows another local user with write access to the directory to unlink claim files, causing multiple holders to believe they hold the lock simultaneously. The issue arises when the environment's umask or default ACLs permit write access to these directories. The vulnerability impacts integrity by allowing concurrent writes protected by the lock, with no confidentiality or significant availability impact.
On Windows, certain soft lock implementations in filelock (versions 3.22.0 through 4.2.0) can be blocked indefinitely due to Windows opportunistic locks (oplocks) on the lock marker file. Another local user with read access can take a Level 1 oplock on a stale marker file and never release it, causing SoftFileLock.acquire() calls to hang past their timeout. This results in partial availability impact without compromising confidentiality or integrity. The issue is fixed in filelock version 3.25.2_5.
AIOHTTP's pure Python HTTP parser is vulnerable to an HTTP request smuggling attack when used instead of the default C parser. This affects applications using the Python parser, such as those with the AIOHTTP_NO_EXTENSIONS environment or non-standard wheel installations. The vulnerability is fixed in version 3.25.2_5.
A vulnerability in AIOHTTP allows a subdomain to remove the Host-Only flag from an existing cookie set for a parent domain. This could reduce cookie security protections for users accessing untrusted subdomains. The impact is limited because most use cases do not reflect these cookies back to the browser.
CVE-2026-111748 is a vulnerability in aiohttp where an attacker can spoof the Request.scheme attribute by sending an absolute-form HTTP request. This can mislead applications relying on this attribute for security decisions, such as determining whether a connection is encrypted. The issue affects versions >=3.25.2_3 and <3.25.2_5. A fix is available in version 3.25.2_5. A workaround is to use a WAF rule to block absolute-form requests, which are typically only legitimate for proxy usage.
CVE-2026-111066 is a vulnerability in AIOHTTP where an attacker can exhaust file descriptors by sending specially crafted multipart requests. This affects handlers using the Request.post() method, potentially leading to resource exhaustion. The issue is fixed in version 3.25.2_5.
AIOHTTP versions >=3.25.2_3 and <3.25.2_5 contain a vulnerability where an overflow in Max-Age processing can cause connections to remain open, leading to temporary exhaustion of the connection pool until garbage collection intervenes. This flaw has a medium severity with a CVSS score of 6.9. A fix is available in version 3.25.2_5.
The aiohttp server component in Lexicon versions >=3.25.2_3 and <3.25.2_5 lacks an initial request/header timeout, allowing an attacker to keep an idle connection open indefinitely before sending any data. This issue has been fixed in version 3.25.2_5. The vulnerability has a high severity with a CVSS score of 8.2. A recommended workaround is to use a reverse proxy with sensible keepalive limits.
A vulnerability in AIOHTTP allows the Secure attribute of a shared cookie to not be enforced, potentially causing the cookie to be sent over unencrypted requests. This flaw affects versions from 3.25.2_3 up to but not including 3.25.2_5 and has a medium severity rating. A fix is available in version 3.25.2_5.
The Model Context Protocol (MCP) Python SDK versions 1.10.0 through 1.29.1 and 2.0.0 through 2.1.1 have a vulnerability where the client fetches server-chosen external $ref URLs during tool output schema validation. This can cause the client to make network or local file requests synchronously without timeout, potentially freezing the client session. The issue is fixed in versions 1.30.0 and 2.2.0, which restrict reference resolution to within the schema document only.
PyJWT versions up to 2.13.0 and current master before 2.26.0 contain a vulnerability where the HMAC verification accepts an empty key when using octet JWKs. This allows an attacker to forge tokens without knowing any secret if the application verifies tokens using a JWK/JWKS with an empty 'k' value. The issue arises because the empty key rejection implemented for string/bytes keys is not applied to keys loaded from JWKs. The vulnerability is fixed in PyJWT version 2.26.0.
The Model Context Protocol (MCP) Python SDK versions 1.8.0 through 1.29.1 and 2.0.0 through 2.1.1 have a vulnerability where HTTP client transports follow cross-origin redirects and send custom headers and, on 307/308 redirects, the request body to the redirected host. This can expose sensitive headers like X-API-Key if an attacker can cause a trusted endpoint to redirect to a malicious host. The Authorization bearer header is not exposed due to HTTP library protections. The issue is fixed in MCP SDK versions 3.0.3 and later.