CVE-2026-112937: filelock: ReadWriteLock on the hard-link route deletes any directory another user renames onto its .filelock-* link directory name
filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, ReadWriteLock can remove a randomized .filelock- private-hard-link directory during cleanup, allowing another local user with rename access in a non-sticky parent to observe a live name or forge a dead-owner sweep name and rename a sibling directory onto it for deletion. 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
Which deployments are realistically exposed to this issue?
Deployments using filelock ReadWriteLock versions from 4.1.0 before 4.2.1 are exposed when its lock-related directory is under a non-sticky parent where another local user has permission to rename entries.
What does an attacker need to do to exploit it?
The attacker needs local access and rename access in the non-sticky parent directory. They must observe a live randomized .filelock-* name or forge a dead-owner sweep name, then rename a sibling directory onto that name before cleanup deletes it.
Are default installations affected?
The provided information does not establish whether a default configuration places lock directories in a non-sticky parent accessible to another local user. Exposure depends on the directory permissions and whether another user can rename entries there.
What should be done if an immediate upgrade is not possible?
Ensure the parent directory used for these lock-related paths is sticky or otherwise prevent untrusted local users from renaming entries in it. Upgrade to filelock 4.2.1 when possible.
How can I determine whether I am affected?
Check whether your application uses ReadWriteLock from filelock 4.1.0 through versions before 4.2.1, and inspect the parent directory containing randomized .filelock-* directories. Systems are at risk if another local user can rename entries in that non-sticky parent directory.