Live › vulnerability › CVE-2026-112939
Go to dashboardVersions of the Python filelock package from 3.22.0 up to 4.2.1 let a process trust a forged process identifier in a SoftFileLock marker file. A local user who can modify that marker can cause the live lock to be removed and another holder admitted, breaking mutual exclusion.
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.
Only projects that use SoftFileLock (the file-based lock that is not OS-level) on a host where another local account, including root, can write to the lock directory. Single-user machines and containers where only one trusted process runs are unlikely to be exposed. Projects that use the OS-level FileLock backend or are pinned below 3.22.0 can skip it.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| tox-dev filelock | vendor | >= 3.22.0, < 4.2.1 | 4.2.1 |
pip show filelock or python -c "import filelock; print(filelock.__version__)", and flag anything from 3.22.0 up to but not including 4.2.1.SoftFileLock (for example grep -rn "SoftFileLock" .) on shared hosts or in multi-user environments.filelock to 4.2.1 or later, for example pip install --upgrade "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 trust a forged process identifier in a marker that an attacker can modify but cannot remove, allowing an authorized contender such as another process of the holder's account or root to act as a confused deputy, remove the live marker, and admit another holder. This issue is fixed in version 4.2.1.
This page as .md · .json · in your agent: get_signal("CVE-2026-112939")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.