Description

filelock is a platform-independent file lock for Python. From 3.22.0 until 4.2.1, soft lock classes on Windows read an existing marker with _read_lock_file and remove a stale marker through break_lock_file using pathname operations that wait for an oplock break. Another local account with read access to an unheld marker can keep a Level 1 or batch oplock unanswered, causing SoftFileLock.acquire and related async or fallback locks to wait beyond timeout, blocking=False, and cancel_check. A stale marker under the oplock cannot be broken, but mutual exclusion remains intact and no file other than the marker is accessed. This issue is fixed in version 4.2.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "2.5",
  "pubDate": "2026-11-05T22:17:46.513Z",
  "pubdate": "2026-11-05T22:17:46.513Z",
  "executiveSummary": "A vulnerability exists in the filelock library, specifically within soft lock implementations on Windows, where pathname operations are susceptible to opportunistic lock (oplock) interference.\nThe vulnerability is classified as a local Denial of Service (DoS) condition. It allows a local, unprivileged attacker with read access to the target file system to cause legitimate application processes to hang indefinitely.\nAffected versions include filelock 3.22.0 through 4.2.1. The flaw manifests when the library attempts to clean up stale markers using break_lock_file. An attacker can place a file and hold an oplock on it, forcing the library's acquisition methods—including those utilizing blocking=False and timeout parameters—to wait beyond expected constraints.\nSuccessful exploitation requires the attacker to have local file system access to place an unheld marker file. The impact is limited to the blocking of the target application's locking mechanism, preventing synchronization, while preserving mutual exclusion integrity elsewhere. No unauthorized data access or privilege escalation occurs.",
  "technicalDetails": "The vulnerability resides in the interaction between the filelock library's soft lock mechanism and Windows kernel-level opportunistic locking (oplock) mechanisms. On Windows systems, the filelock library manages stale marker files to maintain synchronization state.\nThe root cause is the reliance on pathname operations within the break_lock_file function during the cleanup of stale markers. When filelock identifies an existing marker, it invokes _read_lock_file followed by break_lock_file. In a vulnerable environment, these operations interact with the Windows I/O subsystem in a way that is sensitive to oplocks.\nAn attacker can exploit this by creating a placeholder file and requesting a Level 1 or batch oplock on it. A Level 1 oplock notifies the holder when another process attempts to open the file for read or write access. When the filelock library attempts to perform cleanup operations on this marker, the Windows kernel triggers an oplock break notification to the attacker's process.\nThe exploitation flow proceeds as follows: 1) An attacker identifies or creates a marker file path that the target application (using filelock) is likely to utilize or attempt to clean up. 2) The attacker opens the file and requests an oplock. 3) When the target process initiates SoftFileLock.acquire or related async/fallback operations, the library calls break_lock_file. 4) The Windows kernel stalls the target's I/O operation while it waits for the attacker to respond to the oplock break notification. 5) By intentionally ignoring or delaying the response to the oplock break, the attacker forces the target's thread into a state of indefinite suspension.\nCrucially, because the target process is waiting on the kernel-level file operation, it becomes unresponsive to internal library timeouts and blocking=False constraints. This effectively renders the locking mechanism non-functional for the duration of the hold, leading to a localized Denial of Service for the application relying on the filelock synchronization logic. Despite this stall, the filelock system maintains mutual exclusion for other non-marker files, meaning the integrity of data being protected by other locks is not compromised. The issue is restricted to the specific stale marker management lifecycle and was addressed in version 4.2.1."
}