CVE-2026-112906 tox-dev CVE debrief

Who should care

System administrators and developers using the filelock library should assess their exposure and update to version 4.2.1 or later. Those with sensitive resources protected by locks should implement additional monitoring and logging to detect potential exploitation attempts.

Why it matters

The filelock library vulnerability allows a local user to potentially evict a lock file and gain access to resources protected by the lock, compromising system integrity and allowing unauthorized access.

• Local users may gain unauthorized access to resources protected by locks
• Locks may be evicted, allowing concurrent access to sensitive resources
• System integrity may be compromised if an attacker can create pre-dated files in a directory where a lock file is present

Technical summary

The filelock library is vulnerable to a local user creating a pre-dated file in a directory where a lock file is present, potentially leading to the eviction of the lock file and allowing the local user to gain access to resources protected by the lock. The vulnerability exists in the SoftFileLock and MarkerSoftFileLock classes, which evict an unparsable marker (the lock file) once a waiting contender has watched it unchanged for two seconds.

Defensive priority

Medium

Recommended defensive actions

• Review and update filelock library to version 4.2.1 or later
• Implement additional monitoring and logging to detect potential exploitation attempts
• Restrict access to sensitive resources protected by locks
• Confirm whether affected product deployments exist in managed environments and assign an owner for follow-up
• Review the supplied official advisory or CVE record to validate affected scope, severity, and vendor guidance
• Plan vendor-supported updates or mitigations through normal change control where exposure is confirmed
• Check relevant monitoring, detection, and logs for exposed assets that need extra review

Evidence notes

The vulnerability exists in the filelock library, specifically in the SoftFileLock and MarkerSoftFileLock classes. These classes evict an unparsable marker (the lock file) once a waiting contender has watched it unchanged for two seconds. Another local user who can create files in the lock's directory can park an empty file of its own at the lock path, date it to a future tick of the kernel's coarse clock, let the waiters of the user running the lock watch it past two seconds, and unlink it in that tick. On a filesystem that hands a freed inode number straight back (ext4, overlayfs on ext4), the lock user's next marker repeats both values. It inherits the time spent watching the other user's file, and a second waiter removes it while its owner holds the lock.

Sources and references

Methodology and review provenance

AI-assisted synthesis based on stored public vulnerability evidence. System validation, approval state, and publication status do not by themselves establish human review of this revision. PatchSiren helps prioritize defensive review and does not prove exposure or remediation on any system.