A vulnerability in filelock versions >=1.31.0_11 and <1.31.0_12 allows a local 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 to create claim files in an attacker-chosen directory, potentially disrupting other locks by causing stranded claims that lead to denial of service until manually cleared. The issue requires a race condition and specific directory permissions, and has medium severity with a CVSS score of 5.8.
The filelock library versions 4.1.0 through 4.2.0 contain a vulnerability in the ReadWriteLock and AsyncReadWriteLock mechanisms where private .filelock-* directories are deleted recursively without verifying the directory's identity. This can be exploited by another local user who can rename directories in the shared parent directory (without sticky bit protection) to cause the lock user's process to delete arbitrary directories with the lock user's permissions. The issue affects macOS since version 4.1.1 and POSIX systems without a usable /proc/self/fd, such as chroot or containers without /proc mounted. The vulnerability has a CVSS 3.1 score of 6.1 (Medium) and results in high integrity impact due to unauthorized deletion of directory trees.
The ReadWriteLock and AsyncReadWriteLock classes in the affected software resolve lock file paths by following symlinks, which allows a local attacker with write access to the lock directory to manipulate the locking mechanism. This can cause the victim process to create or write files at unintended locations, break mutual exclusion between processes, or cause database locking conflicts. The issue affects versions from 1.31.0_9 up to but not including 1.31.0_11 and has been fixed in version 1.31.0_11.
A vulnerability in the filelock library versions 3.22.0 through 4.2.0 allows a local user with write access to a sticky shared directory (e.g., /tmp) on ext4 or xfs filesystems to cause two processes of the lock owner to simultaneously hold the same lock. This occurs due to inode reuse and a race condition in the stale-lock break logic of SoftFileLock and related classes, leading to integrity violations without confidentiality or availability impact.
CVE-2026-112934 describes a vulnerability in filelock versions >=1.31.0_11 and <1.31.0_12 where the SoftReadWriteLock holder refresh mechanism can be manipulated by a local user who owns the lock's .rw directory tree. This user can cause the lock user's process to hang indefinitely by placing a FIFO (named pipe) in the holders directory, blocking write operations and preventing heartbeat refreshes. Additionally, on systems that permit hard links to files not owned by the user (e.g., Linux with fs.protected_hardlinks=0), the attacker can cause the lock user to overwrite part of one of its own private files. The vulnerability has no confidentiality impact but can cause integrity degradation and high availability impact by allowing two processes to believe they hold the write lock simultaneously. A fix is available in version 1.31.0_12.
A vulnerability in the filelock library'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 settings. This is achieved by placing a crafted SQLite database file at the lock path, which causes the lock acquisition to consume excessive CPU or memory resources, resulting in denial of service. The issue affects filelock versions 3.20.4 through 4.2.0 and has no impact on confidentiality or integrity, only availability.
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 the soft-lock stale break restore mechanism. This flaw enables the attacker to cause the lock process to create a hard link to one of the lock user's own files, exposing file metadata and allowing the attacker to rename the link. On version 4.2.0, this can lead to truncation of the targeted file by the lock user. The issue arises due to symbolic link following behavior in os.link on CPython 3.12+ on Linux and macOS. The vulnerability requires specific conditions including a writable non-sticky directory shared by users on the same filesystem. The CVSS 3.1 score is 5.3 (Medium).
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 due to a time-of-check to time-of-use (TOCTOU) race condition involving os.lstat and os.access calls that handle symlinks differently. The vulnerability affects filelock versions 3.32.6 through 4.2.0 and requires the attacker to have write access to the lock directory and the ability to observe the lock user's acquire outcome. Linux kernel setting fs.protected_symlinks mitigates this in typical sticky world-writable directories like /tmp, but not in others. The issue is rated low severity with a CVSS score of 2.5.
A vulnerability in filelock's StrictSoftFileLock and SoftReadWriteLock classes allows a local unprivileged user to pre-create a protocol directory in a shared sticky directory (e.g., /tmp) before the lock user acquires it. This causes the lock implementation to adopt a directory owned by the other user, enabling them to interfere with lock claims and potentially cause multiple processes to enter the same critical section simultaneously. The issue affects filelock versions 3.30.0 through 4.2.0 and is rated medium severity with CVSS 6.3. The vulnerability requires local access and a race condition where the attacker creates the directory first. It impacts integrity and availability but not confidentiality.
UnixFileLock, used by FileLock and AsyncFileLock on Unix, truncates and changes permissions of any regular file that another local user renames or hard-links onto the lock path before the lock user's next acquire. 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 chmod behavior introduced since 3.10.2. Exploitation requires local access and the ability to rename or hard-link files in directories without the sticky bit or with specific kernel settings. The issue is fixed in version 1.31.0_12.
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.