Live › vulnerability › CVE-2026-112941
Go to dashboardPython's filelock library, versions 4.1.0 through 4.2.1, caches a check of the <path>.rw lock directory and resolves its names again on later writes. A local user who can replace that directory after the first lock is taken can redirect lock-record writes into directories the lock user can write to.
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 filelock's SoftReadWriteLock or AsyncSoftReadWriteLock on a shared machine where another local user can write to the lock path. Single-user machines and containers where only the service account touches the lock directory face little practical risk.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| tox-dev filelock | vendor | >= 4.1.0, < 4.2.1 | 4.2.1 |
pip show filelock and confirm the installed version is between 4.1.0 and 4.2.0.SoftReadWriteLock or AsyncSoftReadWriteLock from filelock.4.2.1 or later (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 4.1.0 until 4.2.1, SoftReadWriteLock and AsyncSoftReadWriteLock cache a successful check of the <path>.rw lock tree and resolve its names again during later record operations, allowing another local user who can replace that tree after the first acquisition to redirect lock-record writes into directories writable by the lock user. This issue is fixed in version 4.2.1.
This page as .md · .json · in your agent: get_signal("CVE-2026-112941")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.