Skip to content

filelock Time-of-Check-Time-of-Use (TOCTOU) Symlink Vulnerability in SoftFileLock

Moderate severity GitHub Reviewed Published Jan 9, 2026 in tox-dev/filelock • Updated Jan 13, 2026

Package

pip filelock (pip)

Affected versions

< 3.20.3

Patched versions

3.20.3

Description

Vulnerability Summary

Title: Time-of-Check-Time-of-Use (TOCTOU) Symlink Vulnerability in SoftFileLock

Affected Component: filelock package - SoftFileLock class
File: src/filelock/_soft.py lines 17-27
CWE: CWE-362, CWE-367, CWE-59


Description

A TOCTOU race condition vulnerability exists in the SoftFileLock implementation of the filelock package. An attacker with local filesystem access and permission to create symlinks can exploit a race condition between the permission validation and file creation to cause lock operations to fail or behave unexpectedly.

The vulnerability occurs in the _acquire() method between raise_on_not_writable_file() (permission check) and os.open() (file creation). 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.

Attack Scenario

1. Lock attempts to acquire on /tmp/app.lock
2. Permission validation passes
3. [RACE WINDOW] - Attacker creates: ln -s /tmp/important.txt /tmp/app.lock
4. os.open() tries to create lock file
5. Lock operates on attacker-controlled target file or fails

Impact

What kind of vulnerability is it? Who is impacted?

This is a Time-of-Check-Time-of-Use (TOCTOU) race condition vulnerability affecting any application using SoftFileLock for inter-process synchronization.

Affected Users:

  • Applications using filelock.SoftFileLock directly
  • Applications using the fallback FileLock on systems without fcntl support (e.g., GraalPy)

Consequences:

  • Silent lock acquisition failure - applications may not detect that exclusive resource access is not guaranteed
  • Denial of Service - attacker can prevent lock file creation by maintaining symlink
  • Resource serialization failures - multiple processes may acquire "locks" simultaneously
  • Unintended file operations - lock could operate on attacker-controlled files

CVSS v4.0 Score: 5.6 (Medium)
Vector: CVSS:4.0/AV:L/AT:L/PR:L/UI:N/VC:N/VI:L/VA:H/SC:N/SI:N/SA:N

Attack Requirements:

  • Local filesystem access to the directory containing lock files
  • Permission to create symlinks (standard for regular unprivileged users on Unix/Linux)
  • Ability to time the symlink creation during the narrow race window

Patches

Has the problem been patched? What versions should users upgrade to?

Yes, the vulnerability has been patched by adding the O_NOFOLLOW flag to prevent symlink following during lock file creation.

Patched Version: Next release (commit: 255ed068bc85d1ef406e50a135e1459170dd1bf0)

Mitigation Details:

  • The O_NOFOLLOW flag is added conditionally and gracefully degrades on platforms without support
  • On platforms with O_NOFOLLOW support (most modern systems): symlink attacks are completely prevented
  • On platforms without O_NOFOLLOW (e.g., GraalPy): TOCTOU window remains but is documented

Users should:

  • Upgrade to the patched version when available
  • For critical deployments, consider using UnixFileLock or WindowsFileLock instead of the fallback SoftFileLock

Workarounds

Is there a way for users to fix or remediate the vulnerability without upgrading?

For users unable to update immediately:

  1. Avoid SoftFileLock in security-sensitive contexts - use UnixFileLock or WindowsFileLock when available (these were already patched for CVE-2025-68146)

  2. Restrict filesystem permissions - prevent untrusted users from creating symlinks in lock file directories:

    chmod 700 /path/to/lock/directory
  3. Use process isolation - isolate untrusted code from lock file paths to prevent symlink creation

  4. Monitor lock operations - implement application-level checks to verify lock acquisitions are successful before proceeding with critical operations


References

Are there any links users can visit to find out more?


Reported by: George Tsigourakos (@tsigouris007)

References

@gaborbernat gaborbernat published to tox-dev/filelock Jan 9, 2026
Published by the National Vulnerability Database Jan 10, 2026
Published to the GitHub Advisory Database Jan 13, 2026
Reviewed Jan 13, 2026
Last updated Jan 13, 2026

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Local
Attack complexity
High
Privileges required
Low
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
Low
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(4th percentile)

Weaknesses

Improper Link Resolution Before File Access ('Link Following')

The product attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource. Learn more on MITRE.

Concurrent Execution using Shared Resource with Improper Synchronization ('Race Condition')

The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently. Learn more on MITRE.

Time-of-check Time-of-use (TOCTOU) Race Condition

The product checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check. Learn more on MITRE.

CVE ID

CVE-2026-22701

GHSA ID

GHSA-qmgc-5h2g-mvrw

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.