Live › vulnerability › CVE-2026-112915
Go to dashboardfilelock's ReadWriteLock opens a SQLite lock database without limiting schema and query work, so a crafted database can make lock acquisition stall or hang. An attacker who is a local user able to replace that database causes a denial of service, not code execution.
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.
Python applications that use filelock's ReadWriteLock on a lock database path that another local user can write to, such as a shared directory on a multi-user host. Single-user machines and containers where only the application user can write the lock path are much less exposed. Projects that do not use ReadWriteLock are not affected by this flaw.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| tox-dev filelock | vendor | >= 3.20.4, < 4.2.1 | 4.2.1 |
pip show filelock or python -c "import filelock; print(filelock.__version__)" and check whether the version is at least 3.20.4 and below 4.2.1ReadWriteLock from filelock, since the flaw is in that class4.2.1 or later with pip install -U "filelock>=4.2.1"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.2.1, ReadWriteLock can open a crafted SQLite lock database without bounding schema and query work, allowing another local user who can replace the database to make acquisition stall or hang; versions from 3.20.4 expose this on initial per-instance opening, and versions from 3.30.0 repeat the exposure on every acquisition. This issue is fixed in version 4.2.1.
This page as .md · .json · in your agent: get_signal("CVE-2026-112915")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.