CVE-2026-112914 tox-dev CVE debrief

Who should care

Defenders responsible for shared filesystem environments, especially those using the filelock package, should assess exposure and prioritize patching or mitigation. They should review the supplied official advisory or CVE record to validate affected scope, severity, and vendor guidance. They should also plan vendor-supported updates or mitigations through normal change control where exposure is confirmed.

Why it matters

Defenders should prioritize patching or mitigating this vulnerability, especially in shared filesystem environments, as it allows a local user to potentially access sensitive files.

• A local user can create a hard link to any of their own files on the same filesystem, potentially allowing them to access files inside directories they cannot enter.
• The vulnerability requires local access and a shared lock directory without the sticky bit.

Technical summary

The filelock package has a vulnerability in its soft-lock stale break restore mechanism, which allows a local user to create a hard link to any of their own files on the same filesystem. This vulnerability arises when a soft-lock stale break finds that the marker it renamed aside was a live one recreated by a successor. The restore branch of `break_lock_file()` checks the break name with `lstat` and then calls `os.link(break_path, lock_file)` by name. On CPython 3.12 and later on Linux, that call follows a symbolic link.

Defensive priority

Defenders should prioritize patching or mitigating this vulnerability, especially in shared filesystem environments.

Recommended defensive actions

• Patch filelock to version 4.2.1 or later
• Assess exposure in shared filesystem environments
• Monitor for suspicious hard link creation
• Review compensating controls for exposed systems while remediation is scheduled and verified
• Check relevant monitoring, detection, and logs for exposed assets that need extra review
• Track exceptions, retest remediated assets, and close the item only after evidence is documented
• Confirm whether affected product deployments exist in managed environments and assign an owner for follow-up

Evidence notes

The vulnerability is caused by a soft-lock stale break restore issue in the filelock package, which allows a local user to create a hard link to any of their own files on the same filesystem. The issue arises when a soft-lock stale break finds that the marker it renamed aside was a live one recreated by a successor. The restore branch of `break_lock_file()` checks the break name with `lstat` and then calls `os.link(break_path, lock_file)` by name. On CPython 3.12 and later on Linux, that call follows a symbolic link. A local user who

Sources and references

Methodology and review provenance

AI-assisted synthesis based on stored public vulnerability evidence. System validation, approval state, and publication status do not by themselves establish human review of this revision. PatchSiren helps prioritize defensive review and does not prove exposure or remediation on any system.