CVE-2026-112909

What it actually does

UnixFileLock in filelock can truncate a target file or alter its permissions when a local attacker with rename or hard-link privileges races to place a file on the lock path, due to unsafe handling of file operations without proper atomicity checks.

Why it matters to the business

Attackers on the same system could corrupt or modify configuration and data files managed by Python applications using this library, leading to service disruption, unauthorized changes, or data integrity loss in shared environments.

How an attack unfolds

A local attacker creates or renames a file onto the intended lock path or hard-links under permissive policies, then triggers the lock acquisition in the vulnerable application; when an explicit mode is set, the file's permissions can also be changed. Public exploit code is available, though no named threat actors or ransomware use have been observed.

How to fix it

Upgrade filelock to version 4.2.1 or later on all affected systems. Where immediate upgrade is not possible, restrict local user permissions on lock file paths and avoid explicit mode requests in lock usage.

How to confirm the fix worked

Verify the installed filelock package version is 4.2.1 or higher using package managers or dependency scanners. Review application code for UnixFileLock usage and test lock behavior under concurrent rename scenarios in a controlled environment.

Typical attack path

1. Identify a Python process using filelock on a Unix system with the vulnerable library version.
2. Obtain local user access with rename or hard-link permissions on the target path.
3. Race the file placement onto the lock path before the application acquires the lock.
4. Trigger lock operations to cause truncation or mode change on the attacker's file.
5. Abuse the resulting file state for further impact such as configuration tampering.

How to detect it

Search application and system logs for unexpected file truncation or permission changes on paths used by filelock. Review process creation events and file access patterns around Python processes for anomalies indicating race conditions or local file manipulation.

What your security team should do

• Prioritize upgrading all instances of filelock to 4.2.1 within the next patch cycle due to available public exploits.
• Audit Python dependency trees for filelock usage across development and production environments.
• Implement filesystem permissions hardening on paths used for file locking.
• Monitor for new releases and apply updates promptly given the nine-day publication window.