CVE-2026-112939

What it actually does

SoftFileLock trusts a modifiable but non-removable process identifier in its marker file, allowing an authorized local process to forge the PID, delete the marker as a confused deputy, and acquire the lock.

Why it matters to the business

Applications relying on exclusive file access in multi-process Python environments can experience lock bypass, leading to data corruption, inconsistent state, or unauthorized resource access; the library is widely used via tox and other packaging tools.

How an attack unfolds

An attacker with the same account privileges locates an active SoftFileLock marker, overwrites the stored PID with a forged value, removes the marker file, and then claims the lock; the library accepts the forged marker and grants access to the new holder.

How to fix it

Upgrade filelock to version 4.2.1 or later; rebuild and redeploy any affected Python environments or containers that depend on the library.

How to confirm the fix worked

Verify installed filelock version is 4.2.1 or higher via package metadata; run integration tests that exercise concurrent SoftFileLock acquisition from separate processes.

Typical attack path

1. Locate active SoftFileLock marker file created by target process
2. Modify the PID value inside the marker
3. Delete the marker file
4. Acquire the lock as the new holder

How to detect it

Monitor for unexpected modifications or deletions of SoftFileLock marker files containing process identifiers; inspect application logs for lock acquisition events that occur without corresponding process creation.

What your security team should do

• Upgrade filelock to 4.2.1 or newer across all environments
• Audit Python dependencies for filelock usage and pin to fixed release
• Review application code that relies on file-based locking for additional hardening