CVE-2026-112941 in filelock
Summary
by MITRE • 10/20/2026
filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, SoftReadWriteLock and AsyncSoftReadWriteLock cache a successful check of the <path>.rw lock tree and resolve its names again during later record operations, allowing another local user who can replace that tree after the first acquisition to redirect lock-record writes into directories writable by the lock user. This issue is fixed in version 4.2.1.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/20/2026
The filelock library for Python provides platform-independent mechanisms for managing exclusive access to files, a critical component in multi-process and distributed application architectures where data integrity relies on preventing concurrent write operations. Versions of the library ranging from 4.1.0 through 4.2.1 contain a logic flaw within the SoftReadWriteLock and AsyncSoftReadWriteLock implementations that undermines this guarantee by introducing an inconsistency between lock acquisition validation and subsequent record writing procedures. This vulnerability stems from how these specific locking classes handle path resolution, creating a window of opportunity for local privilege escalation or data corruption through directory manipulation attacks.
The core technical flaw lies in the caching behavior of successful lock checks against the .rw lock tree structure. When SoftReadWriteLock or AsyncSoftReadWriteLock acquires a lock, it performs an initial validation to ensure that the target path and its associated lock files are secure and accessible by the current user. However, rather than re-validating this state before every write operation, these classes cache the result of that first successful check. During later record operations where data is actually written or appended to the locked file, the library resolves the names within the directory tree again based on cached assumptions about its structure and permissions. This decoupling between initial validation and final execution creates a race condition scenario inherent in the design logic itself.
This architectural oversight allows an attacker with local access who possesses write privileges over directories adjacent to or parent of the lock target to perform a symlink attack or directory replacement maneuver. After the legitimate application has acquired the lock based on its initial check, but before it performs subsequent writes, the attacker can replace the expected file tree structure with symlinks pointing to locations writable by the attacker or other unintended users. Because the library relies on cached validation data rather than re-verifying the path integrity at each write step, it proceeds to redirect lock-record writes into these maliciously substituted directories. This effectively bypasses the intended access controls of the locking mechanism.
The operational impact of this vulnerability is significant for any application relying on filelock for critical synchronization tasks. An attacker can manipulate where lock metadata and record data are stored, potentially leading to unauthorized modification of configuration files, corruption of shared state databases, or injection of malicious content into processes that trust the locked resource. In environments with multiple local users, such as multi-tenant servers or development workstations, this flaw enables one user to interfere with another application's operations by hijacking write targets. The severity is compounded in scenarios where filelock is used for security-sensitive locking mechanisms rather than simple concurrency control, as it violates the fundamental principle of atomicity and integrity expected from exclusive locks.
This vulnerability aligns closely with CWE-20 Improper Input Validation, specifically regarding path traversal or symlink following issues that occur after initial validation steps have been completed. It also relates to CWE-367 Time-of-check Time-of-use (TOCTOU) Race Condition, as the security decision made during lock acquisition is not enforced consistently throughout the lifecycle of the file operations. From a threat modeling perspective using MITRE ATT&CK techniques, this behavior facilitates Local Privilege Escalation via T1548 Abuse Elevation Control Mechanism or Data Injection through T1076 Remote File Copy if combined with other vectors, though primarily it represents an integrity violation within local process synchronization contexts.
To mitigate the risks associated with CVE details involving filelock versions 4.1.0 to 4.2.1, organizations and developers must immediately upgrade to version 4.2.1 or later where this caching logic has been corrected to ensure path validation occurs consistently before each write operation. In addition to upgrading dependencies, security teams should audit applications that utilize SoftReadWriteLock and AsyncSoftReadWriteLock classes for any custom implementations of file locking that might replicate similar patterns of cached state without re-validation. Implementing strict directory permissions on lock directories can also reduce the attack surface by preventing unauthorized users from replacing or manipulating the files within those specific paths, thereby adding a layer of defense-in-depth against symlink-based redirection attacks even if software vulnerabilities persist in other components.