CVE-2025-68146: 
Python vulnerability analysis and mitigation

CVE-2025-68146 is a Time-of-Check-Time-of-Use (TOCTOU) race condition vulnerability in the filelock Python library that allows local attackers to corrupt or truncate arbitrary user files via symlink attacks during lock file creation. It affects all versions of filelock prior to 3.20.1 on Unix, Linux, macOS, and Windows systems. The vulnerability was discovered by George Tsigourakos (@tsigouris007) and disclosed on December 15–16, 2025, with a fix released the same day. It carries a CVSS v3.1 base score of 6.5 (Medium) per Feedly/NVD, though the GitHub Security Advisory rates it 6.3 (Moderate) (GitHub Advisory, Feedly).

The root cause is a classic TOCTOU race condition (CWE-367) combined with improper symlink resolution (CWE-59) and a race condition (CWE-362). On Unix/Linux/macOS, UnixFileLock._acquire() in src/filelock/_unix.py checks whether the lock file exists via Path(self.lock_file).exists() and then opens it with os.O_RDWR | os.O_TRUNC — without the O_NOFOLLOW flag — creating a race window of ~1–5 microseconds during which an attacker can replace the lock path with a symlink pointing to a victim file. On Windows, WindowsFileLock._acquire() similarly opens the file with O_TRUNC without first checking for reparse points (symlinks/junctions). When os.open() is called, the kernel follows the symlink using the victim process's own permissions and truncates the target file to zero bytes. The fix in version 3.20.1 adds O_NOFOLLOW to the Unix os.open() call and uses GetFileAttributesW to detect and reject reparse points on Windows before opening (GitHub Advisory, Fix Commit).

Successful exploitation allows a local attacker with standard user permissions (no elevated privileges required on Unix; Developer Mode required on Windows 10+) to truncate arbitrary files accessible to the victim process, resulting in high integrity and availability impact. Affected files can include SSH configuration files, shell profiles, virtualenv configuration (leaking sensitive path information), PyTorch model checkpoints (causing ML pipeline failures), and any other file reachable via a predictable lock file path. The vulnerability cascades to all libraries that depend on filelock, including virtualenv, PyTorch, poetry, and tox, significantly broadening the attack surface. Confidentiality impact is limited but non-zero, as virtualenv metadata written to overwritten files can leak file paths and Python version information (GitHub Advisory).

A proof-of-concept exploit is publicly available via the GitHub Security Advisory, demonstrating success rates of 33% per attempt for a simple direct attack (average 2.1 attempts) and ~90% on the first attempt for a weaponized virtualenv attack. Exploitation requires only local filesystem access and the ability to create symlinks — standard capabilities for any unprivileged Unix user. The EPSS score is 0.000150 (very low probability of widespread exploitation), and there is no evidence of in-the-wild exploitation or CISA KEV catalog listing as of the time of this report. No threat actor attribution has been identified (GitHub Advisory, Feedly).

1. Reconnaissance: Identify a target application that uses filelock (e.g., virtualenv, PyTorch, tox) and determine the predictable lock file path it creates (e.g., /tmp/myapp.lock or /home/victim/.cache/torch/cpu_isa_check.lock).
2. Identify victim file: Select a high-value target file owned by the victim user that the attacker wants to truncate (e.g., /home/victim/.ssh/config, /home/victim/.bashrc, or a PyTorch model checkpoint).
3. Set up race loop: In a tight loop, remove any existing lock file at the target path (os.unlink(lock_path)) and immediately create a symlink pointing to the victim file (os.symlink(victim_file, lock_path)). This loop runs continuously to maximize the chance of hitting the race window.
4. Trigger victim application: Cause or wait for the victim application to call lock.acquire() on the predictable lock path. The race window between Path(self.lock_file).exists() and os.open(..., O_TRUNC) is ~1–5 microseconds.
5. Exploit: When the timing aligns, os.open() follows the attacker-placed symlink and truncates the victim file to 0 bytes using the victim process's own permissions — no write access to the victim file is required by the attacker.
6. Achieve objective: The victim file is now empty, causing application crashes, data loss, or information leakage (e.g., virtualenv metadata written to the truncated file reveals Python version and system paths) (GitHub Advisory, Fix PR).

• File System: Unexpected symlinks in lock file directories (e.g., /tmp/*.lock pointing to user home directory files); lock files with zero-byte size where content is expected; files such as ~/.ssh/config, ~/.bashrc, or PyTorch cache files (~/.cache/torch/*.lock) unexpectedly truncated to 0 bytes.
• Process: Rapid creation and deletion of symlinks in shared directories (e.g., /tmp) by a non-root process; unusual file descriptor activity on lock paths from processes that should not be accessing them.
• Logs: Application crash logs or errors referencing corrupted configuration files or missing model checkpoints; Python tracebacks from virtualenv, PyTorch, or tox indicating empty or malformed lock/config files; OS-level audit logs (e.g., Linux auditd) showing symlink() syscalls targeting lock file paths followed immediately by open() with O_TRUNC from a different process.

Upgrade filelock to version 3.20.1 or later immediately — this is the only complete remediation. The fix adds O_NOFOLLOW to os.open() on Unix (causing an ELOOP error if the lock path is a symlink) and uses GetFileAttributesW to detect and reject reparse points on Windows before opening. If immediate upgrade is not possible, apply these partial mitigations: (1) use SoftFileLock instead of UnixFileLock/WindowsFileLock (note: different locking semantics); (2) restrict lock file directory permissions to chmod 0700 to prevent untrusted users from creating symlinks; (3) monitor lock file directories for suspicious symlinks. These workarounds do not fully eliminate the race condition. Downstream products from IBM (Watson Speech Services Cartridge, Cognos Analytics, Cloud Pak for Business Automation, Guardium Data Security Center, Instana, Business Automation Workflow), Oracle, and Microsoft have also issued advisories (GitHub Advisory, filelock 3.20.1 Release, IBM Watson Advisory, Oracle Advisory).

The vulnerability was disclosed by maintainer Bernát Gábor (@gaborbernat) on December 15, 2025, the same day the fix was merged and released, demonstrating a rapid coordinated disclosure. Multiple downstream vendors including IBM, Oracle, and Microsoft issued their own advisories acknowledging the impact on their products. The vulnerability received coverage from security aggregators including INCIBE-CERT, LinuxSecurity, and pro-linux.de, and was noted in a dev.to post highlighting its relevance to AI agent frameworks that depend on filelock. Ubuntu issued security notice USN-7999-1 addressing the issue in their distribution (GitHub Advisory, Ubuntu USN).