CVE-2025-68146
TOCTOU Race Condition in filelock Allows Local File Corruption
Publication date: 2025-12-16
Last updated on: 2026-03-05
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| tox-dev | filelock | to 3.20.1 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-362 | The product contains a concurrent code sequence that requires temporary, exclusive access to a shared resource, but a timing window exists in which the shared resource can be modified by another code sequence operating concurrently. |
| CWE-59 | The product attempts to access a file based on the filename, but it does not properly prevent that filename from identifying a link or shortcut that resolves to an unintended resource. |
| CWE-367 | The product checks the state of a resource before using that resource, but the resource's state can change between the check and the use in a way that invalidates the results of the check. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2025-68146 is a Time-of-Check-Time-of-Use (TOCTOU) race condition vulnerability in the filelock Python library before version 3.20.1. It occurs during lock file creation where the software first checks if a lock file exists and then opens it with truncation. An attacker with local filesystem access can create a symbolic link (symlink) pointing to an arbitrary victim file in the gap between the check and open operations. When the lock file is opened, the symlink is followed, causing the victim file to be truncated or corrupted. This affects Unix, Linux, macOS, and Windows systems and can lead to data loss or corruption. The vulnerability also impacts dependent libraries like virtualenv and PyTorch, causing issues such as configuration file overwrites, data leakage, application crashes, or denial of service. The issue was fixed by preventing the open call from following symlinks (using O_NOFOLLOW on Unix and reparse point checks on Windows). [1, 4]
How can this vulnerability impact me? :
This vulnerability can lead to corruption or truncation of arbitrary user files on affected systems. An attacker with local access and the ability to create symlinks can exploit this to overwrite or destroy important files without needing write access to those files. For example, in dependent projects like virtualenv, user configuration files can be overwritten with metadata, potentially leaking sensitive information. In PyTorch, it can corrupt CPU ISA caches or compiled model checkpoints, causing application crashes or denial of service in machine learning pipelines. Overall, it can cause data loss, application instability, and denial of service. [1, 4]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring the lock file directories for suspicious symbolic links (symlinks) or reparse points before running trusted applications. On Unix-like systems, you can use commands like `find /path/to/lockdir -type l` to list symlinks in the lock file directories. On Windows, you can use PowerShell commands to detect reparse points, for example: `Get-ChildItem -Path C:\path\to\lockdir -Recurse | Where-Object { $_.Attributes -band [IO.FileAttributes]::ReparsePoint }`. These commands help identify unexpected symlinks or junctions that could be exploited. Additionally, reviewing lock file paths for predictability and unexpected changes can help detect attempts to exploit the race condition. [4]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include: 1) Upgrading the filelock package to version 3.20.1 or later, which contains the fix preventing symlink following during lock file creation. 2) If upgrading is not immediately possible, use SoftFileLock instead of UnixFileLock or WindowsFileLock, noting that this has different locking semantics and may not suit all use cases. 3) Restrict permissions on lock file directories to be accessible only by trusted users (e.g., chmod 0700 on Unix) to prevent untrusted users from creating symlinks. 4) Monitor lock file directories for suspicious symlinks or reparse points and remove them before running trusted applications. These workarounds provide only partial mitigation, and upgrading is strongly recommended to fully address the vulnerability. [4]
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The provided resources do not explicitly discuss the impact of CVE-2025-68146 on compliance with common standards and regulations such as GDPR or HIPAA. However, the vulnerability allows local attackers to corrupt or truncate arbitrary user files through symlink attacks, potentially leading to data loss, data corruption, or unauthorized modification of files. Such impacts could indirectly affect compliance with data protection regulations that require data integrity and availability, but no direct statements or analyses regarding compliance are given in the provided text.