Live › vulnerability › CVE-2026-112912
Go to dashboardSoftFileLock in filelock versions 3.32.6 through 4.2.1 can follow a swapped symbolic link during its writability check. A local user can infer whether a chosen path exists and is writable from whether the lock acquisition succeeds.
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 on a shared machine where another local user can create symbolic links in the lock file's directory. Systems with single-user machines or containers that do not share directories with other users are much less exposed. Teams that do not use SoftFileLock or that run only on a single-user host can likely skip it.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| tox-dev filelock | vendor | >= 3.32.6, < 4.2.1 | 4.2.1 |
pip show filelock or python -c "import filelock; print(filelock.__version__)" and check whether the version is at least 3.32.6 and below 4.2.1.requirements.txt, poetry.lock or uv.lock.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.32.6 until 4.2.1, SoftFileLock can follow a swapped symbolic link during the conditional os.access writability check for a node without its owner-write bit, allowing another local user on a platform and directory configuration that follows the link to infer whether a chosen path exists and is writable from the observable acquisition result. This issue is fixed in version 4.2.1.
This page as .md · .json · in your agent: get_signal("CVE-2026-112912")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.