A vulnerability in virtualenv's app-data copy seeder causes files copied from a cached environment to retain file permissions from the cache, potentially resulting in files with broader access than intended. This occurs because shutil.copy preserves the cached file modes regardless of the current umask. An attacker with access to the new environment and the ability to traverse it can exploit this to modify files such as pip scripts. The issue affects virtualenvwrapper versions prior to 4.8.4_2 and 6.1.1_4. A fix has been released that enforces stricter file permission policies when copying files from the cache.
CVE-2026-112941 is a local integrity vulnerability in filelock versions 4.1.0 through 4.2.0 involving SoftReadWriteLock and AsyncSoftReadWriteLock. A local user with write access to the lock's parent directory can replace the lock directory tree with one containing symbolic links after the first lock acquire. This causes the lock user’s process to write lock records through these symbolic links, resulting in unintended file modifications in directories writable by the lock user. The issue requires no race condition and affects Linux and POSIX platforms. The vulnerability has low CVSS impact, with no confidentiality or availability impact, only low integrity impact due to replacement of lock-related files.
The filelock ReadWriteLock and AsyncReadWriteLock components use SQLite databases for locking, but on Linux, SQLite reopens the lock database by name following symlinks and acting on side files like -journal, -wal, and -shm. This behavior allows a local attacker who can create or rename files in the directory holding the lock database (if it is writable without the sticky bit) to cause the lock user to write arbitrary data into their own files, create or unlink files, or disrupt locking operations. The vulnerability affects filelock versions 3.20.4 through 4.2.0, with fixes starting in 6.1.1_4 for virtualenvwrapper. The CVSS 3.1 score is 7.1 (High), reflecting local attack with low complexity and high integrity and availability impact but no confidentiality impact.
A vulnerability in filelock versions 3.22.0 through 4.2.0 allows a local user with write access to a lock marker file to forge the process ID in that marker. This causes another process running as the lock owner or root to incorrectly consider the lock stale, remove the live marker, and acquire the lock simultaneously. This results in two processes entering the critical section concurrently without error. The issue requires specific conditions on file permissions and directory settings, such as group or other write bits on the marker and a sticky or non-removable directory.
A vulnerability in filelock versions >=6.1.1_3 and <6.1.1_4 allows a local unprivileged user with write access to a shared directory to swap a symbolic link in place of a lock directory between a check and subsequent operations. This can cause the lock user's process to create claim files in an attacker-chosen directory, potentially disrupting other locks and causing denial of service until manually resolved.
A vulnerability in filelock versions 4.1.0 through 4.2.0 allows a local user with write permission on the directory holding the lock database to rename directories and cause the lock user's process to recursively delete arbitrary directories. This occurs because the ReadWriteLock and AsyncReadWriteLock implementations remove private .filelock-* link directories without verifying that the path still points to the originally created directory. The issue affects macOS since version 4.1.1 and POSIX environments without a usable /proc/self/fd, such as chroots or containers without /proc mounted. The vulnerability has a CVSS score of 6.1 (Medium) and results in high integrity impact by enabling deletion of directories owned by the lock user without error reporting.
A vulnerability in filelock versions 3.22.0 through 4.2.0 allows a local unprivileged user to cause two processes of the lock owner to simultaneously hold the same lock due to a race condition involving inode reuse and stale lock file breaking. This occurs on filesystems like ext4 and xfs that reuse inode numbers immediately after file deletion, combined with a sticky shared directory such as /tmp. The issue leads to high integrity impact as concurrent holders can write protected data without detection, but does not affect confidentiality or availability.
CVE-2026-112934 is a medium severity vulnerability in filelock versions >=6.1.1_3 and <6.1.1_4 used by virtualenvwrapper. It involves the SoftReadWriteLock mechanism refreshing its holder record by reopening and writing to a file without verifying the file type beyond symbolic links. A local attacker who owns the lock's .rw directory can rename a FIFO (named pipe) or a hard link over the holder record file, causing the lock user's write or read lock operations to hang or overwrite part of a private file. This leads to a denial of service by stalling lock acquisition and heartbeat threads, and can cause two processes to believe they hold the write lock simultaneously. The vulnerability requires local access and certain filesystem conditions, such as permissive hard link policies on Linux or default macOS/BSD behavior. A fix is available in version 6.1.1_4.
The filelock library's ReadWriteLock and AsyncReadWriteLock use an SQLite-backed lock database. A crafted lock database file placed by a local user at the lock path can cause every acquire operation to stall or hang indefinitely, ignoring timeout and blocking parameters. This results in a denial of service affecting availability only, without compromising confidentiality or integrity. The issue affects filelock versions 3.20.4 through 4.2.0. A fix is available in version 6.1.1_4 of the related virtualenvwrapper product.
A vulnerability in filelock versions 4.1.0 through 4.2.0 allows a local unprivileged user who can write to a shared lock directory without the sticky bit to exploit a race condition involving symbolic links and hard links. This can lead to the creation of a hard link to a file owned by the lock user, exposing file metadata and enabling the attacker to manipulate the file's name. On version 4.2.0, this can result in truncation of the lock user's file. The issue arises due to the restore branch of the stale-lock break process following symbolic links when creating hard links, which is affected by changes in CPython 3.12 and later on Linux and macOS. The vulnerability requires specific conditions including a writable non-sticky directory and repeated lock acquisition by the lock user.
A symlink swap race condition in the SoftFileLock implementation allows a local user with write access to the lock directory to leak one bit of information about whether a path exists and is writable by the lock user. This occurs because the writability check follows symlinks after an lstat call, enabling a time-of-check to time-of-use (TOCTOU) leak. 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 existence and writability of a chosen path, with no integrity or availability effects. The vulnerability is rated low severity with a CVSS score of 2.5 due to high attack complexity and limited information leakage.
A vulnerability in the filelock library versions >=6.1.1_3 and <6.1.1_4 allows a local unprivileged user to pre-create a protocol directory used for lock ownership state. This causes the locking mechanism to adopt a directory owned by the attacker, enabling them to interfere with lock claims and potentially cause multiple processes to enter critical sections simultaneously. The issue affects StrictSoftFileLock and SoftReadWriteLock classes, leading to integrity and availability impacts without confidentiality loss. The vulnerability requires the attacker to win initial ownership of the protocol directory before the lock user's first acquire operation, typically in shared sticky directories like /tmp. The CVSS 3.1 score is 6.3 (Medium). A fix is available in version 6.1.1_4.
UnixFileLock, used by FileLock and AsyncFileLock on Unix, truncates and can change permissions of any regular file that another local user renames or hard-links onto the lock path. This occurs when the lock user acquires the lock and the file at the lock path is unexpectedly replaced by a file controlled by another user. The vulnerability requires the attacker to have local access and the ability to rename or hard-link files in certain directory conditions. The flaw affects all filelock versions up to and including 4.2.0, with fixes available in later versions.
The vulnerability in filelock versions >=3.30.0 and <=4.2.0 involves the creation of claim directories without proper restrictive permissions, allowing other local users with write access to these directories to unlink claim files. This can lead to multiple holders believing they have exclusive locks, causing integrity issues. The flaw requires specific environment conditions such as a permissive umask or default ACLs that grant write permissions to other users. The vulnerability has a medium severity with no confidentiality impact but high integrity impact.
A vulnerability in filelock versions 4.1.0 through 4.2.0 allows a local unprivileged user to evict a lock file held by another user by exploiting inode reuse and coarse clock timestamp manipulation on ext4 or overlayfs filesystems. This causes two processes of the lock owner to enter a critical section simultaneously, violating lock integrity without affecting confidentiality or availability. The attack requires specific timing conditions and filesystem behavior, making it a high complexity local attack with medium severity.
The msgpack-python C extension has an unbounded memory leak when deserializing MessagePack data with strict_map_key validation enabled (default). If a map key is invalid, the decoded map value is leaked, causing process memory growth and potential denial of service. This affects both unpackb() and the streaming Unpacker API. Additionally, a use-after-free or double Py_DECREF issue exists in the streaming Unpacker due to stale parser-stack references after nested container parsing. The pure-Python fallback does not exhibit this leak. The issue is confirmed in msgpack version 1.2.2 and fixed in 2.10.1_2.