filelock EUVD-2026-105032

Requires a separate, co-located local user account on the same host who can replace the <path>.rw lock directory tree (via symlink or junction) after the first successful acquisition but before later record operations such as periodic heartbeat rewrites, exploiting that SoftReadWriteLock/AsyncSoftReadWriteLock cached the earlier ownership check and re-resolved names. Limited to filelock versions 4.1.0 through 4.2.0 using these specific read-write lock classes, and only where the lock tree resides in a location another account can modify; it requires local access and an existing local account (PR:L), there is no remote vector, and the attacker must act within the window between acquisition and record operations, so default single-user or non-shared deployments are not realistically exposed.

This is a low-severity, locally-exploitable TOCTOU flaw (CWE-367) whose signals are internally consistent and point to low real-world priority. The CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N, base 3.3) confirms local access and an already-authenticated local account are required, with only a low integrity impact and no confidentiality or availability loss. No EPSS score, CISA KEV listing, or public POC was provided in the input, so exploitation is assessed as no public exploit identified at time of analysis - this is NOT active exploitation and must not be treated as such. The only elevated signal is the ubiquity of the filelock library itself; however, the vulnerable SoftReadWriteLock/AsyncSoftReadWriteLock classes only exist from 4.1.0, narrowing the real exposure. Note a tag/impact conflict: the input Tags label this 'Information Disclosure', but the CVSS vector (C:N, I:L) and the description (redirecting lock-record WRITES) describe an integrity issue, not disclosure - the tag appears mislabeled. Net: a genuine but low-priority local race condition, not an urgent remote threat.

On a multi-user host, a local user acquires a SoftReadWriteLock backed by a shared <path>.rw tree that passes an initial ownership check. A second, co-located local user then replaces that tree (e.g., via a symlink or junction) before the lock holder performs later record operations such as heartbeat rewrites, causing the holder to write lock records into directories the attacker controls. No public exploit code was identified, and exploitation is bounded by the attacker needing their own local account and timing against the holder's record operations.