CVE-2026-112906 in filelock
Summary
by MITRE • 10/20/2026
filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, SoftFileLock versions from 4.1.0 can reuse a stale observation when an attacker pre-dates and removes its own marker, at least two lock-user processes are waiting, coarse or matching modification times preserve the observation, and an honest contender creates a fresh marker on the reused inode, causing that live marker to be removed as stale. This issue is fixed in version 4.2.1.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
The filelock library provides platform-independent file locking mechanisms for Python applications, ensuring mutual exclusion when multiple processes attempt to access shared resources. A critical vulnerability exists within the SoftFileLock implementation across versions from 4.1.0 through 4.2.1, where the logic governing lock acquisition and stale marker detection contains a race condition that can be exploited by an attacker with local file system access. This flaw undermines the fundamental guarantee of mutual exclusion, potentially allowing unauthorized concurrent access to protected files or resources which should remain locked during critical operations.
The technical root cause lies in how SoftFileLock identifies and removes stale lock markers based on inode modification times. When a process holds a lock, it creates a marker file associated with a specific inode. If another process attempts to acquire the same lock while one is held, it waits for the existing lock to be released. The vulnerability arises when an attacker pre-dates their own marker file and subsequently removes it before initiating the lock acquisition attempt. Because coarse or matching modification times are preserved during this manipulation, the system may incorrectly interpret a fresh marker created by an honest contender as stale if that contender's inode matches the one previously observed by the waiting processes. Consequently, the legitimate process’s active lock marker is erroneously removed from the file system, effectively breaking the lock without proper release semantics.
This behavior leads to a significant operational impact where multiple users or processes can simultaneously believe they hold an exclusive lock on the same resource. In practical terms, this allows for race conditions that result in data corruption, inconsistent state updates, or denial of service if critical sections are bypassed. An attacker leveraging this flaw could manipulate application logic by forcing concurrent writes to a database file, configuration store, or log file, leading to unpredictable behavior and potential security breaches depending on the sensitivity of the protected resource. The issue is particularly dangerous in multi-user environments where trust boundaries between processes may be assumed but not enforced due to this locking failure.
The vulnerability aligns with CWE-362, Concurrent Execution using Shared Resource with Improper Synchronization of 'Race Conditions', as it involves a timing-dependent error that allows an attacker to interfere with the execution flow by manipulating shared state. It also relates to CWE-841, Improper Enforcement of Behavioral Workflow, because the locking mechanism fails to enforce the intended sequence of lock acquisition and release. From a threat modeling perspective using MITRE ATT&CK techniques, this flaw can be associated with T1562, Impair Defenses, as it undermines security monitoring or control mechanisms that rely on file locks for integrity assurance.
To mitigate this vulnerability, organizations must upgrade the filelock library to version 4.2.1 or later, where the logic has been corrected to prevent the reuse of stale observations and ensure accurate detection of active versus expired lock markers. In environments where immediate patching is not feasible, implementing additional application-level checks such as verifying process IDs associated with lock files can provide a secondary layer of defense. Furthermore, adopting more robust locking mechanisms that utilize atomic operations or operating system-specific file locking APIs rather than relying solely on marker files and modification times can reduce the attack surface for similar race conditions in future development cycles.