CVE-2026-112937 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, ReadWriteLock can remove a randomized .filelock-* private-hard-link directory during cleanup, allowing another local user with rename access in a non-sticky parent to observe a live name or forge a dead-owner sweep name and rename a sibling directory onto it for deletion. This issue is fixed in version 4.2.1.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
The filelock library provides platform-independent file locking mechanisms for Python applications, ensuring that resources are accessed by only one process at a time to prevent data corruption or race conditions. However, versions ranging from 4.1.0 through 4.2.1 contain a critical implementation flaw within the ReadWriteLock component related to how temporary lock files and directories are managed during cleanup operations. Specifically, when releasing locks or cleaning up stale state, the library creates randomized private hard-link directories prefixed with .filelock-*. The vulnerability arises because these directories are created in parent directories that lack sticky bit permissions, which is a standard Unix/Linux security feature designed to prevent users from deleting or renaming files owned by other users.
This architectural oversight allows for a local privilege escalation scenario where an attacker can exploit the race condition between directory creation and cleanup. Because the parent directory does not enforce strict ownership controls via the sticky bit, another local user with rename permissions in that same directory can intercept the operation. The attacker can observe the live name of the randomized lock directory before it is fully removed or forge a dead-owner sweep name to manipulate the filesystem state. By renaming a sibling directory onto the target .filelock-* path, the attacker effectively forces the deletion of their own chosen directory under the guise of cleaning up the library's temporary files. This constitutes an insecure temporary file handling vulnerability where predictable or manipulable paths in insufficiently protected directories lead to unauthorized resource destruction.
From a classification perspective, this issue aligns with CWE-377, which describes Insecure Temporary File creation, and more specifically relates to CWE-59, Improper Link Resolution Before File Access (Link Following), as the manipulation relies on renaming operations that affect file system integrity. In terms of offensive security frameworks such as MITRE ATT&CK, this vulnerability facilitates Local Privilege Escalation techniques where an attacker leverages improper access controls and race conditions to disrupt service availability or potentially escalate privileges by causing denial-of-service against other users sharing the same directory space. The impact is primarily a Denial of Service for local users who share write permissions in non-sticky directories, as their data can be inadvertently deleted during the lock cleanup process initiated by another user's application using filelock.
To mitigate this vulnerability, organizations and developers must upgrade to version 4.2.1 or later of the filelock library, where the internal logic has been corrected to ensure safe handling of temporary files regardless of parent directory permissions. For environments that cannot immediately patch, administrators should enforce strict filesystem policies by ensuring that directories used for application-specific lock files have the sticky bit set (chmod +t). This ensures that only the owner of a file or directory can delete or rename it, thereby neutralizing the ability of other local users to manipulate the cleanup process. Additionally, applications should avoid creating temporary locks in world-writable directories such as /tmp unless necessary, and instead utilize dedicated, permission-restricted directories for lock management to minimize the attack surface associated with race conditions and symlink attacks.