The vulnerability is a race condition in SoftFileLock's stale‑lock removal logic. When an attacker releases its own stale lock marker, an honest contender can create a new lock using the same inode; if the modification time of the new marker is not newer than the observation stored by SoftFileLock, the library mistakenly deletes the live marker and permits two concurrent holders. This breaks the expected exclusive lock guarantee, potentially allowing concurrent processes to modify the same shared resource.

The affected vendor and product are tox‑dev:filelock, the Python filelock library. Versions from 3.22.0 up to (but not including) 4.2.1 contain the flaw. The fix is available in release 4.2.1 and later.

The CVSS score of 4.7 indicates low severity, and no EPSS score is available. The issue is not listed in the CISA KEV catalog. The likely attack vector is local; it requires concurrent access to the same lock file by two processes, one of which could be malicious, and relies on a race condition that must be precisely timed. While exploitation is non‑trivial, the breach of mutual exclusion can lead to data corruption or interference between processes.