CVE-2026-112912 in filelock
Summary
by MITRE • 10/20/2026
filelock is a platform-independent file lock for Python. From 3.32.6 until 4.2.1, SoftFileLock can follow a swapped symbolic link during the conditional os.access writability check for a node without its owner-write bit, allowing another local user on a platform and directory configuration that follows the link to infer whether a chosen path exists and is writable from the observable acquisition result. This issue is fixed in version 4.2.1.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
The filelock library provides a mechanism for managing exclusive access to files across different operating systems, ensuring that concurrent processes do not corrupt shared resources by writing simultaneously. A significant security flaw was identified within the SoftFileLock implementation between versions 3.32.6 and 4.2.1. This vulnerability stems from an improper handling of symbolic links during the preliminary checks performed before acquiring a lock. Specifically, when determining if a file is writable via os.access, the underlying operating system may follow a symlink that has been swapped or replaced by another user prior to the actual locking operation. Because SoftFileLock relies on these permission checks rather than atomic operations for initial validation, it creates a race condition window where an attacker can manipulate filesystem state to influence the outcome of the lock acquisition attempt.
This behavior leads to an information disclosure vulnerability classified under CWE-209 as an Information Exposure Through an Error Message, and more critically aligns with CWE-367 Time-of-check Time-of-use (TOCTOU) race conditions. The core issue is that the writability check does not account for changes in the filesystem target between the time of the check and the actual lock acquisition. If a local user creates a symbolic link pointing to a file they do not own or cannot write to, but then swaps it with a symlink pointing to a writable location owned by another process, the library may incorrectly determine writability based on the final state rather than the initial intent. This allows an attacker to infer sensitive information about the filesystem structure and permissions of other users simply by observing whether their lock acquisition succeeds or fails.
The operational impact of this vulnerability is primarily limited to local privilege escalation through reconnaissance rather than direct code execution or denial of service. An attacker with a low-privileged account on the same system can use this flaw as part of an enumeration strategy to map out which directories and files are writable by other users, including potentially sensitive configuration files or application data stores. While it does not directly allow the attacker to modify those files due to subsequent permission checks during the actual write operation, it provides valuable intelligence that could facilitate further attacks such as targeted symlink injection or more precise exploitation of related vulnerabilities in applications relying on filelock for synchronization.
Mitigation strategies focus primarily on upgrading the library to version 4.2.1 where this logic has been corrected to prevent following swapped symlinks during the writability check. For environments unable to upgrade immediately, developers should avoid using SoftFileLock with paths that are subject to user-controlled symlink manipulation and instead consider using exclusive file locking mechanisms provided by the operating system directly or implementing additional validation steps that verify inode consistency rather than just path-based permissions. Additionally, applying strict filesystem permissions and restricting write access to directories containing lock files can reduce the attack surface available for such TOCTOU exploits.