filelock versions 3.22.0 through 4.2.0 contain a flaw in the stale-lock break mechanism used by SoftFileLock and related classes. This flaw allows a local attacker with write access to the lock directory (such as /tmp) to cause two processes of the lock owner to simultaneously hold the same lock by exploiting inode reuse and race conditions. This results in a high integrity impact where concurrent holders can write protected data without detection. The vulnerability requires local access and a sticky shared directory on ext4 or xfs filesystems. The CVSS 3.1 score is 4.7 (Medium).
The ReadWriteLock and AsyncReadWriteLock components use SQLite databases for locking, but on Linux and other POSIX systems, SQLite reopens the lock database file by name, following symlinks and acting on side files like -journal, -wal, and -shm. This behavior allows a local attacker with write or rename permissions in the directory containing the lock database to manipulate these files, causing the lock user to overwrite files with attacker-controlled data, create or unlink files, or cause lock acquisition failures. The vulnerability affects filelock versions from 3.20.4 through 4.2.0, with fixes starting from version 1.31.0_12. The issue requires a writable directory without the sticky bit and local user access. The CVSS 3.1 score is 7.1 (High), reflecting local attack complexity but high integrity and availability impact.
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 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 the marker, causing the lock to be incorrectly considered stale. This can lead to two processes simultaneously holding the lock and writing to the protected resource without error. The issue arises when the marker file is created with group or other write permissions in a sticky or non-removable directory. The vulnerability has a CVSS score of 4.7 (Medium) and requires local access with low privileges and high attack complexity.
The msgpack-python C extension has a memory leak vulnerability triggered when deserialization rejects a map key under strict_map_key validation. This leak can cause unbounded memory growth and denial of service when processing attacker-controlled MessagePack data. Additionally, the streaming Unpacker API may suffer from a use-after-free or double Py_DECREF due to stale parser-stack references. The issue affects msgpack-python version 2.7.0 up to but not including 2.8.0 and is fixed in version 2.8.0.
A vulnerability in the filelock library's ReadWriteLock and AsyncReadWriteLock implementations allows a local user to cause recursive deletion of directories owned by another user. This occurs when the lock cleanup code removes private .filelock-* directories without verifying the directory has not been renamed by another user. The issue affects macOS since filelock 4.1.1 and POSIX environments without a usable /proc/self/fd, such as containers or chroots without /proc mounted. The vulnerability requires the attacker to have write permission on the directory holding the lock database and the directory must lack the sticky bit. The flaw is fixed in filelock version 4.7.0_1.
The ReadWriteLock and AsyncReadWriteLock classes in pre-commit versions 4.6.0 up to but not including 4.7.0 resolve lock file paths following symlinks, allowing a local attacker with write access to the lock directory to cause the victim process to create or lock files at unintended locations. This can break mutual exclusion between victim processes and cause corruption of protected resources. The issue is fixed in version 4.7.0.
CVE-2026-112934 is a medium-severity local vulnerability in the filelock library (versions >=4.6.2_1 and <4.7.0_1) involving the SoftReadWriteLock mechanism. It allows a different local user who owns the lock's .rw directory tree to cause the lock holder's refresh operation to hang by replacing the holder record with a FIFO (named pipe), which blocks writes and stops the heartbeat thread. Additionally, on Linux systems with permissive hard-link policies (fs.protected_hardlinks=0), the attacker can cause the lock user to overwrite the first ~135 bytes of one of its own private files via a hard link attack. This results in denial of service by stalling lock acquisition and heartbeat, and integrity impact limited to the overwritten record bytes. The issue is patched in version 4.7.0_1.
The filelock library's ReadWriteLock and AsyncReadWriteLock use an SQLite-backed lock database that runs PRAGMA journal_mode=MEMORY on every acquire, causing SQLite to load the entire schema of the lock file. A local unprivileged user who can create or overwrite the lock database file can craft a malicious database that causes every acquire_read or acquire_write call to stall indefinitely, ignoring timeout and blocking flags. 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. A fix is available in version 4.7.0_1.
Certain file locking classes in the filelock library (StrictSoftFileLock, AsyncStrictSoftFileLock, SoftReadWriteLock, AsyncSoftReadWriteLock) adopt ownership of a protocol directory if it already exists, without verifying ownership. This allows a local unprivileged user to pre-create the directory in a shared sticky directory (e.g., /tmp), causing the lock user's process to unknowingly share the lock state. This can lead to multiple processes entering the same critical section simultaneously, integrity violations by allowing two writers, and denial of service by causing lock acquisition to spin indefinitely or consume excessive memory. The vulnerability affects filelock versions 3.30.0 through 4.2.0 and is fixed in version 4.7.0_1.
The filelock library versions 3.30.0 through 4.2.0 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 holders to believe they hold the lock simultaneously. This results in a high integrity impact due to concurrent writes without coordination. The vulnerability requires a specific environment with a permissive umask or default ACL allowing write access to the lock claim directories. The issue is fixed in version 4.7.0_1.