CVE-2026-25628
Arbitrary File Append in Qdrant Logger via Path Injection
Publication date: 2026-02-06
Last updated on: 2026-02-19
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| qdrant | qdrant | From 1.9.3 (inc) to 1.16.0 (inc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-73 | The product allows user input to control or influence paths or file names that are used in filesystem operations. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
CVE-2026-25628 is a vulnerability in Qdrant, a vector similarity search engine and vector database, affecting versions from 1.9.3 to before 1.16.0. It allows an attacker with minimal privileges (read-only access) to append arbitrary content to files on the server by exploiting the `/logger` HTTP endpoint. This endpoint accepts a parameter `on_disk.log_file` that specifies the log file path, which was not properly restricted, enabling attackers to write to arbitrary files.
The attack involves setting the log file path to a critical configuration file (e.g., `config/local.yaml`) and injecting malicious YAML payloads via other API endpoints. When Qdrant restarts, it loads the malicious configuration, allowing attackers to override settings, read arbitrary files, escalate privileges, and even execute arbitrary code remotely.
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'Detection of this vulnerability involves checking if your Qdrant instance is running a vulnerable version (>= 1.9.3 and < 1.16.0) and if the /logger endpoint is accessible and allows modification of the on_disk.log_file path without proper access control.'}, {'type': 'paragraph', 'content': 'You can attempt to detect unauthorized access by sending controlled requests to the /logger endpoint to see if the log_file path can be set or modified via POST requests without management privileges.'}, {'type': 'paragraph', 'content': 'Example commands to test this might include using curl to query or update the logger configuration:'}, {'type': 'list_item', 'content': 'Check current logger configuration (GET request):\ncurl -X GET http://<qdrant-host>:<port>/logger'}, {'type': 'list_item', 'content': 'Attempt to update the log file path (POST request) without proper privileges:\ncurl -X POST http://<qdrant-host>:<port>/logger -H "Content-Type: application/json" -d \'{"on_disk": {"log_file": "config/local.yaml"}}\''}, {'type': 'paragraph', 'content': 'If the POST request succeeds in changing the log_file path, the system is vulnerable. Monitoring logs for unexpected changes or attempts to write to configuration files via the logger endpoint can also help detect exploitation attempts.'}] [1, 3]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include upgrading Qdrant to version 1.16.0 or later, where the vulnerability is fixed by enforcing strict access control on the /logger endpoint.
If upgrading is not immediately possible, restrict access to the /logger endpoint to only users with management privileges or disable the endpoint entirely to prevent unauthorized modifications.
Additionally, ensure that the log file path is limited to a dedicated logs directory and cannot be set arbitrarily via the API.
Review and tighten permissions on the Qdrant configuration directory to prevent unauthorized writes, and monitor for suspicious activity involving the /logger endpoint.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability impact me? :
This vulnerability can have severe impacts including remote code execution (RCE) with low privileges, full compromise of confidentiality, integrity, and availability of the affected system. An attacker can inject malicious configuration files, escalate privileges, read sensitive files such as `/etc/passwd`, and execute arbitrary commands on the host.
The exploitation requires a writable configuration directory and a restart of the Qdrant service, but no user interaction is needed. The scope of the attack extends beyond the vulnerable endpoint, potentially affecting the entire system running Qdrant.