CVE-2026-112937: Arbitrary Directory Deletion via TOCTOU Race Condition in filelock ReadWriteLock

The filelock package is a platform-independent Python implementation used to manage inter-process file locks. Starting with version 4.1.0, the package introduced SQLite-backed reader/writer lock primitives, implemented in ReadWriteLock and AsyncReadWriteLock. These classes allow multiple concurrent readers or an exclusive writer to synchronize operations across independent operating system processes.

When operating in fallback environments where direct file descriptor interaction via /proc/self/fd is unavailable or when utilizing shared directories, ReadWriteLock creates temporary private directories formatted as .filelock-* in the database parent directory. These directories hold hard-linked entries (lock.db) corresponding to active process lock instances.

Prior to version 4.2.1, releasing a lock or cleaning up stale lock entries during dead-owner sweeps triggered recursive path-based deletion via shutil.rmtree(). In non-sticky, world-writable directories, a local attacker can exploit this design by swapping the expected directory path with a target victim directory prior to deletion.

The technical root cause of CVE-2026-112937 lies in relying on path string resolution during recursive directory cleanup instead of using file descriptor pinning. In src/filelock/_read_write.py, the lock mechanism invoked shutil.rmtree(directory) with a string path representing .filelock-<pid>-<hash>.

Because string-based path traversal performs resolution dynamically at execution time, a window of exposure exists between when the lock directory is identified and when shutil.rmtree() performs recursive directory unlinking. An attacker with write and rename permissions in the shared parent directory can move the legitimate .filelock-* directory and replace it with a directory owned by the victim process.

When the victim process finishes lock release or executes the _sweep_links_of_the_dead routine, it passes the string path to shutil.rmtree(). Python traverses the substituted directory path using the process's effective permissions, systematically unlinking all child items and removing the directory hierarchy.

In vulnerable versions, link directories were unlinked directly via shutil.rmtree without verifying directory inode stability or permissions:

# Vulnerable implementation in filelock/_read_write.py
def _purge_link_directory(self, directory: str) -> None:
    # Vulnerable path string resolution
    if os.path.exists(directory):
        shutil.rmtree(directory)

The fix implemented in commit 5e3f2ec0c5fb17cb2635b60b2b68bc63ab81ca2d replaces path-based deletion with file descriptor-pinned operations through _remove_link_directory(link). The patched implementation opens the target directory directly and verifies its device and inode identifier:

# Patched implementation in filelock/_read_write.py
def _remove_link_directory(link: Link) -> None:
    # Open directory file descriptor securely
    fd = os.open(link.path, _DIRECTORY_FLAGS)
    try:
        opened = os.fstat(fd)
        # Verify device and inode match expected identity
        if (opened.st_dev, opened.st_ino) != link.identity:
            raise SecurityError("Directory identity mismatch detected")
        # Perform directory-relative unlinks using dir_fd
        _unlink_contents_at(fd)
    finally:
        os.close(fd)

Additionally, filelock introduced _names_are_private and _directory_is_private helpers to ensure parent directories restrict write access strictly to the owner before link operations proceed. Sweeping functions now enforce user identity checks via os.fstat(fd).st_uid == owner.

To exploit this vulnerability, an attacker requires local unprivileged shell access and write access to the parent directory where the filelock database resides. Shared temporary locations without sticky bits (such as unprotected custom subdirectories under /tmp) represent primary attack vectors.

The attack flow operates in four distinct stages:

1. The attacker monitors the target shared parent directory for new .filelock-* entries created by the victim process.
2. The attacker uses standard filesystem utilities (such as rename) to move .filelock-<pid>-<hash> to a temporary name.
3. The attacker creates a new directory or symbolic link named .filelock-<pid>-<hash> pointing to a victim-owned target directory (e.g., /home/victim/project).
4. Upon lock release or dead owner cleanup, the victim process calls shutil.rmtree(), traversing the attacker-placed reference and deleting the target directory tree.

The impact of CVE-2026-112937 is restricted to localized integrity loss and application denial of service. The vulnerability does not provide arbitrary code execution or direct read access to confidential file contents.

Because the deletion occurs under the user privileges running the filelock library, an attacker can induce destruction of any file or directory writable by that user account. If the victim process runs as a privileged account (such as root or Administrator), an unprivileged attacker can delete critical system configurations or database directories.

This vulnerability has been assigned a CVSS v3.1 score of 6.1 (CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L). EPSS scoring is rated at 0.00096, reflecting no observed exploitation in wild ransomware or automated attack frameworks.

Organizations and developers should update the filelock dependency to version 4.2.1 or higher immediately.

For Python environments managed via pip:

pip install --upgrade "filelock>=4.2.1"

For projects using pyproject.toml dependencies:

[dependencies]
filelock = ">=4.2.1"

If immediate dependency updates cannot be deployed, teams must apply filesystem configuration workarounds. Ensure all lock databases and link directories reside inside restricted directories owned by the process user with strict permissions (0o700). Avoid placing lock instances in shared world-writable paths like /tmp unless sticky bits (S_ISVTX) are strictly enforced.