The vulnerability in the filelock library allows a local user who can create a directory in a shared parent directory before the lock is acquired to cause the StrictSoftFileLock and SoftReadWriteLock implementations to adopt that directory as their protocol datastore. This results in a loss of mutual exclusion, allowing multiple processes to hold the lock simultaneously. The flaw is a race condition reflected by CWE-283 and CWE-412 and potentially leads to data corruption or unexpected behavior in applications that rely on exclusive file locking.

Affects the tox-dev/filelock package in versions 3.30.0 through 4.2.1 inclusive. These releases fail to sanitize or validate the location of the protocol directory, allowing an adversarial local user to interfere. The issue was first identified in 3.30.0 and fixed in 4.2.1. Users running earlier or affected versions should be aware that any concurrent access to the same lock path may be compromised.

The CVSS score of 6.3 indicates a medium severity. EPSS data is not available, and the vulnerability is not listed in the CISA KEV catalog, suggesting limited publicly known exploitation. The attack vector requires local access on the same system; an attacker would simply create a directory with the exact name before the lock is created. Once the lock adopts the outsider’s directory, another process can falsely acquire the lock, leading to race conditions. The exploitability is moderate to high for an insider or compromised process, but it does not enable remote code execution or privilege escalation.