Live › vulnerability › CVE-2026-112935
Go to dashboardfilelock's SoftFileLock can be tricked into removing a live lock marker after a stale-lock race, so two holders get admitted at once. An attacker who can race lock acquisition on a shared lock path can break mutual exclusion, which can corrupt data guarded by the lock.
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.
Applications that use SoftFileLock from filelock 3.22.0 up to but not including 4.2.1 to guard shared resources between processes. Exposure depends on an attacker being able to create and free lock markers on the same lock path, so multi-tenant or shared-filesystem setups are the main concern. Projects that use only the default platform lock or that do not depend on filelock can skip it.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| tox-dev filelock | vendor | >= 3.22.0, < 4.2.1 | 4.2.1 |
pip show filelock and check whether the version is at least 3.22.0 and below 4.2.1.filelock pins, for example grep -i filelock requirements*.txt poetry.lock uv.lock.4.2.1 or later, for example 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.22.0 until 4.2.1, SoftFileLock can break a stale marker after an attacker frees its own marker following the stale read, an honest contender creates a live successor on the reused inode, and the successor's modification time is not newer than the saved observation, causing the live marker to be removed and two holders to be admitted. This issue is fixed in version 4.2.1.
This page as .md · .json · in your agent: get_signal("CVE-2026-112935")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.