The filelock library versions >=1.31.0_11 and <1.31.0_12 have a vulnerability in StrictSoftFileLock and AsyncStrictSoftFileLock 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 processes to believe they hold the lock simultaneously. This leads to integrity issues where two holders can write protected data concurrently without detection. The vulnerability requires specific conditions involving umask or default ACLs that leave the directories writable by other users. The issue is fixed in version 1.31.0_12.
A vulnerability in filelock versions 4.1.0 through 4.2.0 allows a local unprivileged user to cause a lock file to be evicted prematurely by exploiting inode reuse and coarse clock timestamp manipulation on ext4 or overlayfs filesystems. This can lead to two processes simultaneously entering a critical section protected by the lock, causing high integrity impact without affecting confidentiality or availability.
An unauthenticated remote denial of service vulnerability exists in the Twisted HTTP/2 server (CVE-2023-44487). A remote client can rapidly send a request header with END_STREAM followed immediately by a stream reset, causing the server to render the request before processing the reset. Because reset streams are freed and do not count against the concurrent-stream limit, this can be repeated at line rate on a single connection, exhausting CPU resources. This vulnerability affects Twisted version 26.4.0 and is classified as high severity with no confidentiality or integrity impact.
A vulnerability in twisted.names.dns.DNSDatagramProtocol allows DNS response spoofing due to missing source address validation. The protocol accepts DNS responses based solely on matching transaction IDs without verifying the source address, enabling off-path attackers to inject forged DNS answers. While the standard twisted.names.client.Resolver mitigates this risk by using per-query random source ports, direct use of DNSDatagramProtocol or reuse of the same source port removes this protection. This flaw affects all consumers of twisted's DNS client UDP transport, including twisted.mail's MX lookups.
A vulnerability in virtualenv's bash activation script allows an attacker-controlled prompt value to be inserted unescaped into the PS1 environment variable when the bash shell option 'promptvars' is off at activation time. Because 'promptvars' and posix mode can be re-enabled later in the same shell or in child shells, the stored prompt value is expanded and any embedded command substitutions are executed. This regression was introduced in version 21.14.9 and persists through 21.14.12. The issue affects the bash 'bin/activate' script and can lead to command execution as the user activating the environment.
CVE-2026-113723 is a vulnerability in virtualenv's bash activation prompt handling under older bash compatibility modes (4.2 and lower). An attacker who can supply the prompt text to virtualenv can craft it so that it becomes executable shell syntax when the environment is activated and the prompt is drawn. This affects POSIX activation scripts and certain shells like dash when PS1 is exported. The vulnerability was introduced in virtualenv 20.0.0b1 and 21.14.7 and fixed in 4.8.4_2 and 6.1.1_4.
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.