CVE-2026-112906: filelock: SoftFileLock evicts a fresh lock file whose watched age another local user's pre-dated file passed on through inode reuse
filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, SoftFileLock versions from 4.1.0 can reuse a stale observation when an attacker pre-dates and removes its own marker, at least two lock-user processes are waiting, coarse or matching modification times preserve the observation, and an honest contender creates a fresh marker on the reused inode, causing that live marker to be removed as stale. 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 exposed to this issue?
Deployments using filelock's SoftFileLock in versions 4.1.0 through before 4.2.1 are affected. Exploitation requires multiple local lock-user processes and conditions that allow a stale inode observation to be reused.
What access and conditions does an attacker need?
An attacker needs local access and low-privilege ability to create and remove their own lock marker. They must pre-date and remove that marker, have at least two lock-user processes waiting, and rely on coarse or matching modification times plus inode reuse when an honest process creates a fresh marker.
What is the impact if exploitation succeeds?
A fresh, live lock marker created by an honest contender can be removed as though it were stale. This can undermine the intended locking behavior and allow an attacker to affect integrity of operations guarded by the lock.
What should teams do?
Upgrade filelock to version 4.2.1, which fixes the issue. The provided data does not specify a workaround for deployments that cannot immediately upgrade.