Python filelock EUVD-2026-105025

Requires: (1) use of filelock's SoftFileLock, MarkerSoftFileLock, or SoftFileLease class (not the default hard FileLock) at versions 3.22.0 through 4.2.0; (2) a filesystem that recycles freed inode numbers to the next file, explicitly ext4 per the advisory; (3) a local account with write access to the lock directory on a shared host; and (4) the attacker winning a narrow TOCTOU window - freeing their own marker after the stale read while an honest contender creates a live successor on the reused inode whose modification time is not newer than the saved observation. LIMITING FACTORS: exploitation is local only (AV:L), needs an authenticated local user (PR:L), has high attack complexity because it depends on winning a race and on inode-number reuse (AC:H), and does not apply to deployments using the default FileLock or non-inode-reusing/atomic-exchange platforms (Linux renameat2 / macOS renamex_np paths are the fixed design).

This is a genuine but low-urgency correctness flaw rather than a high-impact priority. The CVSS 3.1 vector (AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:N, base 4.7 Medium) describes a locally exploitable TOCTOU race (CWE-367) that an already-authenticated local user can win only under high complexity. There is no public exploit identified at time of analysis, no CISA KEV listing, and no EPSS score was supplied, so there is no evidence of active or opportunistic exploitation - consistent with a timing-race bug that is hard to weaponize remotely or at scale. The only impact is integrity (I:H): the SoftFileLock stale-marker break logic can be driven to remove a live holder's marker so two holders are admitted at once, defeating mutual exclusion. CONFLICTING SIGNAL: the input Tags label this 'Information Disclosure', but the CVSS vector sets C:N (no confidentiality impact) and I:H - the real consequence is broken mutual exclusion / possible corruption of the protected resource, not data disclosure; the tag appears mislabeled. Net: patch opportunistically on multi-user or shared-filesystem hosts that rely on SoftFileLock, but this is not a drop-everything issue given AC:H, AV:L, PR:L and the absence of any exploitation evidence.

On a shared multi-user host where applications use filelock's SoftFileLock (3.22.0-4.2.0) on an inode-reusing filesystem such as ext4, a local user with a normal account repeatedly creates and frees their own lock markers to manipulate the stale-marker break sequence. By freeing their marker after the stale read while an honest process creates a live successor on the reused inode whose mtime is not newer than the saved observation, the attacker causes the live marker to be removed and two holders to be admitted simultaneously, breaking the lock's guarantee and risking corruption of whatever it protects. No public exploit code is known to exist.