CVE-2026-112915: filelock ReadWriteLock: a crafted lock database makes every acquire stall or hang regardless of timeout
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
filelockto a version that resolves this vulnerability.Fixed in 4.2.1
Event History
Frequently Asked Questions
Who can exploit this issue?
An attacker needs local access and the ability to replace the SQLite lock database used by ReadWriteLock. The impact is denial of service: lock acquisition can stall or hang.
Are timeouts an effective mitigation?
No. A crafted lock database can cause acquisition to stall or hang regardless of the configured timeout.
Which usage patterns are exposed most often?
Versions 3.20.4 through before 4.2.1 are affected. In versions 3.20.4 through 3.29.x, exposure occurs when a ReadWriteLock instance initially opens its database; from 3.30.0, the exposure repeats on every acquisition.
What should be done if patching is possible?
Upgrade filelock to version 4.2.1, which fixes the issue.