Live › vulnerability › CVE-2026-112934
Go to dashboardVersions 4.0.0 through 4.2.1 of the filelock Python package let another local user with rename access to the lock directory swap a holder record for a named pipe, stalling the lock. Under a permissive hard-link policy, the same user can link a target file so the lock user writes through it.
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.
Systems running Python code that imports filelock between 4.0.0 and 4.2.1 and use SoftReadWriteLock with a lock directory that other local users can write to. The attacker must already have a local account on the same machine. Single-user machines and containers without shared lock directories can skip it.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| tox-dev filelock | vendor | >= 4.0.0, < 4.2.1 | 4.2.1 |
pip show filelock or python -c "import filelock; print(filelock.__version__)" and check whether the version is 4.0.0 to 4.2.1.SoftReadWriteLock (grep the code for SoftReadWriteLock).4.2.1 or later (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 4.0.0 until 4.2.1, SoftReadWriteLock refreshes holder records by name, allowing another local user with rename access to the lock directory to replace a record with a named pipe and stall the lock, or under a permissive hard-link policy to link a reachable target file and cause the lock user to write through it. This issue is fixed in version 4.2.1.
This page as .md · .json · in your agent: get_signal("CVE-2026-112934")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.