filelock CVE-2026-112937

Exploitation requires: (1) a local account on the same host as the victim process; (2) rename access in a parent directory above the lock's database that is writable by group/others AND lacks the sticky bit (so the attacker can rename entries they do not own); and (3) the target application using filelock's ReadWriteLock (versions 4.1.0 through 4.2.0) with its database placed in such a shared directory, where filelock falls back to the randomized .filelock-* private-hard-link directory. LIMITING FACTORS: there is no remote or network vector (AV:L); a valid local authenticated user is required (PR:L); and default-secure deployments are NOT affected - when the database directory is owned by the locking account or root and is not group/other-writable, or when parent directories carry the sticky bit (e.g. a properly configured /tmp), the preconditions do not hold.

This is a genuine but narrowly-scoped medium-severity issue (CVSS 6.1), not a top-tier priority for most environments. The supplied CVSS vector (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:H/A:L) and CWE-367 (TOCTOU race) agree that this is a LOCAL, authenticated, same-host attack - there is no network vector and no remote mass-exploitation potential. The impact is integrity-centric (I:H: an attacker-chosen sibling directory gets deleted/replaced via the victim process's cleanup) with limited availability impact (A:L) and no confidentiality impact (C:N). No EPSS score, no CISA KEV listing, and no public POC were provided, so there is no public exploit identified at time of analysis and no evidence of exploitation in the wild; the risk profile points to targeted local privilege-boundary abuse on multi-user hosts rather than opportunistic widespread attack. CONFLICT TO NOTE: the input carries an 'Information Disclosure' tag, but the authoritative CVSS vector sets C:N - this is a data-destruction/integrity flaw, not information disclosure, so the tag should be disregarded. Overall prioritize only where filelock's ReadWriteLock runs in a shared, world/group-writable, non-sticky directory alongside untrusted local accounts; elsewhere the preconditions make real-world risk low.

On a shared multi-user POSIX host, a local attacker with rename access in a non-sticky parent directory above an application's filelock ReadWriteLock database observes the randomized .filelock-* private-hard-link directory name (or forges a dead-owner sweep name) and renames a sibling directory onto that name. During cleanup the legitimate lock-holding process then deletes the attacker-substituted directory. No public exploit code was identified, and exploitation requires an existing local account and specific writable-directory conditions.