CVE-2026-112935 in filelock
Summary
by MITRE • 10/20/2026
filelock is a platform-independent file lock for Python. From 3.22.0 until 4.2.1, SoftFileLock can break a stale marker after an attacker frees its own marker following the stale read, an honest contender creates a live successor on the reused inode, and the successor's modification time is not newer than the saved observation, causing the live marker to be removed and two holders to be admitted. 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 filelock library provides platform-independent file locking mechanisms for Python applications, ensuring that only one process can access a specific resource at a time. A critical race condition vulnerability exists within the SoftFileLock implementation affecting versions from 3.22.0 through 4.2.1. This flaw stems from an improper handling of stale lock markers during the acquisition phase, specifically when dealing with inode reuse scenarios common in Unix-like operating systems where file descriptors are recycled after deletion.
The technical root cause involves a time-of-check to time-of-use (TOCTOU) race condition related to how the library validates the age of existing lock files before acquiring them. When SoftFileLock attempts to acquire a lock, it checks for the existence of a marker file and evaluates its modification timestamp against a saved observation to determine if the previous holder is still active or has become stale. An attacker can exploit this by first creating their own lock marker and then immediately removing it after observing that another process has detected a potential stale lock but before that second process successfully acquires the new lock. If an honest contender subsequently creates a live successor on the same reused inode, its modification time may not be newer than the saved observation from the initial check due to filesystem timestamp granularity or timing delays. Consequently, the library incorrectly identifies this legitimate, newly created marker as stale and removes it, thereby failing to enforce exclusive access.
This vulnerability results in a complete breakdown of mutual exclusion guarantees provided by file locking mechanisms. The immediate operational impact is that two distinct processes can simultaneously hold what should be an exclusive lock on the same resource. This leads to data corruption when both processes write to shared files concurrently, as they overwrite each other's changes without synchronization. In security-sensitive contexts, such as configuration management or credential storage, this race condition can lead to privilege escalation if one process assumes it has sole control over a sensitive file while another modifies its permissions or content. It also undermines the reliability of distributed systems that rely on file-based coordination for task scheduling and resource allocation.
The issue is classified under CWE-367: Time-of-check Time-of-use (TOCTOU) Race Condition, as the validity check performed before acquiring the lock becomes invalid by the time the action is executed due to concurrent modifications. From an adversarial perspective, this aligns with MITRE ATT&CK technique T1042: File Deletion or Overwrite, where an attacker manipulates file system state to bypass security controls. The vulnerability allows for denial of service through resource contention and potential integrity violations depending on the application's use case.
To mitigate this risk, organizations must upgrade the filelock library to version 4.2.1 or later, which corrects the logic by ensuring that lock acquisition checks are atomic with respect to inode reuse scenarios. Applications relying on strict mutual exclusion should consider implementing additional synchronization primitives at the application layer rather than depending solely on file locks for critical security boundaries. Furthermore, developers should audit codebases using this library to identify any concurrent access patterns that might have already been affected by this race condition and implement database-level or memory-based locking mechanisms where higher consistency guarantees are required.