CVE-2026-22701

What it actually does

The flaw is a local time-of-check/time-of-use race condition in the Python filelock package's SoftFileLock implementation before version 3.20.3. The vulnerable _acquire() logic checks whether the intended lock file path is writable and then later creates or opens the lock file with os.open(). During the small interval between those operations, a local attacker who can write to the same directory and create symbolic links can replace the expected lock-file path with a symlink. This can cause the lock operation to act on an unintended file or fail, undermining lock integrity and potentially causing denial of service or incorrect application behavior. The issue does not provide remote access by itself and requires local filesystem access, symlink creation permission, and a successful race condition.

Why it matters to the business

Applications that rely on filelock for local coordination may experience failed locks, corrupted workflow sequencing, job failures, stalled automation, or unexpected denial of service if an attacker or untrusted local user can manipulate lock-file locations. The practical risk is highest on shared hosts, CI/build workers, multi-user systems, containers or workloads with shared writable volumes, and services that create lock files in world-writable or user-controllable directories. The vulnerability has a moderate CVSS score, very low EPSS, is not listed in CISA KEV, and has no known public exploit maturity in the provided data, so broad internet-scale exploitation is unlikely; however, it remains relevant for environments where local users, plugins, build jobs, or sandboxed processes share filesystem access.

How an attack unfolds

An attacker first needs local access to a filesystem location where a vulnerable application creates a SoftFileLock lock file. The attacker monitors or predicts the lock-file path used by the application. When the application begins acquiring the lock, the vulnerable code verifies that the path is writable. Before the subsequent os.open() call creates or opens the file, the attacker races to create a symbolic link at that same lock-file path. If the timing succeeds, the lock operation may follow or interact with the symlink target rather than the intended lock file, or it may fail unexpectedly. Depending on how the application uses the lock, this can disrupt job execution, break concurrency protections, cause a denial of service, or induce inconsistent state. There is no indication from the supplied intelligence that named threat actors, ransomware campaigns, or widespread exploitation are using this issue.

How to fix it

Upgrade the Python filelock package to version 3.20.3 or later wherever it is used directly or transitively. For source-based deployments of tox-dev/filelock, ensure the code includes the fix at commit 41b42dd2c72aecf7da83dbda5903b8087dddc4d5 or a later trusted revision. Rebuild and redeploy affected applications, containers, virtual environments, and CI images after updating dependencies. If immediate upgrade is not possible, reduce exposure by avoiding SoftFileLock in directories writable by untrusted users, placing lock files in application-owned directories with restrictive permissions, preventing untrusted symlink creation in lock-file locations, isolating build or job workspaces per user, and using stronger locking mechanisms where feasible. Treat temporary-directory and shared-volume lock paths as higher risk until patched.

How to confirm the fix worked

Confirm installed versions with package inventory and runtime checks such as pip show filelock, pip freeze, poetry.lock, requirements files, SBOMs, container image scans, and virtual environment inspection. Validate that all resolved filelock versions are 3.20.3 or later, or that source deployments include commit 41b42dd2c72aecf7da83dbda5903b8087dddc4d5 or later. Search application code for use of filelock.SoftFileLock or filelock._soft.SoftFileLock and verify that lock-file paths are not located in untrusted shared writable directories. After remediation, run application concurrency tests and lock-acquisition tests in representative environments. For high-risk shared systems, test that an untrusted local user cannot create or replace lock files or symlinks in the directories used for application locks.

Typical attack path

1. Gain low-privileged local access to a system, container, build worker, or shared volume where a vulnerable Python application uses filelock SoftFileLock.
2. Identify or predict the path of a lock file used by the application, especially in writable temporary, cache, workspace, or shared directories.
3. Ensure the attacker account can create symbolic links in the lock-file directory.
4. Wait for or trigger the application to acquire the vulnerable soft file lock.
5. Race the interval between the package's writability check and os.open() by creating a symlink at the expected lock-file path.
6. Cause the lock acquisition to fail, operate on an unintended target, or disrupt the application's concurrency assumptions.
7. Repeat the race as needed to create persistent job failures, service degradation, or inconsistent application behavior.

How to detect it

Because this is a local race condition, successful exploitation may leave limited evidence and may look like intermittent application instability. Review application logs for repeated lock acquisition failures, unexpected permission errors, symlink-related errors, or unusual failures around temporary, cache, workspace, or lock-file directories. On Linux, examine auditd, eBPF, Sysmon for Linux, file integrity monitoring, or endpoint telemetry for rapid symlink creation, unlink, rename, and open events involving application lock-file paths by users or processes that should not manage those files. Look for symbolic links where regular lock files are expected, especially links created shortly before application errors. Correlate process execution and filesystem events to determine whether an untrusted local process created a symlink at a lock-file path while a Python process using filelock was acquiring a lock. On container and CI systems, review job logs and workspace artifacts for unexpected .lock symlinks or lock files owned by another user. There are no known public threat actor or ransomware indicators in the provided data, so detection should focus on behavioral evidence rather than fixed network indicators.

• filelock._soft.SoftFileLock
• SoftFileLock
• raise_on_not_writable_file
• OSError: [Errno 40] Too many levels of symbolic links
• Too many levels of symbolic links
• PermissionError: [Errno 13] Permission denied
• FileExistsError: [Errno 17] File exists
• TimeoutException
• Cannot acquire lock
• type=SYSCALL
• syscall=symlink
• syscall=symlinkat
• syscall=unlink
• syscall=rename
• .lock ->

What your security team should do

• Inventory Python applications, containers, build pipelines, and virtual environments for filelock versions earlier than 3.20.3.
• Prioritize remediation on shared hosts, CI/CD runners, developer workstations with shared workspaces, multi-user servers, container platforms with shared writable volumes, and applications using lock files in temporary or user-controlled directories.
• Upgrade filelock to 3.20.3 or later, or deploy source code containing commit 41b42dd2c72aecf7da83dbda5903b8087dddc4d5 or later.
• Review application use of SoftFileLock and relocate lock files to directories owned by the application service account with restrictive permissions.
• Add dependency scanning or SBOM policy checks to prevent reintroduction of filelock versions earlier than 3.20.3.
• Monitor for suspicious symlink creation and lock-file manipulation in application lock directories, especially where untrusted local workloads execute.
• If unexpected job failures or lock errors have occurred on shared systems, perform targeted forensic review for symlink race artifacts before closing the issue.