CVE-2026-112934 in filelock
Summary
by MITRE • 10/20/2026
filelock is a platform-independent file lock for Python. From 4.0.0 until 4.2.1, SoftReadWriteLock refreshes holder records by name, allowing another local user with rename access to the lock directory to replace a record with a named pipe and stall the lock, or under a permissive hard-link policy to link a reachable target file and cause the lock user to write through it. This issue is fixed in version 4.2.1.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/20/2026
The vulnerability identified in Python's filelock library affects versions ranging from 4.0.0 up to, but not including, 4.2.1. The core of this security flaw lies within the implementation of the SoftReadWriteLock mechanism, which is designed to manage concurrent access to files by maintaining holder records that track lock ownership and state. Under normal operation, these records are stored as regular files within a designated lock directory. However, the logic used to refresh or update these holder records relies on operations that do not sufficiently validate file types before proceeding with read or write actions. Specifically, when refreshing holder records by name, the library fails to distinguish between standard regular files and special filesystem objects such as named pipes (FIFOs) or symbolic links. This lack of strict type checking creates a window for local privilege escalation and denial-of-service attacks against applications relying on this locking mechanism for data integrity.
An attacker with access to the same lock directory, which typically requires only basic file creation permissions in that specific location, can exploit this behavior through two primary vectors. First, by replacing an existing holder record file with a named pipe, the attacker can cause any process attempting to acquire or refresh the read-write lock to block indefinitely when it attempts to write to what it believes is a regular file but is actually a FIFO. This results in a denial of service condition where legitimate application threads hang waiting for I/O operations that will never complete because no reader exists on the other end of the pipe. Second, if the system permits hard links and the attacker has access to create them within or pointing toward the lock directory, they can link a reachable target file into the position expected by the holder record. When the locked application subsequently writes data under the assumption that it is updating its own state file, it inadvertently overwrites the linked target file. This leads to unauthorized modification of arbitrary files accessible to the user running the vulnerable process, potentially leading to further compromise depending on the sensitivity and permissions of those targeted files.
From a classification perspective, this vulnerability aligns with CWE-59 Improper Link Resolution Before File Access, as it involves manipulating filesystem links or special file types to redirect I/O operations to unintended targets. It also relates closely to CWE-367 Time-of-check Time-of-use (TOCTOU) Race Condition, although the specific manifestation here is more about improper handling of file attributes during refresh cycles rather than a strict race between check and use in concurrent threads. In terms of MITRE ATT&CK mapping, this behavior can be associated with T1548 Abuse Elevation Control Mechanism if used to escalate privileges by modifying critical system files via hard links, or more broadly under T1053 Scheduled Task/Job for persistence mechanisms that might rely on file locks, and T1079 Application Process Discovery if the hanging processes are leveraged for reconnaissance. The fundamental issue is a failure in input validation regarding filesystem object types during state management operations.
The operational impact of this vulnerability varies based on the context in which filelock is used. In multi-user environments where multiple local users share access to specific directories, such as temporary folders or shared application data stores, an attacker can disrupt service availability by stalling processes that depend on accurate lock states. This denial of service can cause cascading failures in applications that rely on these locks for synchronization, leading to system instability or unresponsive services. Furthermore, the ability to write through a hard-linked file poses a significant integrity risk. If the locked application writes configuration data, logs, or other critical information into a location controlled by an attacker via this vulnerability, it can lead to code execution if those files are later interpreted as scripts or configurations by privileged processes. This effectively allows a lower-privileged user to influence higher-privileged operations indirectly through file manipulation.
Mitigation for this issue is straightforward and primarily involves upgrading the library. The maintainers have addressed these flaws in version 4.2.1, which implements stricter validation checks to ensure that holder records are regular files before performing refresh or write operations. Developers using affected versions should immediately update their dependencies to version 4.2.1 or later. In environments where immediate patching is not feasible, administrators can mitigate the risk by restricting file creation permissions in directories used for lock storage, ensuring that only trusted processes can create new entries within those locations. Additionally, configuring filesystems to disable hard link creation for non-root users and monitoring for unusual named pipe creations in sensitive directories can provide additional layers of defense against exploitation attempts while waiting for a full software update cycle.