filelock EUVD-2026-105020

Requires all of the following to coincide: the application uses SoftFileLock, MarkerSoftFileLock, or SoftFileLease from filelock 4.1.0-4.2.0; the lock directory resides on a directory WITHOUT the sticky bit and is shared with other local users; the attacker holds rename/write access within that directory; the target OS/runtime follows symbolic links during marker restore and the hard-link target is on the same filesystem; and the attacker wins the brief TOCTOU window while a stale marker is moved aside and restored by name. Limiting factors that reduce realistic risk: local access and a second unprivileged account are mandatory (not remotely reachable), the race is high-complexity and timing-dependent, and the shared non-sticky-bit lock directory is a non-default/hardening-dependent deployment - sticky-bit directories (e.g. default /tmp) and platforms without symlink-following behavior are not exploitable.

All signals point to a genuinely low operational priority despite the MEDIUM 5.3 CVSS. The vector CVSS:3.1/AV:L/AC:H/PR:L/UI:N is local-only (AV:L) - there is no remote exploitation path - and carries High attack complexity (AC:H) because success depends on winning a narrow TOCTOU race during a stale-marker break plus several environmental preconditions. PR:L means an authenticated local user is required. No EPSS score, no CISA KEV listing, and no public exploit were provided in the input, so this is 'no public exploit identified at time of analysis' rather than active exploitation. One notable conflict: the input Tags label this 'Information Disclosure' while the CVSS vector rates integrity as the dominant impact (C:L/I:H/A:N) - the described effect (coercing the lock holder into hard-linking one of its own files into an attacker-accessible lock directory) blends a limited confidentiality exposure with a lock-mutual-exclusion/integrity break, so treat the single 'Information Disclosure' label as incomplete, not authoritative. Net: a real but low-urgency local hardening issue, not a widespread-exploitation emergency.

On a multi-user host where filelock's SoftFileLock places its lock in a shared directory without the sticky bit, a local attacker with rename access watches for a stale-marker break and, in the gap between the holder moving its marker aside and restoring it by name, swaps in a symbolic link. On a runtime that follows the link to a same-filesystem target, the legitimate lock process is tricked into hard-linking one of its own files into the lock directory, exposing it to the attacker and corrupting lock state. No public proof-of-concept was identified at time of analysis.