---
id: "CVE-2026-112915"
kind: "vulnerability"
aliases: ["CVE-2026-112915"]
title: "filelock: crafted SQLite lock database can hang Python lock acquisition"
severity: "medium"
cvss: 5.5
epss: null
exploited: false
status: "open"
category: "package"
products: [{"name": "tox-dev filelock", "fixed": ["4.2.1"], "affected": ">= 3.20.4, < 4.2.1", "ecosystem": "vendor"}]
ecosystems: ["vendor"]
tags: ["filelock", "package", "python", "self-hosted"]
not_affected_if: ["no-readwritelock-usage", "private-lock-path", "single-user-host"]
published_at: "2026-10-20T15:17:15+00:00"
first_seen_at: "2026-10-23T21:57:20+00:00"
updated_at: "2026-10-25T04:12:32+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-112915", "first_seen_at": "2026-10-23T21:57:20+00:00"}]
---

# filelock: crafted SQLite lock database can hang Python lock acquisition

filelock'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, check and fix written by a model from the sources; labelled as such._

## Affected

- vendor:tox-dev filelock affected >= 3.20.4, < 4.2.1 fixed 4.2.1

## How to check

- Run `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.1`
- Check whether the application uses `ReadWriteLock` from filelock, since the flaw is in that class

## Fix

- Upgrade filelock to `4.2.1` or later with `pip install -U "filelock>=4.2.1"`

## Timeline

- 2026-10-23T21:57:20+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-112915

## From the sources

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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_