CVE-2026-112941 describes a local integrity vulnerability in the SoftReadWriteLock implementation used by filelock versions 4.1.0 through 4.2.0. A local unprivileged user with write access to the lock's parent directory can replace the lock directory tree with symbolic links after the lock's initial acquisition, causing the lock user process to write lock records into attacker-controlled paths. This results in the lock user's files being replaced or deleted, breaking functionality such as a git repository's operation. The vulnerability requires specific conditions including directory write access and the presence of sticky bits in parent directories like /tmp. The impact is limited to integrity loss with no confidentiality or availability impact. The CVSS 3.1 base score is 3.3 (Low).
The ReadWriteLock and AsyncReadWriteLock components of filelock use SQLite databases for locking, but on Linux, SQLite reopens the lock database by name, following symlinks and acting on side files such as -journal, -wal, and -shm. This behavior allows a local attacker with write permissions in the directory containing the lock database to manipulate these files, causing the lock user to write arbitrary data into their own files, create or unlink files, or cause lock acquisition failures. The vulnerability affects filelock versions 3.20.4 through 4.2.0, with the /proc/self/fd redirect introduced in 4.0.9 and side-file variants since 3.20.4. The CVSS 3.1 score is 7.1 (High), reflecting local attack complexity but high integrity and availability impact. The issue requires a writable, non-sticky directory accessible to the attacker. In sticky directories like /tmp, a planted -wal file causes lock acquisition failures. Kernel settings such as fs.protected_regular and fs.protected_hardlinks influence the exploitability. No confidentiality impact is noted.
A vulnerability in the filelock library versions 3.22.0 through 4.2.0 allows a local user with write access to a lock marker file (but without permission to remove it) to forge the process ID in the marker. This causes the lock to be incorrectly considered stale, enabling two processes to hold the lock simultaneously and potentially corrupt shared data. The issue arises when the marker file is created with group or other write permissions, such as with a permissive mode or a lax umask in a sticky or non-removable directory.
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 critical 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 impact includes denial of service by causing stranded claims that block other locks until manually force-broken. The vulnerability requires local access and specific directory permissions, with medium severity (CVSS 5.8).
A vulnerability in the filelock Python package versions 4.1.0 through 4.2.0 allows a local user with write permission on the directory containing the lock database to rename directories in a way that causes the lock user's process to recursively delete arbitrary directories. This occurs because the ReadWriteLock and AsyncReadWriteLock implementations remove their 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 chroot or containers without /proc mounted. The vulnerability requires a non-sticky, writable shared parent directory and allows deletion of directories owned by the lock user, resulting in integrity and partial availability loss. The CVSS 3.1 score is 6.1 (Medium).
A vulnerability in the filelock library 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 soft file lock. This occurs due to a race condition in the stale-lock break mechanism that relies on inode numbers and modification times, which can be manipulated on filesystems like ext4 and xfs that reuse inode numbers immediately. The issue requires a sticky shared directory writable by the attacker and at least two contending processes by the lock owner. The vulnerability impacts integrity by allowing concurrent lock holders without detection but does not affect confidentiality or availability.
CVE-2026-112934 describes a vulnerability in the SoftReadWriteLock mechanism used by the filelock library versions 4.0.0 through 4.2.0. The flaw 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 file with a FIFO (named pipe) or a hard link. This can cause the lock holder's write or read lock operations to hang indefinitely and prevent the heartbeat thread from running, leading to a state where two processes believe they hold the write lock simultaneously. The vulnerability requires local access and specific filesystem conditions, such as permissive hard-link policies on Linux or default macOS/BSD behavior. The impact includes denial of service (availability) and low integrity degradation due to partial overwriting of private files.
A vulnerability in filelock'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 triggers expensive schema loading operations that consume significant CPU and memory resources. The issue affects filelock versions 3.20.4 through 4.2.0 and results in a denial of service condition without compromising confidentiality or integrity.
A vulnerability in filelock versions 4.1.0 through 4.2.0 allows a local unprivileged user to exploit a race condition in the SoftFileLock stale-break restore process. By replacing a lock file marker with a symbolic link in a writable, non-sticky shared directory, the attacker can cause the lock user to create a hard link to one of their own files. This exposes file metadata and allows the attacker to manipulate the file's name. On version 4.2.0, this can lead to truncation of the file by the lock user's subsequent FileLock operation. The vulnerability requires specific conditions including a writable non-sticky directory and CPython 3.12 or later on Linux/macOS.
On Windows, the filelock library's ReadWriteLock and AsyncReadWriteLock use SQLite side files for locking. A local user who can create files in the lock directory but cannot delete others' files can place a specially crafted SQLite side file (such as a -wal or -journal file) beside the database. This causes the lock user’s attempts to acquire read or write locks to fail with disk I/O errors or unexpected file deletions until the side file is removed. This affects filelock versions 3.20.4 through 4.2.0 on Windows in directories where untrusted users can create but not delete files, such as C:\Windows\Temp and C:\Users\Public. The vulnerability has a low CVSS score (3.3) due to its local attack vector and limited impact on availability only.
A symlink swap race condition in the SoftFileLock implementation of the filelock library allows a local user with write access to the lock directory to leak one bit of information about the existence and writability of arbitrary paths. This occurs because the writability check follows symlinks under certain conditions, revealing whether the symlink target exists and is writable by the lock user. The issue affects filelock versions 3.32.6 through 4.2.0 and is mitigated on Linux by the fs.protected_symlinks kernel setting in common sticky world-writable directories like /tmp. The vulnerability has low severity due to high attack complexity and limited information leakage.
The vulnerability affects the StrictSoftFileLock and SoftReadWriteLock classes in the filelock library versions 3.30.0 through 4.2.0. These classes adopt a protocol directory created by another local user without verifying ownership, allowing that user to interfere with lock claims. This can lead to multiple writers entering critical sections simultaneously, silent compromise of lock integrity, and denial of service by causing lock acquisition to spin indefinitely or consume excessive memory. The issue requires the attacker to create the protocol directory before the lock user's first acquire, typically in shared sticky directories like /tmp. The vulnerability has no confidentiality impact but high integrity and availability impacts, with a CVSS 3.1 score of 6.3 (Medium).
The filelock library on Windows ignores the specified file mode (e.g., 0o600) when creating lock files and the ReadWriteLock database. Instead of applying restrictive permissions, the created files inherit the directory's ACL, potentially allowing other local accounts with inherited access to read or modify these lock files. This can lead to partial confidentiality, integrity, and availability impacts, such as unauthorized reading of lock metadata, corruption of lock state, and denial of lock acquisition by the legitimate owner. The issue affects filelock versions 3.10.0 through 4.2.0 on Windows.
The UnixFileLock component in the FileLock and AsyncFileLock libraries on Unix truncates and changes permissions (chmod) 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, potentially allowing the other user to read and modify the file contents if a permissive mode is set. The vulnerability requires local user access and specific filesystem conditions such as writable non-sticky directories or disabled kernel hardlink protection. It affects all filelock releases up to and including 4.2.0.
The vulnerability in filelock versions 3.30.0 through 4.2.0 involves the creation of claim directories without restrictive permissions, allowing other local users with write access to those directories to unlink claim files. This can lead to multiple holders simultaneously writing protected data without detection, causing integrity issues. The flaw requires specific conditions related to umask and default ACL settings that leave the claim directories writable by other users. The impact is limited to local users and does not affect confidentiality but can compromise data integrity and availability.
On Windows, certain soft lock implementations in the filelock library (versions 3.22.0 through 4.2.0) can be blocked indefinitely by another local user exploiting Windows opportunistic locks (oplocks) on the lock marker file. This happens when a stale lock marker file is present and another local account with read access takes a Level 1 oplock on it without releasing it. As a result, attempts to acquire the lock by the original user hang past their timeout, causing partial availability impact without compromising confidentiality or integrity.
A vulnerability in filelock versions 4.1.0 through 4.2.0 allows a local unprivileged user to cause a lock eviction by exploiting inode reuse and coarse clock timestamp manipulation on ext4 or overlayfs filesystems. This results in two processes of the lock owner entering a critical section simultaneously, violating lock integrity without affecting confidentiality or availability. The attack requires specific timing conditions and filesystem behavior, making exploitation complex and unreliable.