The filelock package contains a time‑of‑check/time‑of‑use race condition in its SoftFileLock implementation. During a window between permission validation and the creation of the lock file, an attacker with local file system access can replace the intended lock file path with a symbolic link. This can cause the lock to operate on an unintended target file or result in a failure of the lock operation, potentially leading to denial of service or inconsistent locking behavior for applications that rely on filelock.

Projects that incorporate the tox‑dev filelock Python library with a version older than 3.20.3 are affected. The vulnerability manifests in the _acquire() method of SoftFileLock, so any code that performs lock acquisition via filelock before the 3.20.3 release is potentially exposed.

The CVSS base score is 5.3 indicating moderate severity. The EPSS score is reported as < 1 %, showing a very low likelihood of exploitation at this time. The vulnerability is not listed in the CISA KEV catalog. The attack vector requires local filesystem access and the ability to create symlinks, so it is generally limited to users with sufficient local privileges. If successfully exploited, an attacker could force the lock to reference a different file or trigger denial of service, disrupting application workflow.