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
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.
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
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:
filelock.SoftFileLock directlyFileLock on systems without fcntl support (e.g., GraalPy)Consequences:
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:
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:
O_NOFOLLOW flag is added conditionally and gracefully degrades on platforms without supportO_NOFOLLOW support (most modern systems): symlink attacks are completely preventedO_NOFOLLOW (e.g., GraalPy): TOCTOU window remains but is documentedUsers should:
UnixFileLock or WindowsFileLock instead of the fallback SoftFileLockIs there a way for users to fix or remediate the vulnerability without upgrading?
For users unable to update immediately:
Avoid SoftFileLock in security-sensitive contexts - use UnixFileLock or WindowsFileLock when available (these were already patched for CVE-2025-68146)
Restrict filesystem permissions - prevent untrusted users from creating symlinks in lock file directories:
chmod 700 /path/to/lock/directory
Use process isolation - isolate untrusted code from lock file paths to prevent symlink creation
Monitor lock operations - implement application-level checks to verify lock acquisitions are successful before proceeding with critical operations
Are there any links users can visit to find out more?
Reported by: George Tsigourakos (@tsigouris007)