Race condition in filelock ReadWriteLock enables directory deletion
Key facts
- Attack vector
- Local
- Privileges required
- Low
- User interaction
- None
- Attack complexity
- Low
- Impact type
- —
- Confidentiality · integrity · availability
- None · High · Low
- Fix status
- Fixed
Attack profile from CVSS 3.1 · CNA. Fix status from CNA and GitHub.
Summary
The tox-dev filelock package from 4.1.0 before 4.2.1 has a race condition (CWE-367) in ReadWriteLock on the hard-link route. The lock can remove a randomized .filelock-* private hard-link directory during cleanup, so a local user with low privileges who has rename access in a non-sticky parent directory can rename another directory onto that name and have it deleted. The references include an exploit link.
Written with Claude Haiku 5.5 from the sources below · 2026-11-06
Description from the CNA
filelock is a platform-independent file lock for Python. From 4.1.0 until 4.2.1, ReadWriteLock can remove a randomized .filelock-* private-hard-link directory during cleanup, allowing another local user with rename access in a non-sticky parent to observe a live name or forge a dead-owner sweep name and rename a sibling directory onto it for deletion. This issue is fixed in version 4.2.1.
Why it matters now
SSVC decision points
CISA ADP · SSVC 2.0.3
- Exploitation
- None
- Automatable
- No
- Technical impact
- Partial
The decision (Track, Attend, Act) also depends on your mission and well-being impact; see CISA's SSVC guide.
Affected products
| Vendor | Product | Affected versions | Fixed in | Status | Source |
|---|---|---|---|---|---|
| tox-dev | filelock | 4.1.0 to before 4.2.1 | 4.2.1 | Patch available | CNA |
| — | filelock (PyPI) | 4.1.0 to before 4.2.1 | 4.2.1 | Patch available | GHSA-jqc4-5cvw-7w85 |
- filelock Vendortox-dev Affected 4.1.0 to before 4.2.1 Fixed in 4.2.1 Patch available CNA
- filelock (PyPI) Vendor— Affected 4.1.0 to before 4.2.1 Fixed in 4.2.1 Patch available GHSA-jqc4-5cvw-7w85
Remediation
Upgrade the filelock package to version 4.2.1, which fixes this issue in both the tox-dev and PyPI listings.
Written with Claude Haiku 5.5 from the sources below · 2026-11-06
- Fix · CNA filelock (tox-dev) Fixed in 4.2.1
- Fix · GHSA-jqc4-5cvw-7w85 filelock (PyPI) Fixed in 4.2.1 Advisory →
Vendor assessments
Timeline
- 2026-10-20 Threatist record created from CVE-2026-112937
- 2026-10-21 CISA SSVC decision points changed
- 2026-10-21 Priority changed: MEDIUM → LOW
- 2026-10-23 Alias added: GHSA-jqc4-5cvw-7w85
- 2026-10-23 Fix available: PyPI/[email protected] · GHSA-jqc4-5cvw-7w85
- 2026-10-23 CVSS score added · GHSA-jqc4-5cvw-7w85
- 2026-10-23 Weakness changed · GHSA-jqc4-5cvw-7w85
- 2026-10-23 6 new references · GHSA-jqc4-5cvw-7w85
- 2026-11-06 Affected versions changed · Red Hat
- 2026-11-06 CVSS score added · Red Hat
References
Patch 2
More tox-dev Filelock vulnerabilities
- TI-2026-76862 Symlink race in filelock ReadWriteLock lets attackers overwrite files CVSS 3.1HIGH 7.1
- TI-2026-76853 filelock soft locks adopt directories created by other local users CVSS 3.1MEDIUM 6.3
- TI-2026-76859 Symlink following in filelock ReadWriteLock redirects SQLite database CVSS 3.1MEDIUM 6.1
- TI-2026-76857 Unsafe holder record refresh in filelock SoftReadWriteLock CVSS 3.1MEDIUM 6.1
- TI-2026-76852 filelock UnixFileLock truncates files placed on the lock path CVSS 3.1MEDIUM 6.1
- TI-2026-76856 Crafted lock database makes filelock ReadWriteLock acquisitions hang CVSS 3.1MEDIUM 5.5
Sources
- CVE-2026-112937 · CVE Program
- CVE-2026-112937 · NVD
- FIRST EPSS
- GHSA-jqc4-5cvw-7w85 · GitHub Advisory Database · CC BY 4.0
- CVE-2026-112937 · Red Hat security data · CC BY 4.0
This product uses the NVD API but is not endorsed or certified by the NVD. Sources and licences