CVE-2026-112912

What it actually does

SoftFileLock follows a swapped symlink during an os.access writability check on nodes lacking owner-write bits, leaking existence and writability of a chosen path to another local user via observable lock acquisition results.

Why it matters to the business

Attackers on shared systems can probe for sensitive file locations and permissions, increasing risk of targeted follow-on attacks; the flaw affects a widely used Python dependency in development and CI tooling with an available exploit and recent publication.

How an attack unfolds

An attacker with local access creates or swaps a symlink to a target path, triggers SoftFileLock's conditional access check in versions 3.32.6 to 4.2.0, and observes whether the lock succeeds to infer the target's existence and writability; the published exploit lowers the barrier for local reconnaissance.

How to fix it

Upgrade the filelock package to version 4.2.1 or later in all environments; verify the resolved version after installation and rebuild any affected containers or virtual environments.

How to confirm the fix worked

Run pip show filelock or equivalent package manager commands to confirm version 4.2.1 or newer is installed; test SoftFileLock behavior with crafted symlinks in a controlled environment to verify the symlink-following check is disabled.

Typical attack path

1. Identify a target path whose existence or writability is of interest.
2. Create or atomically swap a symlink pointing to the target in a directory where the victim process runs SoftFileLock.
3. Trigger the vulnerable SoftFileLock acquisition from the victim process.
4. Observe the lock result to determine if the target exists and is writable.
5. Use the inferred information to guide further local attacks.

How to detect it

Review process creation and file access logs on multi-user systems for unexpected symlink operations around Python processes using filelock; look for repeated lock acquisition attempts on paths that do not exist.

What your security team should do

• Immediately prioritize upgrade to filelock 4.2.1 across all Python projects and CI pipelines.
• Scan dependency manifests and lockfiles for versions between 3.32.6 and 4.2.0.
• Review shared development or build hosts for local users who could leverage the information leak.
• Monitor for new exploit releases given the ExploitAvailable maturity.