CVE-2026-112936 in filelock
Summary
by MITRE • 10/20/2026
filelock is a platform-independent file lock for Python. From 3.20.4 until 4.0.9, ReadWriteLock and AsyncReadWriteLock versions from 3.20.4 resolve the lock path and pass it to SQLite without rejecting a final symbolic link, allowing another local user who can create names in the lock directory to redirect database creation and locking or split mutual exclusion between targets. This issue is fixed in version 4.0.9.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/20/2026
The filelock library for Python provides platform-independent mechanisms for managing exclusive access to files through locking primitives such as ReadWriteLock and AsyncReadWriteLock. A critical vulnerability exists within versions ranging from 3.20.4 up to, but not including, the fixed release of 4.0.9. This flaw stems from an insufficient validation mechanism regarding file system paths during the initialization of lock objects that utilize SQLite databases for state management or coordination. Specifically, when these locking classes resolve the path provided by the application developer, they fail to reject inputs where the final component is a symbolic link rather than a regular directory or file entry. This oversight allows an attacker who possesses write permissions within the target lock directory to manipulate the underlying storage mechanism used by the library.
The technical core of this vulnerability lies in how SQLite handles database creation and locking when presented with a path that resolves through a symlink. By creating a symbolic link named identically to the expected lock file or directory, an attacker can redirect the operation to write into or lock a completely different location on the local filesystem. This redirection effectively bypasses the intended isolation boundaries of the application using filelock. Consequently, mutual exclusion guarantees are compromised because the lock is no longer applied to the resource originally targeted by the developer but instead to a path chosen by an unprivileged user with directory creation privileges in that specific context.
The operational impact of this flaw is significant for any Python application relying on filelock for concurrency control or exclusive access enforcement, particularly those running as privileged users or handling sensitive data. An attacker can exploit this condition to cause denial of service by locking critical system files or other applications out of their necessary resources. Furthermore, the ability to redirect database creation poses a risk of unauthorized data persistence or corruption in unintended locations. In scenarios where filelock is used for coordinating access to shared configuration files or temporary state directories, an attacker could potentially inject malicious logic or disrupt application workflows by controlling which processes hold the lock and when they release it. This represents a classic case of path traversal via symbolic link manipulation, leading to privilege escalation effects relative to the intended scope of the lock.
From a classification perspective, this vulnerability aligns with CWE-59 Improper Link Resolution Before File Access, as the system fails to properly validate that the resolved file is not a symlink before performing operations on it. It also relates to CWE-732 Incorrect Permission Assignment for Critical Resource, since the locking mechanism assumes exclusive access without verifying the integrity of the target path against unauthorized redirections. In terms of offensive security frameworks, this behavior can be leveraged within ATT&CK techniques related to Defense Evasion or Privilege Escalation, specifically where an attacker manipulates file system objects to bypass intended restrictions and gain control over resource availability for other processes.
To mitigate this vulnerability, organizations must ensure that all instances of the filelock library are upgraded to version 4.0.9 or later, which implements stricter path validation logic to reject symbolic links in lock paths. For applications where upgrading is not immediately feasible, developers should implement additional safeguards by validating the resolved real path of any directory intended for locking using standard operating system calls that resolve symlinks before passing them to filelock functions. Additionally, restricting write permissions on directories containing lock files to only trusted users and processes can reduce the attack surface available to local adversaries attempting to create malicious symbolic links. Regular auditing of third-party dependencies is essential to maintain this security posture as new versions are released.