ReadWriteLock in the filelock Python library opens the SQLite lock database and its side files using file names. On POSIX systems, an attacker who can rename files inside a non‑sticky parent directory can swap the database and transaction names, causing the lock user to overwrite or unlink its own files. If a writable adjacent hot journal file is also present, the attacker can further create overwrites with attacker‑chosen content. This flaw allows an attacker to delete or corrupt files used by the locked process, potentially leading to loss of data or accidental code replacement.

All versions of tox‑dev:filelock from 3.20.4 up to, but not including, 4.2.1 are vulnerable. The issue is resolved in release 4.2.1 and later. Users of the filelock package, particularly those running on POSIX platforms, should verify the installed version and upgrade if it falls within the affected range.

The CVSS score of 7.1 indicates high severity. The EPSS score of 0.00116 indicates a very low exploitation probability, and the vulnerability is not listed in the CISA KEV catalog, but a local attacker with rename and file creation rights in a non‑sticky directory can exploit the flaw by manipulating SQLite lock files. No remote‑execution vector is disclosed; the attack requires local filesystem access and a writable hot journal to achieve arbitrary overwrites. When combined with access to the target process’s environment, the flaw can lead to integrity violations or denial of service.