Python filelock CVE-2026-112909

Requires a second local user who has rename permission on the directory holding the UnixFileLock lock file (e.g. a group- or world-writable shared lock directory), OR a system with a permissive hard-link policy (Linux sysctl fs.protected_hardlinks=0) that lets the attacker hard-link an arbitrary target file onto the lock path. The mode-changing variant additionally requires the application to request an explicit mode and affects versions from 3.10.2 onward. Limiting factors: the attacker must already have a local account and write/rename access to the lock directory; default Linux hard-link protection (fs.protected_hardlinks=1) neutralizes the hard-link vector; applications that place lock files in per-user private directories not writable by others are not exposed; there is no remote or unauthenticated path.

This is a locally-exploitable, medium-severity integrity flaw, not an urgent remote threat. The provided CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:H/A:N, base 6.1) confirms the attacker must already hold a local account (PR:L) on the same host and have rename or hard-link access to the directory containing the lock file - there is no network vector. No EPSS score, no CISA KEV listing, and no POC were supplied in the input, so there is no signal of active or probable exploitation; exploitation status is 'no public exploit identified at time of analysis.' SSVC decision data was not provided. The signals are internally consistent (local vector matches a 'another local user' description), but note the 'Information Disclosure' tag understates the real impact: the dominant consequence is integrity/data-destruction (I:H, file truncation), with confidentiality only minor (C:L, from a possible mode change). Net: a legitimate but low-to-moderate-priority issue - patch in normal cycles, prioritized only where lock files sit in directories writable by untrusted local users.

On a host where an application places its lock file in a directory shared with other local users, an attacker with rename permission renames (or, under a permissive hard-link policy, hard-links) a victim's regular file onto the lock path. When the victim's application next calls acquire() on its UnixFileLock, affected filelock versions open that planted file as their own lock file and truncate it, destroying its contents; if the application requested an explicit mode, versions from 3.10.2 also change the file's permission bits. No public exploit code is identified at time of analysis.