filelock EUVD-2026-105018

Exploitation requires: (1) a local attacker account on the same host as the victim; (2) use of the opt-in StrictSoftFileLock (3.30.0 through <4.2.1) or SoftReadWriteLock (4.0.0 through <4.2.1) classes - the default FileLock is not affected; (3) the lock's protocol directory ('<path>.filelock'/claims or '<path>.rw'/gen/holders) placed in a parent directory writable by other local users; and (4) the attacker creating that protocol directory before the victim acquires the lock, winning the ordering race. Limiting factors that reduce realistic risk: no remote vector (local access only), no confidentiality impact, the need for a shared writable/non-sticky parent directory, reliance on non-default lock classes, and the race/ordering requirement reflected in AC:H. The fix refuses coordination directories owned by a foreign account under sticky parents such as /tmp and opens directories with O_NOFOLLOW, so default sticky-directory deployments are already partially protected.

This is a medium-severity, local-only issue whose signals are internally consistent and point to limited real-world urgency. The CVSS vector (AV:L/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:H, base 6.3) requires an attacker to already have a local account on the same host (PR:L) and to win an ordering/race condition by creating the protocol directory before the victim (AC:H), with no confidentiality impact (C:N) but high integrity and availability impact because mutual exclusion is broken and concurrent holders are admitted. No EPSS score, CISA KEV listing, or POC is present in the supplied intelligence, so there is no public exploit identified at time of analysis and no evidence of active exploitation. These signals do not conflict: a local-only, race-dependent lock-bypass in an opt-in Python lock class is characteristically low-probability and situational rather than mass-exploitable. One inconsistency must be flagged: the input Tags include 'Information Disclosure', but the CVSS vector explicitly sets C:N and the description describes a locking/concurrency integrity failure, not data leakage - the tag appears mislabeled and should not drive triage. Net priority is moderate for multi-tenant Linux hosts that use StrictSoftFileLock or SoftReadWriteLock in a world-writable shared directory, and low elsewhere.

On a multi-user Linux host where filelock's StrictSoftFileLock or SoftReadWriteLock places its coordination directory in a shared, non-sticky parent directory, a local attacker pre-creates the expected protocol directory (e.g. '<path>.filelock'/claims or '<path>.rw') before the victim process acquires the lock. The victim adopts the attacker-owned directory and its protocol state, letting the attacker admit concurrent lock holders and corrupt the resource the lock was meant to serialize. No public exploit code was identified in the provided data, and exploitation depends on winning the directory-creation race.