CVE-2026-112909: filelock: UnixFileLock truncates and chmods any regular file another user renames or hard-links onto the lock path
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
filelockto a version that resolves this vulnerability.Fixed in 4.2.1
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Local multi-user environments are exposed when another user can rename a regular file onto the lock path. Systems with a permissive hard-link policy may also be exposed if another user can hard-link a file to that path.
What does an attacker need to exploit it?
The attacker needs local access and the ability to place a regular file at the lock path, either through actual rename permission or, under permissive hard-link policies, by creating a hard link. No user interaction is required.
What is the impact if exploitation succeeds?
Affected UnixFileLock versions can truncate the file placed on the lock path. Versions affected from 3.10.2 can also change that file's mode when the application requests an explicit mode.
Which versions should be remediated?
Upgrade filelock to version 4.2.1, which fixes the issue. The truncation issue affects versions before 4.2.1; the mode-change behavior applies to affected versions starting with 3.10.2 when an explicit mode is requested.