CVE-2026-112914 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, SoftFileLock can restore a stale marker by name after moving it aside, allowing another local user with rename access in a non-sticky lock directory to swap in a symbolic link and, on a runtime that follows the link and a same-filesystem target, make the lock user hard-link one of its files into the lock directory. This issue is fixed in version 4.2.1.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
The filelock library for Python provides platform-independent mechanisms to manage exclusive access to resources via file locking. A critical vulnerability exists within the SoftFileLock implementation, specifically affecting versions from 4.1.0 through 4.2.1. This flaw stems from an improper handling of stale lock markers during the cleanup and restoration process. When a previous instance of a locked resource terminates unexpectedly or is terminated abruptly, leaving behind a marker file that indicates a lock exists but does not correspond to an active holder, the library attempts to restore this state by moving the marker aside for verification. However, the logic governing this operation fails to adequately validate the integrity and type of files involved in the directory operations, creating a window for local privilege escalation or denial of service attacks through file system manipulation.
The core technical flaw involves a race condition combined with insufficient validation when handling symbolic links within non-sticky lock directories. In Unix-like operating systems, sticky bits on directories prevent users from deleting or renaming files they do not own unless they are the directory owner. Without this protection, an attacker who has rename access to the lock directory can exploit the timing gap between the library moving a stale marker aside and its subsequent restoration logic. By placing a symbolic link in the target location before the library attempts to restore the original file structure, the attacker forces the application to follow the symlink. If the runtime environment resolves this path correctly and points to a same-filesystem target that the attacker controls or can influence, the vulnerability is triggered.
This scenario allows for a more severe exploitation vector where the lock user, operating under their own privileges, inadvertently hard-links one of its files into the attacker-controlled directory structure via the symlinked path. This action effectively bypasses standard file permission checks because the operation appears to be performed by the legitimate application process itself rather than an external malicious actor. The result is that the attacker gains indirect control over the contents or metadata of files owned by the lock user, potentially leading to data corruption, unauthorized modification of critical configuration files, or denial of service if essential system files are overwritten or unlinked during this swap operation.
From a classification perspective, this vulnerability aligns with CWE-367, which describes Time-of-check Time-of-use (TOCTOU) race conditions in file operations. The application checks the existence and state of a lock marker but uses that information to perform an action on a different object due to the intervening symlink swap. Furthermore, it relates to CWE-59, Improper Link Resolution Before File Access, as the system follows symbolic links without ensuring they point to safe or expected targets within the context of file locking semantics. In terms of offensive security frameworks such as MITRE ATT&CK, this behavior can be categorized under T1076, which involves Windows Remote Desktop Protocol abuse in broader contexts but more accurately maps to local privilege escalation techniques involving symbolic link following and race conditions for lateral movement or persistence if the locked resource is a critical system component.
The operational impact of this vulnerability depends heavily on the context in which filelock is used. If applied to sensitive application data, it could lead to integrity violations where an attacker modifies configuration files or database locks without detection. In multi-user environments such as shared servers or development workstations, any local user with write access to the lock directory can potentially disrupt services running under different user accounts by corrupting their state files. This undermines the fundamental guarantee of mutual exclusion that file locking is designed to provide, rendering the protection mechanism ineffective and exposing applications to reliability issues and potential security breaches.
Mitigation strategies primarily involve upgrading to version 4.2.1 or later, where this logic has been corrected to prevent the restoration of stale markers in a manner susceptible to symlink attacks. For environments that cannot immediately upgrade, administrators should ensure that lock directories are created with sticky bits enabled using chmod commands such as chmod +t on Unix-like systems. This restricts file renaming and deletion operations to only those users who own the files or the directory itself, thereby neutralizing the attacker's ability to swap in symbolic links during the race window. Additionally, applications should avoid storing lock files in world-writable directories whenever possible, opting instead for user-specific temporary directories that are not accessible by other local users on the system.