CVE-2026-112937 tox-dev CVE debrief

Who should care

System administrators and developers using the filelock library, especially in macOS and POSIX environments, should assess exposure and update to version 4.2.1 or later. Affected operators must review compensating controls for exposed systems while remediation is scheduled and verified. Security teams should monitor for suspicious directory renaming activities and verify the filelock library version.

Why it matters

A vulnerability in the filelock library allows a local user to delete arbitrary directories, posing a medium defensive priority for system administrators and developers.

• A local user can delete arbitrary directories with the lock user's permissions
• A vulnerability exists in the filelock library, affecting macOS and POSIX processes
• The vulnerability can be exploited by renaming a directory onto the .filelock-* link directory name
• Verify the filelock library version and update to 4.2.1 or later

Technical summary

The filelock library uses a SQLite-backed reader/writer lock, which removes its private .filelock-* link directories with shutil.rmtree. However, it does not check if the path still names the directory it created. This vulnerability can be exploited on the hard-link route, affecting macOS since 4.1.1 and POSIX processes without a usable /proc/self/fd. The vulnerability is caused by the ReadWriteLock and AsyncReadWriteLock removing their private .filelock-* link directories with shutil.rmtree without checking if the path still names the directory they created. This can be exploited by another local user who can rename entries in the directory that holds the lock database. A local user can delete arbitrary with

Defensive priority

Medium

Recommended defensive actions

• Review and update filelock library to version 4.2.1 or later
• Assess exposure in macOS and POSIX environments
• Monitor for suspicious directory renaming activities
• Verify the filelock library version and update to 4.2.1 or later
• Check relevant monitoring, detection, and logs for exposed assets that need extra review
• Track exceptions, retest remediated assets, and close the item only after evidence is documented
• Confirm whether affected product deployments exist in managed environments and assign an owner for follow-up

Evidence notes

The vulnerability is caused by the ReadWriteLock and AsyncReadWriteLock removing their private .filelock-* link directories with shutil.rmtree without checking if the path still names the directory they created. This can be exploited by another local user who can rename entries in the directory that holds the lock database.

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.