A vulnerability in virtualenv's POSIX console launcher generation allows attacker-controlled destination paths to be interpreted as shell syntax. This occurs because the interpreter path is not properly escaped in the shell wrapper, enabling shell command injection when running generated launchers. The issue affects POSIX console scripts created by virtualenv's app-data seeder or pip when a shell wrapper is required. Windows executable launchers are not affected. Exploitation requires an attacker to influence the environment destination path and the user to run the generated launcher, resulting in execution of arbitrary shell commands with the user's privileges.
CVE-2026-113721 is a vulnerability in virtualenv where generated activation files and pyvenv.cfg can follow existing symbolic links and write outside the intended environment. This occurs because the code checks for file existence without handling dangling symlinks properly, allowing writes to arbitrary locations if an attacker can prepare links beforehand. The issue affects environment creation and seeding files, potentially overwriting files outside the virtual environment. The vulnerability requires that another user can place links in the destination and that the invoking user has write permissions to the linked targets. A fix is available in versions 1.2.2_1 and 2.5.1_1.
Virtualenv versions prior to 1.2.2_1 and 2.5.1_1 have a vulnerability where files copied from a cached app-data directory retain file permissions from the cache rather than applying the current environment's umask. This can result in files with overly permissive access rights in new environments if the cache was created with a permissive umask, potentially allowing other local users to modify files such as pip scripts. The issue arises because shutil.copy preserves the source file mode, overriding the current umask. A fix is available in versions 1.2.2_1 and 2.5.1_1, which enforce stricter file permissions when copying from the cache.
A vulnerability in virtualenv's builtin environment creator allows writes outside the intended environment directory when directory symlinks are present. This occurs because the ensure_dir() function follows existing symlinks and writes environment files through them, potentially affecting directories controlled by another user. The issue affects versions prior to 1.2.2_1 and 2.5.1_1 and has a medium severity rating.
The filelock ReadWriteLock and AsyncReadWriteLock components use SQLite databases for locking but pass SQLite a filename they do not fully control. On Linux, SQLite reopens the lock database by name via /proc/self/fd, following symlinks and acting on side files like -journal, -wal, and -shm. A local attacker who can create or rename files in the directory holding the lock database (a writable directory without the sticky bit) can exploit this to cause the lock user to write arbitrary data into their own files, create or unlink files, or cause lock acquisition failures. This affects filelock versions 3.20.4 through 4.2.0, with the fixed version being 2.5.1_1 for poetry. The vulnerability requires local access and specific directory permissions to exploit.
A vulnerability in filelock versions 3.22.0 through 4.2.0 allows a local user with write access to a lock marker file (but not removal rights) to forge the process ID in the marker. This causes the lock to be incorrectly considered stale, enabling two processes to simultaneously hold the lock and write to the protected resource without error. The issue arises when the marker file is group- or other-writable, typically due to permissive file modes or umask settings in sticky or restricted directories. The vulnerability has medium severity with a CVSS score of 4.7.
A vulnerability in filelock versions 3.30.0 through 4.2.0 allows a local user with write access to a shared directory to swap a symbolic link in place of a lock coordination directory during a narrow timing window. This causes the lock user's process to create claim files in a directory chosen by the attacker but writable only by the lock user. The effect can cause denial of service by making other locks time out until manually force-broken. The vulnerability requires local access and specific directory permissions, with medium severity impact.
The ReadWriteLock and AsyncReadWriteLock classes in poetry versions >=2.3.2_1 and <2.5.1_1 resolve lock file paths following symlinks and open them with sqlite3.connect() without preventing symlink traversal. This allows a local attacker with write access to the lock directory to cause the victim process to create or lock files at attacker-controlled locations, potentially breaking mutual exclusion and corrupting protected resources. The issue affects Linux, macOS, and Windows 11. A fix is available in version 2.5.1_1.
A vulnerability 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 soft file lock. This occurs due to inode reuse and a race condition in stale-lock breaking logic, which can lead to integrity issues where two holders 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 lock holder's refresh operations. By replacing the holder record with a FIFO (named pipe), the attacker can cause the lock holder's write or read lock operations to hang indefinitely, preventing heartbeat refreshes and allowing multiple processes to believe they hold the lock simultaneously. Additionally, on systems where the kernel permits hard links to files not owned by the user (e.g., Linux with fs.protected_hardlinks=0), the attacker can cause the lock holder to overwrite the first ~135 bytes of one of its own private files with lock holder data. The vulnerability has a CVSS score of 6.1 (Medium) and affects local users with low privileges but no confidentiality impact.
A vulnerability in filelock's ReadWriteLock and AsyncReadWriteLock components allows a local user who can place or overwrite the lock database file to cause every acquire operation to stall or hang indefinitely, ignoring timeout and blocking settings. This results in a denial of service affecting availability only, with no confidentiality or integrity impact. The issue affects filelock versions 3.20.4 through 4.2.0 and requires the attacker to have write access to the lock file path, typically in a non-sticky shared directory or a writable database owned by the lock user. The vulnerability is rated medium severity with a CVSS score of 5.5 and has been fixed in version 2.5.1_1 of the affected product poetry.
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) leak. The vulnerability affects filelock versions 3.32.6 through 4.2.0 and requires the attacker to create entries in the lock directory and race the lock user's acquire calls. Linux's fs.protected_symlinks kernel setting mitigates this in sticky world-writable directories like /tmp, but not in others. The impact is limited to a low-severity confidentiality leak of a single bit per acquire attempt. A fix is available in filelock version 2.5.1_1.
A vulnerability in the filelock library versions 3.30.0 through 4.2.0 allows a local unprivileged user to pre-create a protocol directory used by StrictSoftFileLock and SoftReadWriteLock. This causes the lock to adopt a directory owned by the attacker, enabling them to interfere with lock claims, potentially allowing concurrent writers and denial of service conditions. The flaw requires the attacker to create the directory before the lock user's first acquire on that path, typically in shared sticky directories like /tmp. The vulnerability has a medium CVSS score of 6.3 and impacts integrity and availability but not confidentiality. A fix is available in version 2.5.1_1.
UnixFileLock, used by FileLock and AsyncFileLock on Unix systems, truncates and can change permissions of any regular file that another local user renames or hard-links onto the lock path before the lock is acquired. This allows a local attacker with write access to certain directories to cause the lock user to truncate and potentially expose files to unauthorized read/write access. The vulnerability affects all filelock releases up to and including 4.2.0 and requires specific conditions such as writable non-sticky directories or disabled kernel hardlink protections. The CVSS 3.1 score is 6.1 (Medium).
The filelock vulnerability (CVE-2026-112908) affects versions of the poetry package >=2.4.2 and <2.5.1_1. It involves the StrictSoftFileLock and AsyncStrictSoftFileLock classes creating claim directories without applying the intended restrictive mode, resulting in directories that may be writable by other local users under certain umask or ACL configurations. This allows another local user with write access to unlink claim files, causing the lock to be bypassed and potentially allowing concurrent holders to write protected data without detection. The vulnerability has a medium severity with a CVSS score of 5.3 and is fixed in version 2.5.1_1.
PyJWT versions up to 2.13.0 and the current master branch contain a vulnerability where the HMAC verification accepts an empty key when using JWKs with an oct key type and an empty 'k' value. This allows an attacker to forge tokens without knowledge of a secret if the application verifies tokens using such a JWK. The issue arises because the empty key rejection implemented for string/bytes secrets was not applied to the JWK verification path. This flaw is fixed in PyJWT version 0.12.0_5.
The Model Context Protocol (MCP) Python SDK client versions 1.10.0 through 1.29.1 and 2.0.0 through 2.1.1 have a vulnerability where the client fetches server-declared external $ref URLs during tool output schema validation. This can cause the client to synchronously fetch arbitrary HTTP, HTTPS, or file URLs from the client's network position, potentially stalling the client if the target is unresponsive. The issue affects applications using the SDK as a client calling tools on untrusted servers. Fixed in versions 1.30.0 and 2.2.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 their HTTP client transports follow cross-origin HTTP redirects and send custom headers and, on certain redirects, the request body to the redirected host. This behavior can expose sensitive headers like API keys if an attacker can cause a trusted endpoint to redirect to a malicious or unintended host. The SDK's OAuth client providers are similarly affected. The lone Authorization bearer header is not exposed due to existing HTTP library protections. MCP servers and clients with redirect following disabled are not affected. Fixed in MCP versions 1.30.0 and 2.2.0.
FastMCP versions 3.0.0 through 3.4.9 and 4.0.0 through 4.1.1 contain an authorization vulnerability where direct calls to transformed components skip the final authorization check. This allows low-privilege users to invoke protected tools, resources, templates, or prompts that should be denied by policy. The issue arises because transforms modify component metadata but the authorization check is performed on the original component, not the transformed one. Fixes are available in FastMCP versions 3.4.10 and 4.1.2. Until patched, users should avoid overlapping proxy templates for protected resources and enforce authorization at the handler or server boundary.
Authlib versions prior to 0.23.1_2 contain a critical signature verification bypass vulnerability in the JsonWebSignature.deserialize_json() method. This flaw allows an attacker to submit a JSON Web Signature (JWS) object with an empty signatures array, which is incorrectly accepted as valid without any cryptographic verification. As a result, attacker-crafted payloads can be accepted as authenticated, leading to a complete authentication bypass. The issue is fixed in version 0.23.1_2.