Live › vulnerability › CVE-2026-112911
Go to dashboardfilelock is a Python library for cross-process file locks. Between versions 3.30.0 and 4.2.1, StrictSoftFileLock and SoftReadWriteLock can adopt a lock directory created first by another local user in a shared parent directory, letting that user alter lock state and let concurrent holders in.
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.
Exposure needs a Python application that uses StrictSoftFileLock (from 3.30.0) or SoftReadWriteLock (from 4.0.0) with lock files in a directory other local users can write to, such as a shared /tmp path on a multi-user host. Single-user machines, containers with a private lock directory, and code that uses other filelock lock classes are not affected.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| tox-dev filelock | vendor | >= 3.30.0, < 4.2.1 | 4.2.1 |
pip show filelock or pip freeze | grep -i filelock and check whether the version is at least 3.30.0 and below 4.2.1.StrictSoftFileLock or SoftReadWriteLock with lock paths in a shared directory such as /tmp.4.2.1 or later.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.30.0 until 4.2.1, StrictSoftFileLock versions from 3.30.0 and SoftReadWriteLock versions from 4.0.0 can adopt a protocol directory created first by another local user in a shared parent directory, allowing that user to alter protocol state and admit concurrent holders. This issue is fixed in version 4.2.1.
This page as .md · .json · in your agent: get_signal("CVE-2026-112911")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.