The vulnerability exists in filelock versions 3.20.4 through 4.0.8, where ReadWriteLock and AsyncReadWriteLock resolve the lock path and allow a symbolic link at the lock file location. The library passes the resolved path to SQLite without rejecting a trailing symlink, so a local user who has write access to the lock directory can create a symlink pointing to an arbitrary location. When the affected application subsequently creates the SQLite database, the database file is created at the location the symlink points to or the existing database is locked incorrectly. This can allow the local user to divert the database contents, corrupt the database, or, if the application runs with elevated privileges, cause data tampering or privilege escalation.

This affects the tox‑dev filelock Python library, versions 3.20.4 to 4.0.8 inclusive. The fix is applied in release 4.0.9. Any Python application that depends on filelock 3.20.4–4.0.8 and creates SQLite databases or locks under a directory writable by other local users is potentially affected.

The CVSS score is 6.1, indicating moderate severity. EPSS is not available, and the issue is not listed in CISA KEV. The exploit requires local user access to the lock directory; no remote exploits are described. An attacker with local file‑write capability could redirect or corrupt the SQLite database, potentially leading to privilege escalation if the application runs with higher permissions. While no public exploits are documented, the possibility of local misuse warrants patching.