CVE-2026-112914

What it actually does

SoftFileLock in filelock 4.1.0-4.2.0 restores a stale marker by name after moving it aside, permitting a local attacker with rename access in a non-sticky directory to substitute a symlink; on link-following runtimes sharing the filesystem this causes the lock process to hard-link an attacker-chosen file into the lock directory, resulting in unauthorized file placement with integrity impact.

Why it matters to the business

Local users on shared systems can cause unexpected file modifications or placements through the locking mechanism, potentially leading to data corruption, unauthorized access to files, or disruption of processes relying on file locks; urgency is moderate given the six-day-old public exploit and local attack requirements.

How an attack unfolds

An attacker with local rename access in the lock directory moves the marker aside, replaces it with a crafted symlink pointing to a target file on the same filesystem, and waits for the victim process using SoftFileLock to restore the marker; the runtime follows the link and performs a hard-link operation that places the attacker's chosen file into the lock directory.

How to fix it

Upgrade filelock to version 4.2.1 or later for all affected Python environments; where immediate upgrade is not possible restrict lock-directory permissions to sticky-bit mode or isolate processes that require file locking.

How to confirm the fix worked

Confirm the installed filelock version is 4.2.1 or newer via package metadata; review application code and dependency manifests for any pinned older versions and test lock behavior in a controlled directory without symlink traversal.

Typical attack path

1. Identify a non-sticky directory used for SoftFileLock markers by a target Python process
2. Obtain rename access in that directory as a local user
3. Move the existing marker aside and substitute a symbolic link to a chosen target file
4. Trigger or wait for the victim process to perform lock acquisition which follows the link
5. Achieve hard-link of the target file into the lock directory

How to detect it

Review application logs for unexpected hard-link operations or file creations inside lock directories; inspect process execution and file-system events around SoftFileLock usage for symlink creation or marker manipulation by non-owner users.

What your security team should do

• Immediately audit all Python environments for filelock versions between 4.1.0 and 4.2.0 and schedule upgrades to 4.2.1
• Enforce sticky-bit permissions on directories used for file locks where feasible
• Monitor for new exploit code leveraging the public availability and reassess KEV status
• Restrict local user rename access to shared lock directories as a compensating control