filelock CVE-2026-112940

Requires: (1) a POSIX system running filelock 3.20.4 through 4.2.0 using the ReadWriteLock (SQLite-backed) feature; (2) a local attacker account holding rename/write access in a non-sticky parent directory at or above the lock database path, so the attacker can swap names between the lock's checks and SQLite's open; and (3) for attacker-chosen CONTENT overwrites specifically, an additionally writable adjacent hot journal file (name-swap alone yields overwrite/unlink). LIMITING FACTORS: exploitation is local only (no network vector), requires an existing low-privileged account, and is a timing-sensitive race. It does NOT apply when every parent directory is owned by the locking account or root and is either non-group/other-writable or carries the sticky bit, and is fixed outright in 4.2.1.

This is a genuine but conditional local-privilege issue, not a widespread remote threat. The provided CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:H, base 7.1) correctly scopes it as LOCAL with low privileges and no confidentiality impact - the damage is integrity/availability via file overwrite and unlink. CWE-363 (race condition / TOCTOU link-following) and the description's dependence on winning a swap window suggest the AC:L in the input is optimistic; a reliable attacker-chosen-content overwrite additionally requires a writable adjacent hot journal, which in practice argues for higher attack complexity than AC:L. No EPSS score, no CISA KEV listing, and no POC were supplied, so there is no public exploit identified at time of analysis and no signal of active or automated exploitation. Signals are internally consistent except for one conflict: the 'Information Disclosure' tag contradicts the CVSS C:N (no confidentiality impact) - the real impact is file overwrite/unlink, so treat the disclosure framing as mislabeled. Net: a real fix-worthy local race in a hugely popular library, but exploitation is gated on multi-user shared-directory conditions, so prioritize patching on shared/multi-tenant hosts rather than treating it as an internet-facing emergency.

On a shared POSIX host, a low-privileged local user with write/rename access to a non-sticky directory that contains (or sits above) another account's ReadWriteLock SQLite database races the lock acquire, swapping in crafted '-journal'/'-wal'/'-shm' side-file names so SQLite reopens and acts on attacker-controlled names. This lets the attacker unlink or overwrite victim-owned files, and with a writable adjacent hot journal, overwrite them with attacker-chosen content. No public exploit is identified at time of analysis; the attack requires winning a TOCTOU window and is local-only.