Description

filelock is a platform-independent file lock for Python. From 3.30.0 until 4.2.1, On POSIX platforms, StrictSoftFileLock and AsyncStrictSoftFileLock validate the coordination directory in _ensure_protocol_directory but later reach the claims directory through _open_directory by pathname, allowing a local account that can rename the coordination name to swap in a symbolic link between check and use during acquisition. That race can create and leave claim files in another writable directory or strand claims in a different strict lock so the second lock times out. Separately, the claims property and force_break follow a resting symbolic link without a race when the lock user inspects or recovers the lock. Claims inspection discloses a file name to the other account only if the resulting exception text or claim_name reaches that account through a shared log, CI output, or error report. A blind force_break recovery that removes live claims from another strict lock can allow two processes into that lock's critical section; this path reaches other strict locks, not arbitrary files. This issue is fixed in version 4.2.1.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.8",
  "pubDate": "2026-11-05T22:17:47.213Z",
  "pubdate": "2026-11-05T22:17:47.213Z",
  "executiveSummary": "The Python library filelock contains a Time-of-Check to Time-of-Use (TOCTOU) vulnerability affecting StrictSoftFileLock and AsyncStrictSoftFileLock on POSIX platforms. Versions 3.30.0 through 4.2.1 are impacted.\nThe vulnerability arises due to insecure path handling during the acquisition of the coordination directory. A local attacker with sufficient permissions to rename the coordination directory can perform a symlink swap between the directory validation check and the subsequent file operation.\nThis race condition allows for the creation of claim files in unauthorized, writable directories or the stranding of claims, causing denial-of-service in concurrent lock processes. Furthermore, insecure handling of symlinks in the claims property and force_break method allows for unauthorized inspection and modification of lock states.\nSuccessful exploitation requires local access to the system. The primary risk involves unintended file creation in arbitrary locations, potential denial of service by stranding locks, and the bypass of critical section protections by forcing the removal of legitimate claim files from other lock processes.\nThis vulnerability does not allow for arbitrary file deletion but can be used to disrupt lock integrity, potentially leading to race conditions in protected critical sections.",
  "technicalDetails": "The vulnerability stems from the implementation of _ensure_protocol_directory and _open_directory in filelock versions 3.30.0 to 4.2.1. While _ensure_protocol_directory performs a validation check on the coordination directory, the subsequent invocation of _open_directory resolves the path via filesystem lookup rather than using a file descriptor or a secure directory handle.\nThe attack flow leverages a race condition during the acquisition phase. A local attacker capable of renaming the coordination directory can introduce a symbolic link after the check is performed but before the file operation is committed. By swapping the directory path with a symlink, the process is coerced into performing operations in an attacker-controlled location, specifically writing claim files to external, writable directories.\nBeyond the acquisition race, the vulnerability extends to the claims property and the force_break method. These components insecurely follow symbolic links when inspecting or recovering lock states. If a lock user triggers an inspection, the underlying implementation follows existing symbolic links, potentially leaking file names if exception messages containing the path are exposed through logging systems, CI pipelines, or standard error outputs.\nFurthermore, the force_break implementation is vulnerable to a blind recovery attack. Because the method blindly removes claim files, an attacker can manipulate the state of a victim process, causing it to prematurely terminate its claim. This effectively removes the safety mechanisms protecting a critical section, potentially allowing two concurrent processes to enter the same critical section simultaneously. This manipulation is constrained to other strict locks, preventing arbitrary file deletion but facilitating logical race conditions within the application.\nAffected components include StrictSoftFileLock and AsyncStrictSoftFileLock, specifically under POSIX operating systems where symlink behavior is predictable by local users. The exploitation does not require administrative privileges, merely the ability to manipulate the filesystem path associated with the coordination directory."
}