Live › vulnerability › CVE-2026-112909
Go to dashboardfilelock's UnixFileLock can truncate a regular file that another local user renamed or hard-linked onto the lock path before 4.2.1. When an explicit mode is requested, affected versions from 3.10.2 can also change that file's permissions.
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 on Unix-like systems that use filelock's UnixFileLock with lock paths in directories other local users can write to. Windows-only deployments and systems where lock files live in private directories are less exposed. Teams that pin filelock below 4.2.1 should check their lock locations.
No product ranges from the sources yet.
pip show filelock or python -c "import filelock; print(filelock.__version__)" and compare against 4.2.1filelock Python package to 4.2.1 or laterEach 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. Prior to 4.2.1, UnixFileLock can truncate a regular file renamed onto the lock path when another local user has actual rename permission, or hard-linked there under a permissive hard-link policy; when an explicit mode is requested, affected versions from 3.10.2 can also change that file's mode. This issue is fixed in version 4.2.1.
This page as .md · .json · in your agent: get_signal("CVE-2026-112909")
NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.