filelock CVE-2026-112934

Requires: (1) a local account on the same host as the victim; (2) rename or write access to the SoftReadWriteLock directory - specifically an account with the same effective UID as the lock holder or ownership/write access to the parent, letting the attacker rename records over '<path>.rw', 'gen', or 'holders'; (3) the target application must use filelock's SoftReadWriteLock on an affected version (4.0.0 through 4.2.0); and (4) for the write-through (hard-link) variant, a permissive hard-link policy (e.g. fs.protected_hardlinks disabled) so a link to a reachable target file succeeds. Limiting factors: there is no network vector and no unauthenticated path - the attacker must already be a local, authenticated user sharing the lock directory; the FIFO-stall variant yields only denial of the lock, and the higher-impact write-through variant additionally needs the permissive hard-link configuration, making realistic risk confined to shared/multi-tenant UNIX hosts rather than single-user or isolated deployments.

This is a locally-exploitable, medium-severity issue, not a remote-critical one. The provided CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H, score 6.1) tells a consistent story with the description: an attacker needs an existing local account (PR:L) with rename access to the shared lock directory - not network reach. No EPSS score was supplied, no CISA KEV listing is present, and no public exploit code is referenced, so by the precision rules this is 'no public exploit identified at time of analysis.' All three real-world exploitation signals (EPSS/KEV/POC) are therefore absent or silent, which argues against treating this as an urgent, widely-weaponized threat. The impact split is also telling: confidentiality is N (so the 'Information Disclosure' tag conflicts with the vector - see data_quality_flags), the real impact is integrity (I:L, attacker-planted hard link causes the victim to write through a chosen file) and availability (A:H, a named pipe stalls the lock holder). Net assessment: a legitimate but low-priority hardening fix for multi-tenant/shared-host Python deployments using SoftReadWriteLock; it is not a high-CVSS-but-no-substance issue, but neither is it a drop-everything priority given the local, authenticated, shared-directory precondition and absence of any exploitation evidence.

On a shared multi-user host where a Python application uses filelock's SoftReadWriteLock against a lock directory writable by another local account, a malicious user with rename access replaces a holder record with a named pipe (FIFO) so the victim's heartbeat blocks and the lock stalls, or under a permissive hard-link policy links a sensitive target file over the record so the victim writes through it and corrupts it. No public proof-of-concept is referenced in the available data; exploitation requires an existing local foothold rather than any remote access.