CVE-2026-112911

What it actually does

A local race condition in StrictSoftFileLock (3.30.0+) and SoftReadWriteLock (4.0.0+) allows an attacker who creates a protocol directory first in a shared parent directory to control protocol state, enabling concurrent lock holders.

Why it matters to the business

Attackers with local access can bypass file locking protections in shared environments, risking data corruption or inconsistent application state in multi-user Python deployments; the flaw has been public for nine days with exploit code available, increasing urgency for any organizations using affected filelock versions.

How an attack unfolds

An attacker with local access in a shared directory creates the expected protocol directory before the victim process; the vulnerable lock code adopts the attacker-controlled directory, allowing the attacker to manipulate lock state and admit additional concurrent holders, violating intended mutual exclusion.

How to fix it

Upgrade tox-dev filelock to version 4.2.1 or later for all affected StrictSoftFileLock and SoftReadWriteLock usage; avoid running untrusted code in shared directories until patched.

How to confirm the fix worked

Confirm filelock version is 4.2.1 or newer via package metadata; review application code for use of StrictSoftFileLock or SoftReadWriteLock and verify they are instantiated only after the upgrade.

Typical attack path

1. Identify a shared parent directory used by a target Python process relying on filelock
2. Create the protocol directory with attacker-controlled contents before the target acquires the lock
3. Allow the target to adopt the directory and proceed with its locking protocol
4. Manipulate protocol state to admit concurrent access or corrupt lock semantics

How to detect it

Review application logs for unexpected concurrent file access or lock-related errors; inspect process listings and file creation events in shared directories for anomalous protocol directory creation by non-application users.

What your security team should do

• Immediately inventory all Python environments for filelock versions prior to 4.2.1
• Prioritize upgrade to 4.2.1 in any shared-directory or multi-user deployments
• Monitor for new exploit code leveraging the public proof-of-concept
• Restrict shared directory permissions where file locking is used until remediation is complete