CVE-2026-22701: Python filelock Race Condition Vulnerability

CVE-2026-22701 Overview

A Time-of-Check Time-of-Use (TOCTOU) race condition vulnerability has been discovered in the SoftFileLock implementation of the Python filelock package, a widely-used platform-independent file locking library. Prior to version 3.20.3, an attacker with local filesystem access and permissions to create symlinks can exploit a race window between permission validation and file creation to cause lock operations to fail or behave unexpectedly.

The vulnerability occurs in the _acquire() method, specifically between the raise_on_not_writable_file() permission check and the subsequent os.open() file creation call. During this race window, an attacker can create a symlink at the lock file path, potentially causing the lock to operate on an unintended target file or leading to denial of service conditions.

Critical Impact

Local attackers can exploit the symlink race condition to redirect lock file operations to unintended targets, potentially causing application failures, data corruption, or denial of service in systems relying on filelock for synchronization.

Affected Products

• filelock Python package versions prior to 3.20.3
• Applications using SoftFileLock class for file locking
• Systems running on platforms without O_NOFOLLOW support (such as GraalPy)

Discovery Timeline

• 2026-01-10 - CVE-2026-22701 published to NVD
• 2026-01-13 - Last updated in NVD database

Technical Details for CVE-2026-22701

Vulnerability Analysis

This vulnerability is classified under CWE-59 (Improper Link Resolution Before File Access), commonly known as a symlink attack. The root issue is a classic TOCTOU race condition where the time gap between validating that a file path is safe and actually using that path creates an exploitable window.

The SoftFileLock implementation performs a permission check using raise_on_not_writable_file() before attempting to create the lock file with os.open(). However, between these two operations, the filesystem state can change. An attacker with local access can monitor for lock file creation attempts and rapidly create a symlink at the target path during the race window.

If successful, the symlink could point to a sensitive file, causing the lock operation to create or modify an unintended target. On platforms where O_NOFOLLOW is not available, this attack has a higher likelihood of success since the os.open() call will follow the symlink.

Root Cause

The vulnerability stems from two factors:

1. Temporal Gap: The separation between the permission validation (raise_on_not_writable_file()) and the actual file operation (os.open()) creates a window where the filesystem state can be manipulated.

2. Missing Symlink Protection: Prior to the patch, the os.open() call did not include the O_NOFOLLOW flag, allowing the operation to follow symlinks if present at the target path.

The SoftFileLock class is designed as a portable fallback when OS-level locking mechanisms are unavailable, but this portability came at the cost of reduced security guarantees.

Attack Vector

The attack requires local filesystem access with the following prerequisites:

• Permission to create symlinks in the directory where lock files are created
• Ability to monitor or predict when lock file creation will occur
• Timing precision to win the race between permission check and file creation

The attack flow involves:

1. Monitoring for applications attempting to acquire locks
2. Detecting the target lock file path
3. Creating a symlink at that path pointing to an attacker-chosen target
4. The victim application then operates on the symlink target instead of the intended lock file

The patched code adds the O_NOFOLLOW flag to prevent following symlinks:

    def _acquire(self) -> None:
        raise_on_not_writable_file(self.lock_file)
        ensure_directory_exists(self.lock_file)
        flags = (
            os.O_WRONLY  # open for writing only
            | os.O_CREAT
            | os.O_EXCL  # together with above raise EEXIST if the file specified by filename exists
            | os.O_TRUNC  # truncate the file to zero byte
        )
        o_nofollow = getattr(os, "O_NOFOLLOW", None)
        if o_nofollow is not None:
            flags |= o_nofollow
        try:
            file_handler = os.open(self.lock_file, flags, self._context.mode)
        except OSError as exception:  # re-raise unless expected exception

Source: GitHub Commit

Detection Methods for CVE-2026-22701

Indicators of Compromise

• Unexpected symlinks appearing in directories where lock files are typically created
• Lock file operations failing with unexpected OSError exceptions
• Application logs showing file locking errors pointing to unusual file paths
• Monitoring tools detecting rapid symlink creation/deletion in lock file directories

Detection Strategies

• Audit installed Python packages for filelock versions below 3.20.3 using dependency scanning tools
• Monitor filesystem events for symlink creation in directories used for lock files
• Implement file integrity monitoring on directories containing lock files
• Review application logs for unusual file locking behavior or path traversal patterns

Monitoring Recommendations

• Enable filesystem auditing on directories where applications create lock files
• Configure alerts for symlink creation events in sensitive directories
• Implement process monitoring to detect suspicious local privilege escalation attempts
• Use SentinelOne's Singularity platform to monitor for anomalous file system operations and potential TOCTOU exploitation patterns

How to Mitigate CVE-2026-22701

Immediate Actions Required

• Upgrade the filelock package to version 3.20.3 or later immediately
• Audit applications to identify usage of SoftFileLock class
• For security-sensitive applications, migrate to UnixFileLock or WindowsFileLock which provide stronger OS-level guarantees
• Review filesystem permissions to restrict symlink creation in lock file directories

Patch Information

The vulnerability has been patched in filelock version 3.20.3. The fix adds the O_NOFOLLOW flag to the os.open() call when available on the platform, preventing the operation from following symlinks.

Security patches are available at:

• GitHub Commit 255ed06
• GitHub Commit 41b42dd
• GitHub Security Advisory GHSA-qmgc-5h2g-mvrw

Workarounds

• Switch from SoftFileLock to UnixFileLock or WindowsFileLock for applications requiring stronger security guarantees
• Restrict filesystem permissions on lock file directories to prevent unauthorized symlink creation
• Implement additional validation in applications to verify lock file integrity before and after lock operations
• On platforms without O_NOFOLLOW support (such as GraalPy), consider using alternative locking mechanisms

# Upgrade filelock to patched version
pip install --upgrade filelock>=3.20.3

# Verify installed version
pip show filelock | grep Version

# For poetry users
poetry add filelock@^3.20.3

# For pipenv users
pipenv install filelock>=3.20.3