CVE-2026-7846
Time-of-Check Time-of-Use in Langchain-Chatchat
Publication date: 2026-05-05
Last updated on: 2026-05-05
Assigner: VulDB
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| chatchat | langchain-chatchat | to 0.3.1.3 (inc) |
| chatchat-space | langchain-chatchat | to 0.3.1.3 (inc) |
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-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
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
The provided information does not specify any direct impact of this vulnerability on compliance with common standards and regulations such as GDPR or HIPAA.
Can you explain this vulnerability to me?
CVE-2026-7846 is a silent file overwrite vulnerability in Langchain-Chatchat versions up to 0.3.1.3. It occurs in the OpenAI-Compatible File Upload API, specifically in the file libs/chatchat-server/chatchat/server/api_server/openai_routes.py. The vulnerability arises because the application constructs file paths deterministically using the file's purpose, date, and user-supplied filename without any conflict detection, deduplication, or per-user isolation.
This leads to a time-of-check to time-of-use (TOCTOU) race condition where if two users upload files with the same name on the same day, the second upload silently overwrites the first without warning or protection. The vulnerable code writes files directly without checking for existing files, allowing an attacker to replace legitimate files with malicious content.
An attacker can exploit this by uploading a file with the same name as a victim's file, causing the victim's file to be overwritten. This can result in the vision language model (LLM) fetching attacker-controlled images instead of the original uploads during image_url callbacks.
How can this vulnerability impact me? :
This vulnerability can impact you by allowing an attacker to silently overwrite files you upload if they use the same filename on the same day. This means your legitimate files can be replaced with malicious content without your knowledge.
The main impact is LLM input poisoning, where the vision chat system processes attacker-controlled images instead of your original uploads. This can lead to incorrect or malicious outputs from the system.
Additionally, the attack is stealthy because the frontend preview may still show the correct image, while the LLM fetches the replaced malicious file, making detection difficult.
Exploitation requires access to the local network and is considered difficult due to the high complexity of the attack.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
This vulnerability can be detected by monitoring file uploads to the /v1/files endpoint and checking for silent overwrites of files with the same filename uploaded on the same day.
Specifically, detection involves verifying if files are being overwritten without warning or conflict detection, which can be done by comparing file hashes or timestamps for files with identical names uploaded by different users.
Commands to help detect this issue might include:
- Using file system commands to check for multiple uploads with the same filename and different content, e.g., `ls -l` and `stat` to check timestamps and file sizes.
- Using hash commands like `sha256sum` or `md5sum` on files in the upload directory to detect if files with the same name have different hashes over time.
- Monitoring application logs for multiple uploads of files with the same name on the same day.
Since the vulnerability involves a race condition in file writes, network detection might be difficult, but monitoring for suspicious repeated uploads with identical filenames from different users could help.
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include preventing filename collisions by modifying the file storage logic to include a unique identifier in the file path.
Specifically, the suggested fix is to update the `_get_file_id()` function to append a random UUID to the file path, ensuring that files uploaded with the same name do not overwrite each other.
Additionally, implementing conflict detection, deduplication, or per-user isolation in file storage can help prevent silent overwrites.
Until a patch is applied, restricting access to the vulnerable endpoint and monitoring uploads for suspicious activity may reduce risk.