Log in Start free

Vulnerability · Published Nov 5, 2026 · Assigned by GitHub_M

CVE-2026-112913filelock: ReadWriteLock on Windows acts on SQLite side files another local user places beside its database

Low 3.3

In plain English

A low-severity security flaw in filelock from tox-dev. There are no confirmed reports of exploitation so far. The chance it is exploited in the next 30 days is estimated at 0.1% (higher than 2% of all known vulnerabilities). Fixed versions are available - upgrade the affected package.

Severity (CVSS 3.1)3.3Low
Exploit odds (30 days)0.1%top 98.3% of all CVEs
Exploited in the wildNo reportsnot in CISA KEV
Attack toolingNoneno public tooling known

Official description

filelock is a platform-independent file lock for Python. From 3.20.4 until 4.2.1, ReadWriteLock and AsyncReadWriteLock on Windows use _connect to attach SQLite to the lock database by pathname, allowing another local account that can create adjacent names to place a database-wal or database-journal side file before acquisition. An undeletable WAL file makes each read or write acquisition fail immediately with sqlite3.OperationalError regardless of timeout. Separately, when the database contains at least one table, a hot journal that grants the lock account modify rights can cause SQLite recovery to delete a file named by that journal only when the lock account has permission to delete the target. The issue requires a directory writable by another account, such as a shared Windows temporary directory, and does not affect private directories. This issue is fixed in version 4.2.1.

Affected packages & fixed versions

EcosystemPackageFixed inAdvisory
PyPIfilelock4.2.1GHSA-9vhv-jxww-xfm5
Ubuntu:26.04:LTSpython-filelockno fix listedUBUNTU-CVE-2026-112913
Ubuntu:26.10python-filelockno fix listedUBUNTU-CVE-2026-112913

Affected products (as reported)

VendorProductVersions
tox-dev filelock >= 3.20.4, < 4.2.1

Weakness: CWE-367 · Vector: CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L

References