You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Update dependency filelock to v4 [SECURITY] - #10955
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.
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.
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 python3importosimportsecretsimportshutilimportstatimportsubprocessimportsys##### set up: a directory every user may write, without the sticky bitshared="/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,
)
defvictim_runs(job):
victim.stdin.write(job+"\n")
victim.stdin.flush()
assertvictim.stdout.readline() =="done\n"defas_attacker(script, argument):
command= ["runuser", "-u", "attacker", "--", sys.executable, f"/tmp/repro.d/{script}", argument]
returnsubprocess.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 itvictim_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}")
##### attackas_attacker("attacker_rename_journal.py", shared)
##### the victim takes its lock again, then notes a secret in its journal through the descriptor it holdssecret=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 attackerlock_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"injournal_content_beforeand"job 1"notinlock_content_afterjournal_was_widened=stat.S_IMODE(journal_before.st_mode) ==0o600andstat.S_IMODE(lock_after.st_mode) ==0o666attacker_reads_the_secret=secretinattacker_read_afterbug= (
attacker_was_deniedandlock_path_is_the_journalandjournal_was_emptiedandjournal_was_widenedandattacker_reads_the_secret
)
print("BUG"ifbugelse"OK")
importosimportsysshared_directory=sys.argv[1]
##### needs only write access to the directory: no sticky bit, so any user may rename any entry in itos.rename(f"{shared_directory}/victim-journal.log", f"{shared_directory}/jobs.lock")
repro.d/victim_job_runner.py
importosimportsysfromfilelockimportFileLockshared_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=0o666lock=FileLock(f"{shared_directory}/jobs.lock", mode=0o666, timeout=5)
forjobinsys.stdin:
withlock:
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) -> EEXIST
V->>K: open(jobs.lock, O_RDWR|O_NOFOLLOW) -> fd (regular file, created=False)
V->>K: flock(fd, LOCK_EX|LOCK_NB) -> ok (no holder)
rect rgb(255, 214, 214)
V->>K: fstat(fd), st_nlink != 0
V->>K: ftruncate(fd, 0)
V->>K: fchmod(fd, 0o666)
Note over V,K: the journal's inode is now empty and world read-write, still owned by victim
end
V->>K: write("ran job 2 <secret>") through the journal descriptor it still holds
A->>D: read jobs.lock -> "ran job 2 <secret>"
Loading
Evidence
The scanner reproducer (victim and attacker accounts, root-created 0777 directory without the sticky bit under /tmp, default sysctls, Linux 6.1, CPython 3.14.8, overlayfs; lock FileLock(path, mode=0o666, timeout=5)). It printed CONTROL journal: inode 296383, uid 1000, mode 600, content 'ran job 1\n' and CONTROL attacker reads the journal: 'permission denied\n'. After the rename and the second job of victim it printed OBSERVED lock path: inode 296383, uid 1000, mode 666, content 'ran job 2 f4bc9a4e04c3f556\n' and OBSERVED attacker reads the lock path: 'ran job 2 f4bc9a4e04c3f556\n', last line BUG. The verdict requires that the earlier read by attacker failed, that the lock path is the journal's inode, that the old line is gone, that the mode went from 0600 to 0666, and that the later read by attacker contains the secret. It runs in under a second with no race. The scanner ran the two-name and link(2) variants above by hand at the same commit (commands and results in its report), not through the script.
Maintainer triage: the reproducer prints BUG on the scanned commit b831496 and on the 4.2.0 release image. The independent review (soft-open) confirmed the mechanism and that the hard-link and two-name variants go through the same two calls.
Impact
The file's content is lost in every configuration, including for processes that hold the file open and under every other name the file has. With an explicit permissive mode, the other user can read and modify everything the lock user writes afterwards, while the file still belongs to the lock user. The other user can rename the file back to its old name after the acquire. It stays there with the lock's mode, and the lock user's next acquire creates a fresh lock file.
Somebody who may rename a single-name file may also unlink it, so losing such a file under its name is not new. What the lock adds are two operations on the inode that the other user cannot perform, ftruncate and fchmod, run with the lock user's privileges. Those matter for a descriptor the lock user still holds, for a second name of the file, and for programs that trust the file's ownership. The other user does not choose the mode, and the lock user writes no bytes the other user chose. Mutual exclusion is not affected.
Workarounds
Keep the lock file in a directory no other account can write, or in a sticky directory on a filesystem where no directory holding the lock user's files is writable by others. On Linux keep fs.protected_hardlinks=1 (the default on mainstream distributions), which closes the hard-link route.
Do not pass a permissive explicit mode (0o666, 0o660, 0o644) unless accounts share the lock; without a mode the exposure is the truncation only.
Keep the lock file in place (preserve_lock_file=True). Once a lock file owned by the lock user exists in a sticky directory, another user cannot rename or link over it.
Where the lock does not need flock semantics, SoftFileLock applies its mode only to the marker it created with O_EXCL and does not truncate an existing file.
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 high by the scanner)
2026-10-16 00:46 UTC: draft advisory created (first as a group of four findings, then narrowed to ANT-2026-KO573NWI; the other three security findings have their own advisories)
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:
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 python3importosimportshutilimportsubprocessimportsysimporttempfileprivate_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 makesos.umask(0o022)
locks=tempfile.mkdtemp()
##### control: UnixFileLock, which leaves the lock file behindsubprocess.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&0o777unix_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 wholewindows_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 NtCreateFileprint(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}")
forcallinwindows_private_calls:
print(f"OBSERVED WindowsFileLock FileLock(path, mode=0o600): {call}")
forcallinwindows_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==0o600andunix_default_mode==0o644private_create=next(callforcallinwindows_private_callsifcall.startswith("NtCreateFile("))
dropped_on_windows= (
"ObjectAttributes.SecurityDescriptor=None"inprivate_createandwindows_private_calls==windows_default_calls
)
print("BUG"ifhonoured_on_unixanddropped_on_windowselse"OK")
importctypesimportfcntlimportosimportrunpyimportsysimporttypes##### 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.defRtlDosPathNameToNtPathName_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)
return0# STATUS_SUCCESSdefNtCreateFile(
handle, access, attributes, _io_status, allocation_size, file_attributes, share, disposition, options, ea, ea_length
):
object_attributes=attributes._objprint(
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.Bufferhandle._obj.value=os.open(path, os.O_RDWR|os.O_CREAT|os.O_NOFOLLOW)
return0# STATUS_SUCCESSdefRtlFreeUnicodeString(_nt_name):
print("RtlFreeUnicodeString()")
defGetFileInformationByHandle(_handle, info):
print("GetFileInformationByHandle()")
info._obj.dwFileAttributes=0x80# FILE_ATTRIBUTE_NORMAL: not a reparse pointreturnTruedefLockFileEx(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)
returnTruedefUnlockFileEx(handle, _reserved, bytes_low, bytes_high, _overlapped):
print(f"UnlockFileEx(nNumberOfBytesToUnlockLow={bytes_low}, nNumberOfBytesToUnlockHigh={bytes_high})")
fcntl.flock(handle, fcntl.LOCK_UN)
returnTrue##### only a filelock that builds a security descriptor for the lock file calls thisdefConvertStringSecurityDescriptorToSecurityDescriptorW(sddl, _revision, descriptor, _size):
print(f"ConvertStringSecurityDescriptorToSecurityDescriptorW({sddl!r})")
descriptor._obj.value=1# any address but NULLreturnTrue##### filelock sets argtypes on these at import; a lock taken without contention never calls themdefnot_called(*_arguments):
raiseNotImplementedErrordlls= {
"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.importfilelock# noqa: E402fornamein [namefornameinsys.modulesifname.split(".")[0] =="filelock"]:
delsys.modules[name]
ctypes.WinDLL=lambdaname, use_last_error=False: dlls[name]
sys.modules["msvcrt"] =types.SimpleNamespace(open_osfhandle=lambdahandle, _flags: handle, get_osfhandle=lambdafd: fd)
os.O_NOINHERIT=0sys.platform="win32"importfilelock# noqa: E402, F811assertfilelock.FileLockisfilelock.WindowsFileLocksys.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
Loading
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.
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
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.
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.
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 python3importosimportsecretsimportshutilimportstatimportsubprocessimportsys##### set up: a directory every user may write, without the sticky bitshared="/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,
)
defvictim_runs(job):
victim.stdin.write(job+"\n")
victim.stdin.flush()
assertvictim.stdout.readline() =="done\n"defas_attacker(script, argument):
command= ["runuser", "-u", "attacker", "--", sys.executable, f"/tmp/repro.d/{script}", argument]
returnsubprocess.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 itvictim_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}")
##### attackas_attacker("attacker_rename_journal.py", shared)
##### the victim takes its lock again, then notes a secret in its journal through the descriptor it holdssecret=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 attackerlock_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"injournal_content_beforeand"job 1"notinlock_content_afterjournal_was_widened=stat.S_IMODE(journal_before.st_mode) ==0o600andstat.S_IMODE(lock_after.st_mode) ==0o666attacker_reads_the_secret=secretinattacker_read_afterbug= (
attacker_was_deniedandlock_path_is_the_journalandjournal_was_emptiedandjournal_was_widenedandattacker_reads_the_secret
)
print("BUG"ifbugelse"OK")
importosimportsysshared_directory=sys.argv[1]
##### needs only write access to the directory: no sticky bit, so any user may rename any entry in itos.rename(f"{shared_directory}/victim-journal.log", f"{shared_directory}/jobs.lock")
repro.d/victim_job_runner.py
importosimportsysfromfilelockimportFileLockshared_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=0o666lock=FileLock(f"{shared_directory}/jobs.lock", mode=0o666, timeout=5)
forjobinsys.stdin:
withlock:
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) -> EEXIST
V->>K: open(jobs.lock, O_RDWR|O_NOFOLLOW) -> fd (regular file, created=False)
V->>K: flock(fd, LOCK_EX|LOCK_NB) -> ok (no holder)
rect rgb(255, 214, 214)
V->>K: fstat(fd), st_nlink != 0
V->>K: ftruncate(fd, 0)
V->>K: fchmod(fd, 0o666)
Note over V,K: the journal's inode is now empty and world read-write, still owned by victim
end
V->>K: write("ran job 2 <secret>") through the journal descriptor it still holds
A->>D: read jobs.lock -> "ran job 2 <secret>"
Loading
Evidence
The scanner reproducer (victim and attacker accounts, root-created 0777 directory without the sticky bit under /tmp, default sysctls, Linux 6.1, CPython 3.14.8, overlayfs; lock FileLock(path, mode=0o666, timeout=5)). It printed CONTROL journal: inode 296383, uid 1000, mode 600, content 'ran job 1\n' and CONTROL attacker reads the journal: 'permission denied\n'. After the rename and the second job of victim it printed OBSERVED lock path: inode 296383, uid 1000, mode 666, content 'ran job 2 f4bc9a4e04c3f556\n' and OBSERVED attacker reads the lock path: 'ran job 2 f4bc9a4e04c3f556\n', last line BUG. The verdict requires that the earlier read by attacker failed, that the lock path is the journal's inode, that the old line is gone, that the mode went from 0600 to 0666, and that the later read by attacker contains the secret. It runs in under a second with no race. The scanner ran the two-name and link(2) variants above by hand at the same commit (commands and results in its report), not through the script.
Maintainer triage: the reproducer prints BUG on the scanned commit b831496 and on the 4.2.0 release image. The independent review (soft-open) confirmed the mechanism and that the hard-link and two-name variants go through the same two calls.
Impact
The file's content is lost in every configuration, including for processes that hold the file open and under every other name the file has. With an explicit permissive mode, the other user can read and modify everything the lock user writes afterwards, while the file still belongs to the lock user. The other user can rename the file back to its old name after the acquire. It stays there with the lock's mode, and the lock user's next acquire creates a fresh lock file.
Somebody who may rename a single-name file may also unlink it, so losing such a file under its name is not new. What the lock adds are two operations on the inode that the other user cannot perform, ftruncate and fchmod, run with the lock user's privileges. Those matter for a descriptor the lock user still holds, for a second name of the file, and for programs that trust the file's ownership. The other user does not choose the mode, and the lock user writes no bytes the other user chose. Mutual exclusion is not affected.
Workarounds
Keep the lock file in a directory no other account can write, or in a sticky directory on a filesystem where no directory holding the lock user's files is writable by others. On Linux keep fs.protected_hardlinks=1 (the default on mainstream distributions), which closes the hard-link route.
Do not pass a permissive explicit mode (0o666, 0o660, 0o644) unless accounts share the lock; without a mode the exposure is the truncation only.
Keep the lock file in place (preserve_lock_file=True). Once a lock file owned by the lock user exists in a sticky directory, another user cannot rename or link over it.
Where the lock does not need flock semantics, SoftFileLock applies its mode only to the marker it created with O_EXCL and does not truncate an existing file.
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 high by the scanner)
2026-10-16 00:46 UTC: draft advisory created (first as a group of four findings, then narrowed to ANT-2026-KO573NWI; the other three security findings have their own advisories)
This benchmark measured no execution time, so its result is not comparable and counts as unchanged. This usually happens when the compiler removes the code under test.
System calls cannot be simulated consistently and are left out of the measure. The reported value understates the real cost. Switch to the Walltime instrument to measure them.
30 benchmarks were run, but are now archived. If they were deleted in another branch, consider rebasing to remove them from the report. Instead if they were added back, click here to restore them. ↩
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Note
This PR body was truncated due to platform limits.
This PR contains the following updates:
3.20.3→4.2.1Warning
Some dependencies could not be looked up. Check the Dependency Dashboard for more information.
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 ofFileLockandAsyncFileLockon Unix, empties whatever regular file it finds at the lock path once it holds theflock(a kernel lock on an open file). With an explicitmodeit 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 nextacquire(). A hard link is a second name for the same file. With a mode such as0o666the 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/tmpneedsfs.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:Nscores 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 explicitmodethe 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
FileLockandAsyncFileLockon Unix (UnixFileLock).SoftFileLockapplies an explicit mode only to a file it created withO_CREAT | O_EXCLand does not truncate an existing file.WindowsFileLockhas not truncated at any version./tmpcleaner, or after a release with the defaultpreserve_lock_file=False, which unlinks the file. The scanner checked three ways at the scanned commit, with default kernel settings unless stated:0777directory);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 withEPERM;link(2)into a sticky directory. This needs a system that lets a user hard-link a file it cannot write, which on Linux meansfs.protected_hardlinks=0. Mainstream distributions set 1, which refuses the link. The scanner did not test macOS or the BSDs.FileLock(path)the lock truncates the file, which keeps its mode. With an explicitmode(a lock shared between users needs0o666or0o660, becauseUnixFileLockopens the file read-write), the lock also chmods the file to that mode._apply_explicit_modesuppressesPermissionErroronly for files the lock user does not own. The lock user owns its own files, so thefchmodsucceeds.O_NOFOLLOWmakes the open fail withELOOP; mutual exclusion between cooperating processes.Affected code
Scanned commit
b831496b0273:UnixFileLock._finalize_locked_fd, whoseos.ftruncateand_apply_explicit_modecalls have only thest_nlink != 0guard (the file still has at least one name);_apply_explicit_mode;_open_lock_file, which learns from itsO_EXCLcreate whether this attempt made the file but hands that flag only to theENOSYSfallback.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 withgit tag --contains). Before it the code passed the mode only toopen(), 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.0understated it, as the review noted.Mechanism
_open_lock_filefirst triesos.open(path, O_RDWR | O_NOFOLLOW | O_CREAT | O_EXCL, mode). With the lock user's file renamed to the lock path that fails withFileExistsError. The secondos.open(path, O_RDWR | O_NOFOLLOW)succeeds, because the entry is a regular file the lock user owns, and returnscreated = False._acquire_nativepassescreatedonly to theENOSYSbranch. No process holds aflockon 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), thenos.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_NOFOLLOWdoes 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.AsyncUnixFileLockinherits_finalize_locked_fdunchanged.The scanner measured three variants at the same commit, same accounts (
victimuid 1000,attackeruid 1001). First, a rename within a0777directory: the nextFileLock("jobs.lock", mode=0o666)ofvictimempties the0600journal ofvictimrenamed tojobs.lockand sets it to0666;attackerthen reads whatvictimkeeps writing through its open descriptor. Second, a rename of a two-name file (ln /tmp/cache/blob ~/env/blob,0644) from a0777directory,fs.protected_hardlinks=1: aftermv /tmp/cache/blob /tmp/cache/app.lockandFileLock("/tmp/cache/app.lock", mode=0o666)asvictim,~/env/blobhas2 links, mode 666, 0 bytesandecho pwned >> /home/victim/env/blobasattackersucceeds, in a directoryattackercannot write. Third,os.link(notes, lock_path)in a1777directory withfs.protected_hardlinks=0:notes.txt(0644, in the home ofvictim) ends up 0 bytes with mode0666, andopen(notes, "w")asattackerthen succeeds. With plainFileLock(lock_path)a0600file 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 commitb831496b0273.reprorepro.d/attacker_read_file.pyrepro.d/attacker_rename_journal.pyrepro.d/victim_job_runner.pyAttack 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) -> EEXIST V->>K: open(jobs.lock, O_RDWR|O_NOFOLLOW) -> fd (regular file, created=False) V->>K: flock(fd, LOCK_EX|LOCK_NB) -> ok (no holder) rect rgb(255, 214, 214) V->>K: fstat(fd), st_nlink != 0 V->>K: ftruncate(fd, 0) V->>K: fchmod(fd, 0o666) Note over V,K: the journal's inode is now empty and world read-write, still owned by victim end V->>K: write("ran job 2 <secret>") through the journal descriptor it still holds A->>D: read jobs.lock -> "ran job 2 <secret>"Evidence
The scanner reproducer (
victimandattackeraccounts, root-created0777directory without the sticky bit under/tmp, default sysctls, Linux 6.1, CPython 3.14.8, overlayfs; lockFileLock(path, mode=0o666, timeout=5)). It printedCONTROL journal: inode 296383, uid 1000, mode 600, content 'ran job 1\n'andCONTROL attacker reads the journal: 'permission denied\n'. After the rename and the second job ofvictimit printedOBSERVED lock path: inode 296383, uid 1000, mode 666, content 'ran job 2 f4bc9a4e04c3f556\n'andOBSERVED attacker reads the lock path: 'ran job 2 f4bc9a4e04c3f556\n', last lineBUG. The verdict requires that the earlier read byattackerfailed, that the lock path is the journal's inode, that the old line is gone, that the mode went from0600to0666, and that the later read byattackercontains the secret. It runs in under a second with no race. The scanner ran the two-name andlink(2)variants above by hand at the same commit (commands and results in its report), not through the script.Maintainer triage: the reproducer prints
BUGon the scanned commitb831496and on the 4.2.0 release image. The independent review (soft-open) confirmed the mechanism and that the hard-link and two-name variants go through the same two calls.Impact
The file's content is lost in every configuration, including for processes that hold the file open and under every other name the file has. With an explicit permissive
mode, the other user can read and modify everything the lock user writes afterwards, while the file still belongs to the lock user. The other user can rename the file back to its old name after the acquire. It stays there with the lock's mode, and the lock user's next acquire creates a fresh lock file.Somebody who may rename a single-name file may also unlink it, so losing such a file under its name is not new. What the lock adds are two operations on the inode that the other user cannot perform,
ftruncateandfchmod, run with the lock user's privileges. Those matter for a descriptor the lock user still holds, for a second name of the file, and for programs that trust the file's ownership. The other user does not choose the mode, and the lock user writes no bytes the other user chose. Mutual exclusion is not affected.Workarounds
fs.protected_hardlinks=1(the default on mainstream distributions), which closes the hard-link route.mode(0o666,0o660,0o644) unless accounts share the lock; without a mode the exposure is the truncation only.preserve_lock_file=True). Once a lock file owned by the lock user exists in a sticky directory, another user cannot rename or link over it.flocksemantics,SoftFileLockapplies its mode only to the marker it created withO_EXCLand does not truncate an existing file.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.
ANT-2026-KO573NWI; the other three security findings have their own advisories)Severity
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:NReferences
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
modeargument.FileLock(path, mode=0o600)creates the same file asFileLock(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 theReadWriteLockdatabase, which it asks to be0o600, 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 lateracquire()calls waiting or timing out. They can read holder metadata anon_acquiredhook left in apreserve_lock_file=Truefile. Where the directory hands down modify access, they can write to both files.lock.modestill reports0o600. 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:Lscores 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 where0o600was 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=0o600across 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
FileLockandAsyncFileLockon Windows (WindowsFileLock), and the SQLite database ofReadWriteLockandAsyncReadWriteLock. Both go through_open_non_reparse_fd. The soft locks create their markers withos.open, which also keeps only a read-only bit of the mode on Windows; the scanner did not examine them further.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.LockFileExdocumentation, 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 withpreserve_lock_file=True. TheReadWriteLockdatabase is not unlinked at any point.UnixFileLockcreates the file with the mode and repeats it withfchmod. Mutual exclusion between cooperating processes is not affected.Affected code
Scanned commit
b831496b0273:_open_non_reparse_fdreduces the mode to oneread_onlybit. That bit is false for every accepted mode, because_check_moderejects any mode without owner read and write, and an unset mode becomes0o666. In_nt_opentheOBJECT_ATTRIBUTES.SecurityDescriptorfield stays unassigned, andread_onlyonly choosesFILE_ATTRIBUTE_READONLY._open_lock_databasepasses0o600through 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
modeparameter and on Windows handed it toos.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)computesread_only = not mode & _OWNER_WRITEand calls_nt_open(path, read_only=read_only)._nt_openfills anOBJECT_ATTRIBUTESwith the NT path andOBJ_CASE_INSENSITIVEand leavesSecurityDescriptorNULL. It then callsNtCreateFilewithFILE_OPEN_IFandFILE_ATTRIBUTE_NORMAL(orFILE_ATTRIBUTE_READONLYwhenread_only, which no accepted mode produces). Nothing consults the group and other bits. Per theNtCreateFileandOBJECT_ATTRIBUTESdocumentation, 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 withmode=0o600in a directory that hands down read access toUsersis therefore readable byUsers.Nothing tells the caller. The constructor validates the mode,
lock.modereturns0o600, andhas_explicit_modeisTrue.docs/concepts.rstsays "filelock creates the file with it" and that "0o600and0o700keep other UIDs out", with no Windows caveat. Only the_open_non_reparse_fddocstring and a comment in_soft.pyrecord the limitation.Reproduction
The scanner's reproducer for
ANT-2026-0KEO0DDO, quoted as received. It ran against commitb831496b0273.reprorepro.d/job_with_default_lock.pyrepro.d/job_with_private_lock.pyrepro.d/run_on_windows_backend.pyFailure 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=TrueEvidence
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 withmode=0o600and the one without produce identical call lists (RtlDosPathNameToNtPathName_U_WithStatus,NtCreateFilewithFileAttributes=0x80andObjectAttributes.SecurityDescriptor=None,RtlFreeUnicodeString,GetFileInformationByHandle,LockFileEx,UnlockFileEx), while the Unix control produced0o600and0o644files. It printsOBSERVED the two Win32 call lists are identical: TrueandBUG. 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
BUGon the scanned commitb831496and on the 4.2.0 release image.Maintainer verification on Windows 11 with two local accounts: a script creates
private.lockwithFileLock(mode=0o600, preserve_lock_file=True),default.lockwithout a mode, and aReadWriteLockdatabaselock.dbas the first account, in a directory granted(OI)(CI)(M)to a second account that is a member ofUsers. It then opens each file under the second account's logon token withLogonUserWandImpersonateLoggedOnUser. On 4.2.0 the second account could openprivate.lockandlock.dbfor both read and write, the same asdefault.lock, andicaclslisted only inherited(I)entries on all three. This confirms the claim the review had marked unconfirmed.Impact
A program that passes
mode=0o600so 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 theReadWriteLockdatabase. 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
ReadWriteLockdatabases in a directory whose ACL already excludes other accounts (inside the user profile, or a directory with inheritance disabled and only the owner,SYSTEMandAdministratorsgranted), rather than relying onmode.preserve_lock_file=Trueor aReadWriteLockdatabase, set its ACL yourself, for exampleicacls <file> /inheritance:r /grant:r "<owner>:F" "SYSTEM:F" "Administrators:F"; a file that exists keeps its ACL on later opens.on_acquiredon 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.
Severity
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:LReferences
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 ofFileLockandAsyncFileLockon Unix, empties whatever regular file it finds at the lock path once it holds theflock(a kernel lock on an open file). With an explicitmodeit 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 nextacquire(). A hard link is a second name for the same file. With a mode such as0o666the 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/tmpneedsfs.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:Nscores 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 explicitmodethe 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
FileLockandAsyncFileLockon Unix (UnixFileLock).SoftFileLockapplies an explicit mode only to a file it created withO_CREAT | O_EXCLand does not truncate an existing file.WindowsFileLockhas not truncated at any version./tmpcleaner, or after a release with the defaultpreserve_lock_file=False, which unlinks the file. The scanner checked three ways at the scanned commit, with default kernel settings unless stated:0777directory);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 withEPERM;link(2)into a sticky directory. This needs a system that lets a user hard-link a file it cannot write, which on Linux meansfs.protected_hardlinks=0. Mainstream distributions set 1, which refuses the link. The scanner did not test macOS or the BSDs.FileLock(path)the lock truncates the file, which keeps its mode. With an explicitmode(a lock shared between users needs0o666or0o660, becauseUnixFileLockopens the file read-write), the lock also chmods the file to that mode._apply_explicit_modesuppressesPermissionErroronly for files the lock user does not own. The lock user owns its own files, so thefchmodsucceeds.O_NOFOLLOWmakes the open fail withELOOP; mutual exclusion between cooperating processes.Affected code
Scanned commit
b831496b0273:UnixFileLock._finalize_locked_fd, whoseos.ftruncateand_apply_explicit_modecalls have only thest_nlink != 0guard (the file still has at least one name);_apply_explicit_mode;_open_lock_file, which learns from itsO_EXCLcreate whether this attempt made the file but hands that flag only to theENOSYSfallback.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 withgit tag --contains). Before it the code passed the mode only toopen(), 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.0understated it, as the review noted.Mechanism
_open_lock_filefirst triesos.open(path, O_RDWR | O_NOFOLLOW | O_CREAT | O_EXCL, mode). With the lock user's file renamed to the lock path that fails withFileExistsError. The secondos.open(path, O_RDWR | O_NOFOLLOW)succeeds, because the entry is a regular file the lock user owns, and returnscreated = False._acquire_nativepassescreatedonly to theENOSYSbranch. No process holds aflockon 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), thenos.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_NOFOLLOWdoes 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.AsyncUnixFileLockinherits_finalize_locked_fdunchanged.The scanner measured three variants at the same commit, same accounts (
victimuid 1000,attackeruid 1001). First, a rename within a0777directory: the nextFileLock("jobs.lock", mode=0o666)ofvictimempties the0600journal ofvictimrenamed tojobs.lockand sets it to0666;attackerthen reads whatvictimkeeps writing through its open descriptor. Second, a rename of a two-name file (ln /tmp/cache/blob ~/env/blob,0644) from a0777directory,fs.protected_hardlinks=1: aftermv /tmp/cache/blob /tmp/cache/app.lockandFileLock("/tmp/cache/app.lock", mode=0o666)asvictim,~/env/blobhas2 links, mode 666, 0 bytesandecho pwned >> /home/victim/env/blobasattackersucceeds, in a directoryattackercannot write. Third,os.link(notes, lock_path)in a1777directory withfs.protected_hardlinks=0:notes.txt(0644, in the home ofvictim) ends up 0 bytes with mode0666, andopen(notes, "w")asattackerthen succeeds. With plainFileLock(lock_path)a0600file 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 commitb831496b0273.reprorepro.d/attacker_read_file.pyrepro.d/attacker_rename_journal.pyrepro.d/victim_job_runner.pyAttack 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) -> EEXIST V->>K: open(jobs.lock, O_RDWR|O_NOFOLLOW) -> fd (regular file, created=False) V->>K: flock(fd, LOCK_EX|LOCK_NB) -> ok (no holder) rect rgb(255, 214, 214) V->>K: fstat(fd), st_nlink != 0 V->>K: ftruncate(fd, 0) V->>K: fchmod(fd, 0o666) Note over V,K: the journal's inode is now empty and world read-write, still owned by victim end V->>K: write("ran job 2 <secret>") through the journal descriptor it still holds A->>D: read jobs.lock -> "ran job 2 <secret>"Evidence
The scanner reproducer (
victimandattackeraccounts, root-created0777directory without the sticky bit under/tmp, default sysctls, Linux 6.1, CPython 3.14.8, overlayfs; lockFileLock(path, mode=0o666, timeout=5)). It printedCONTROL journal: inode 296383, uid 1000, mode 600, content 'ran job 1\n'andCONTROL attacker reads the journal: 'permission denied\n'. After the rename and the second job ofvictimit printedOBSERVED lock path: inode 296383, uid 1000, mode 666, content 'ran job 2 f4bc9a4e04c3f556\n'andOBSERVED attacker reads the lock path: 'ran job 2 f4bc9a4e04c3f556\n', last lineBUG. The verdict requires that the earlier read byattackerfailed, that the lock path is the journal's inode, that the old line is gone, that the mode went from0600to0666, and that the later read byattackercontains the secret. It runs in under a second with no race. The scanner ran the two-name andlink(2)variants above by hand at the same commit (commands and results in its report), not through the script.Maintainer triage: the reproducer prints
BUGon the scanned commitb831496and on the 4.2.0 release image. The independent review (soft-open) confirmed the mechanism and that the hard-link and two-name variants go through the same two calls.Impact
The file's content is lost in every configuration, including for processes that hold the file open and under every other name the file has. With an explicit permissive
mode, the other user can read and modify everything the lock user writes afterwards, while the file still belongs to the lock user. The other user can rename the file back to its old name after the acquire. It stays there with the lock's mode, and the lock user's next acquire creates a fresh lock file.Somebody who may rename a single-name file may also unlink it, so losing such a file under its name is not new. What the lock adds are two operations on the inode that the other user cannot perform,
ftruncateandfchmod, run with the lock user's privileges. Those matter for a descriptor the lock user still holds, for a second name of the file, and for programs that trust the file's ownership. The other user does not choose the mode, and the lock user writes no bytes the other user chose. Mutual exclusion is not affected.Workarounds
fs.protected_hardlinks=1(the default on mainstream distributions), which closes the hard-link route.mode(0o666,0o660,0o644) unless accounts share the lock; without a mode the exposure is the truncation only.preserve_lock_file=True). Once a lock file owned by the lock user exists in a sticky directory, another user cannot rename or link over it.flocksemantics,SoftFileLockapplies its mode only to the marker it created withO_EXCLand does not truncate an existing file.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.
ANT-2026-KO573NWI; the other three security findings have their own advisories)Severity
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:NReferences