CVE-2026-112934

What it actually does

SoftReadWriteLock refreshes holder records by filename only, enabling local replacement of the record file with a named pipe (stalling the lock) or a hard link (causing writes to be redirected through the attacker-controlled target).

Why it matters to the business

Applications relying on filelock for coordination can be stalled or induced to corrupt data, leading to service outages or data-integrity failures in shared environments.

How an attack unfolds

A local user with rename or hard-link privileges in the lock directory replaces the holder record with a named pipe or link; when the victim process next refreshes the lock it either blocks indefinitely or writes through the attacker-chosen target. Public exploit code is already available.

How to fix it

Upgrade the filelock package to version 4.2.1 or later; remove any pinned older releases from dependency manifests and rebuild affected environments.

How to confirm the fix worked

Query the installed filelock version with pip show filelock or equivalent package-manager commands and confirm it reports 4.2.1 or higher; re-run application tests that exercise concurrent lock acquisition.

Typical attack path

1. Obtain a local account on the target system
2. Locate the directory containing the SoftReadWriteLock record file
3. Replace or link the record with a named pipe or reachable target file
4. Trigger the victim process to perform a lock refresh or acquisition

How to detect it

Review system and application logs for processes that remain blocked on file operations inside lock directories; look for unexpected named-pipe creations or hard-link entries within those directories around the time of suspected stalls.

What your security team should do

• Immediately upgrade all instances of filelock to 4.2.1+
• Scan dependency trees for any transitive use of vulnerable versions
• Restrict write access to lock directories where feasible
• Monitor for stalled processes that hold filelock resources