SoftFileLock in Filelock versions 4.1.0 through 4.2.1 can restore a stale lock marker by moving it aside and then recreating it. A local user with rename permission on a non‑sticky lock directory can replace that marker with a symbolic link that points to a target on the same filesystem. When the library later accesses the lock file, the runtime follows the link, creating a hard link to an arbitrary file owned by the attacker inside the lock directory. This allows the attacker to interfere with the locking process, potentially causing data corruption, unintended overwrite of files, or unauthorized access to authenticated data. The weakness is a form of improper input handling and path traversal, reflected by CWE‑59 and resource management error CWE‑363.

The vulnerability affects the tox‑dev Filelock Python package, specifically versions 4.1.0 through 4.2.1. Any environment where the package is installed and the lock directory is located on a writable, non‑sticky filesystem is vulnerable. All users who execute code that creates or manipulates Filelock locks in such directories could be impacted.

The CVSS score of 5.3 signals moderate severity, and the EPSS score is below 1%, indicating a low probability of widespread exploitation. The vulnerability is not listed in CISA’s KEV catalog. Exploitation requires local presence with write/rename rights to the lock directory. An attacker can manipulate the lock state or insert a hard link to a file of their choice, potentially disrupting concurrent processes or tampering with protected data. There is no evidence of remote or privilege‑escalation capabilities in the current description.