CVE-2026-112937: 
Python vulnerability analysis and mitigation

CVE-2026-112937 is a Time-of-Check Time-of-Use (TOCTOU) race condition in the filelock Python library (maintained by tox-dev) that allows a local attacker to cause the ReadWriteLock or AsyncReadWriteLock to recursively delete an arbitrary directory owned by the victim user. It affects filelock versions 4.1.0 through 4.2.0 (inclusive) and was fixed in version 4.2.1. The vulnerability was reported by Anthropic's OSS Scanner on October 15, 2026, and publicly disclosed on October 20, 2026. It carries a CVSS v3.1 base score of 6.1 (Medium) (GitHub Advisory GHSA-jqc4-5cvw-7w85, Feedly).

The root cause is CWE-367 (TOCTOU Race Condition): when ReadWriteLock operates on the hard-link route (used on macOS since version 4.1.1, and on any POSIX system where /proc/self/fd/ is unavailable, such as a chroot or container without /proc), it creates a randomized .filelock-* private directory via mkdtemp and later removes it using shutil.rmtree on the remembered path — without verifying that the path still refers to the directory it originally created. A local attacker with write permission on the non-sticky parent directory can perform two rename() calls: first moving the legitimate .filelock-* directory aside, then renaming a victim-owned sibling directory onto the vacated .filelock-* name. When the lock user's process releases the lock (or during the dead-owner sweep on the next lock construction), shutil.rmtree deletes the attacker-substituted directory — which is actually the victim's data — with the victim's own permissions and no error. A second attack vector (the dead-owner sweep) requires only one rename call and no held lock: the attacker forges a .filelock-* name with a dead PID and the host digest (computable by any local user when /proc is absent), causing the next ReadWriteLock construction in that directory to sweep and delete the renamed victim directory. Stock Linux with /proc mounted is not affected (GitHub Advisory GHSA-jqc4-5cvw-7w85, Fix PR #834).

A local attacker can cause the victim user's process to recursively delete an arbitrary directory tree — including files the attacker could not otherwise remove — with the victim's permissions, while the victim's process reports success and no error. The primary impact is high integrity loss (destruction of the victim's data) and partial availability loss (the victim's application silently loses its data). There is no confidentiality impact, as the attacker does not gain read access to the victim's files. The attack is particularly dangerous in shared build, cache, or CI environments where lock databases reside in world-writable directories without the sticky bit (GitHub Advisory GHSA-jqc4-5cvw-7w85).

No public exploit code or in-the-wild exploitation has been reported. The EPSS score is 0.0 and the vulnerability is not listed in the CISA KEV catalog. The attack requires a local account on the same host and write access to a non-sticky shared parent directory containing the lock database — conditions common in multi-user build or CI environments. Notably, the release variant requires no race against filelock's own code; two rename() calls at any point during the lock hold are sufficient. The dead-owner sweep variant requires only one rename and no held lock, making it particularly easy to trigger (GitHub Advisory GHSA-jqc4-5cvw-7w85, Feedly).

1. Identify a vulnerable environment: Confirm the target system runs filelock 4.1.0–4.2.0 on macOS, or on a POSIX system where /proc/self/fd/ is unavailable (e.g., a container or chroot without /proc mounted). Identify a shared directory without the sticky bit (e.g., a 0777 or group-writable cache/build directory) that contains a ReadWriteLock database.
2. Identify the target directory: Choose a victim-owned directory (e.g., victim_project/) that resides as a sibling of the lock database in the shared parent directory. The attacker needs only write permission on the parent, not on the victim's directory itself.
3. Wait for or trigger lock acquisition (release variant): Wait until the victim process acquires the ReadWriteLock (a .filelock-* directory will appear in the shared parent). Alternatively, for the sweep variant, proceed without waiting for a held lock.
4. Execute the rename attack (release variant): As the attacker, run two rename() calls: (a) rename('.filelock-PID--DIGEST-XXXX', 'moved-aside') to move the legitimate link directory aside, then (b) rename('victim_project', '.filelock-PID--DIGEST-XXXX') to place the victim's directory at the link directory's name.
5. Trigger deletion (release variant): Wait for the victim process to exit its with lock.write_lock(): block. The shutil.rmtree call in release() deletes victim_project and all its contents with the victim's permissions. The victim process exits with status 0 and reports no error.
6. Alternative — dead-owner sweep variant: Compute the host digest as hashlib.sha256(socket.gethostname().encode()).hexdigest()[:16]. Rename the victim's directory to .filelock-2147483647---<digest>-x (using a PID above the OS limit, ensuring it appears dead). The next time any process constructs a ReadWriteLock in that directory on the link route, the sweep deletes the renamed victim directory automatically (GitHub Advisory GHSA-jqc4-5cvw-7w85).

• File System: Unexpected disappearance of directories in shared parent directories (e.g., build caches, project directories) that previously existed and were owned by a different user; presence of a moved-aside/ directory or similar renamed artifact in the shared parent alongside the lock database; .filelock-* directories with forged names (e.g., containing very large PIDs like 2147483647) in shared directories.
• Logs: Python application logs showing successful lock release (exit status 0) despite missing expected output files or directories; RecursionError in Python 3.11 applications using ReadWriteLock in a shared directory (indicating the sweep variant with a deeply nested forged directory).
• Process: Unexpected rename() system calls on .filelock-* directories observed via strace/auditd from a process running as a different user than the lock owner; shutil.rmtree activity on directories not owned by the calling process.

Upgrade filelock to version 4.2.1, which fixes this vulnerability by removing link directories through a checked file descriptor (verifying fstat identity matches the created directory) rather than by path name, and by restricting the dead-owner sweep to only parse directories owned by the locking account (filelock 4.2.1 Release, Fix PR #834). As a workaround for those unable to upgrade immediately: on macOS and POSIX systems without /proc, keep the ReadWriteLock database in a directory writable only by the locking account (no group or other write bits, and no sticky-bit-less shared parent). Do not place ReadWriteLock databases in 0777 or group-writable directories shared with other accounts, and do not keep valuable sibling directories beside a lock database in such shared locations (GitHub Advisory GHSA-jqc4-5cvw-7w85).

The vulnerability was reported by Anthropic's OSS Scanner (automated analysis) on October 15, 2026, and the maintainer (gaborbernat) opened a fix PR (#834) within hours of receiving the report. The advisory was published on October 17, 2026, alongside the patched release 4.2.1. No significant broader community or media reactions have been identified beyond the GitHub advisory and fix (GitHub Advisory GHSA-jqc4-5cvw-7w85).