Live › vulnerability › CVE-2026-112936
Go to dashboardfilelock's ReadWriteLock and AsyncReadWriteLock in versions 3.20.4 through 4.0.9 pass the lock path to SQLite without rejecting a final symbolic link. A local user who can create names in the lock directory can redirect database creation and locking, which can break mutual exclusion.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-23 21:57 UTC. All times on this page are UTC.
Only projects that use filelock's ReadWriteLock or AsyncReadWriteLock on a lock path in a shared or multi-user directory are exposed. Single-user machines, containers with a private lock directory, and projects that only use FileLock can skip it.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| tox-dev filelock | vendor | >= 3.20.4, < 4.0.9 | 4.0.9 |
pip show filelock or python -c "import filelock; print(filelock.__version__)" and check whether the version is between 3.20.4 and 4.0.9.ReadWriteLock or AsyncReadWriteLock with a lock path in a directory that other local users can write to.4.0.9 or later.Each row is the first time that source carried this signal. The analyst’s rows are its own findings.
filelock is a platform-independent file lock for Python. From 3.20.4 until 4.0.9, ReadWriteLock and AsyncReadWriteLock versions from 3.20.4 resolve the lock path and pass it to SQLite without rejecting a final symbolic link, allowing another local user who can create names in the lock directory to redirect database creation and locking or split mutual exclusion between targets. This issue is fixed in version 4.0.9.
This page as .md · .json · in your agent: get_signal("CVE-2026-112936")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.