CVE-2026-112940 in filelock
Summary
by MITRE • 10/20/2026
filelock is a platform-independent file lock for Python. From 3.20.4 until 4.2.1, ReadWriteLock let SQLite reopen the database and side files by name; on POSIX systems an attacker with rename access in a non-sticky parent can swap those names to cause overwrite or unlink operations, while a writable adjacent hot journal is additionally required for attacker-chosen content overwrites. 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 provides platform-independent file locking mechanisms for Python applications, ensuring that concurrent processes do not interfere with one another when accessing shared resources. A critical vulnerability was identified within the ReadWriteLock implementation between versions 3.20.4 and 4.2.1. This flaw specifically affects how SQLite databases and their associated side files are handled during lock acquisition or release operations. The core technical issue stems from the library's reliance on reopening these database files by name rather than using file descriptors that remain stable across filesystem changes. In POSIX-compliant operating systems, this approach introduces a race condition vulnerability known as a Time-of-Check to Time-of-Use (TOCTOU) error. When an application attempts to access or modify a SQLite database through the vulnerable version of filelock, it resolves the filename at one point in time and then performs operations on that path later. If an attacker possesses rename privileges within the parent directory containing the lock files but not necessarily write permissions for the sticky bit-protected directories themselves, they can exploit this timing gap to swap filenames.
This manipulation allows a malicious actor to redirect file operations intended for legitimate database side files toward arbitrary targets controlled by the attacker. The primary impact of this vulnerability is the potential for unauthorized data overwrites or the deletion of critical system and application files. By swapping names in a non-sticky parent directory, an attacker can cause the SQLite engine to write into a different file than originally intended. For instance, if the lock mechanism attempts to create or update a journal file associated with the database, the rename attack could redirect this operation to overwrite sensitive configuration files, log files, or even executable binaries depending on the context in which the vulnerable Python application runs. The severity of the impact is further amplified when an attacker can also control writable adjacent hot journals, as this enables them to dictate specific content within the overwritten file rather than merely causing a denial of service through unlinking operations. This capability transforms what might otherwise be a simple disruption into a potential code execution or privilege escalation vector if the targeted files are processed by higher-privilege services later.
From a classification perspective, this vulnerability aligns with CWE-367, which describes Time-of-check to time-of-use (TOCTOU) race conditions involving file systems. The attack scenario also maps closely to MITRE ATT&CK technique T1558, specifically the Steal or Forge Authentication Credentials sub-technique if authentication data is stored in SQLite files, or more broadly to T1499 Endpoint Denial of Service and T1070 Indicator Removal on Hosts when used for destructive purposes. The vulnerability highlights a common pitfall in cross-platform file locking implementations where developers prioritize ease of use over strict filesystem semantics that guarantee atomicity and isolation under adversarial conditions. Secure coding practices dictate that applications should utilize open file descriptors or operate within directories with sticky bits enabled to prevent such renaming attacks, ensuring that the identity of a file is bound to its inode rather than its mutable name in the directory listing.
To mitigate this vulnerability, organizations must immediately upgrade the filelock library to version 4.2.1 or later, where the developers have addressed the race condition by implementing more robust handling mechanisms for database and side files. For environments where upgrading is not immediately feasible, administrators should enforce strict filesystem permissions that prevent non-root users from renaming files in directories containing sensitive SQLite databases. Additionally, deploying applications within sticky-bit protected temporary directories can significantly reduce the attack surface by ensuring that only the file owner or root can rename or delete files within those locations. Regular auditing of Python dependencies and maintaining an up-to-date software bill of materials are essential practices to detect such vulnerabilities early. Security teams should also monitor for unusual filesystem activity, particularly rapid renaming operations in application data directories, as this may indicate active exploitation attempts against unpatched systems.