CVE-2026-25628: Qdrant Path Traversal Vulnerability

CVE-2026-25628 Overview

CVE-2026-25628 is a path traversal vulnerability in Qdrant, a popular vector similarity search engine and vector database. The vulnerability exists in versions 1.9.3 through 1.15.x and allows attackers with minimal (read-only) access to append arbitrary content to files on the target system by exploiting the /logger endpoint with an attacker-controlled on_disk.log_file path parameter.

This vulnerability is classified as CWE-73 (External Control of File Name or Path), which occurs when an application uses external input to construct a pathname that should be within a restricted directory, but fails to properly neutralize elements that can cause the pathname to resolve to a location outside of that restricted directory.

Critical Impact

Attackers with minimal privileges can append data to arbitrary files on the server, potentially leading to configuration tampering, log poisoning, or establishing persistence mechanisms through file manipulation.

Affected Products

• Qdrant versions 1.9.3 through 1.15.x
• Qdrant vector database deployments with the /logger API endpoint accessible
• Systems running vulnerable Qdrant instances with network-exposed service APIs

Discovery Timeline

• February 6, 2026 - CVE-2026-25628 published to NVD
• February 6, 2026 - Last updated in NVD database

Technical Details for CVE-2026-25628

Vulnerability Analysis

The vulnerability resides in Qdrant's logger configuration API, specifically in the /logger endpoint implementation within src/actix/api/service_api.rs. The endpoint originally lacked proper access control validation and path restrictions, allowing users with only read-only access to specify arbitrary file paths through the on_disk.log_file configuration parameter.

When a malicious request is processed, the application opens the specified file path in append mode without validating whether the path is within an allowed directory or whether the user has appropriate write permissions. This enables attackers to write log data to any file accessible to the Qdrant process on the filesystem.

The exploitation requires network access to the Qdrant API and only minimal authentication privileges (read-only access), making it relatively easy to exploit in environments where Qdrant is exposed to untrusted networks or users.

Root Cause

The root cause is insufficient access control on the /logger API endpoints combined with a lack of path validation for the on_disk.log_file parameter. The original implementation allowed any authenticated user to modify logger configuration including the log file destination, without verifying that:

1. The user has appropriate write-level permissions
2. The specified file path is within an allowed logging directory
3. The path does not traverse outside of intended boundaries

Attack Vector

The attack is network-based and requires only low-privilege (read-only) authenticated access to the Qdrant API. An attacker can exploit this vulnerability by:

1. Authenticating to the Qdrant instance with minimal read-only credentials
2. Sending a POST request to the /logger endpoint with a crafted log_file path pointing to a sensitive system file
3. The Qdrant service opens the specified file in append mode and writes log data to it
4. The attacker can potentially corrupt configuration files, poison logs, or achieve code execution through file manipulation

The following patch shows the security fix implemented to restrict the /logger API:

 }
 
 #[get("/logger")]
-async fn get_logger_config(handle: web::Data<tracing::LoggerHandle>) -> impl Responder {
+async fn get_logger_config(
+    ActixAccess(access): ActixAccess,
+    handle: web::Data<tracing::LoggerHandle>,
+) -> impl Responder {
     let timing = Instant::now();
-    let result = handle.get_config().await;
-    helpers::process_response(Ok(result), timing, None)
+
+    let future = async {
+        let _ = access.check_global_access(AccessRequirements::new())?;
+        let config = handle.get_config().await;
+        Ok(config)
+    };
+
+    helpers::process_response(future.await, timing, None)
 }
 
 #[post("/logger")]
 async fn update_logger_config(
+    ActixAccess(access): ActixAccess,
     handle: web::Data<tracing::LoggerHandle>,
-    config: web::Json<tracing::LoggerConfig>,
+    mut config: web::Json<tracing::LoggerConfig>,
 ) -> impl Responder {
     let timing = Instant::now();

Source: GitHub Qdrant Commit

Detection Methods for CVE-2026-25628

Indicators of Compromise

• Unusual POST requests to the /logger endpoint from unexpected sources or users
• Log file paths containing directory traversal sequences (../) or pointing to sensitive system files
• Unexpected modifications to system configuration files or application logs
• Authentication logs showing read-only users attempting to modify logger configurations

Detection Strategies

• Monitor API access logs for requests to /logger endpoints with suspicious log_file parameters
• Implement file integrity monitoring on critical system files to detect unauthorized modifications
• Deploy network-based detection rules to identify requests containing path traversal patterns targeting the logger endpoint
• Review Qdrant audit logs for configuration changes initiated by low-privilege users

Monitoring Recommendations

• Enable detailed logging for all Qdrant API endpoints, particularly configuration-related APIs
• Implement alerting on file system changes in sensitive directories where Qdrant has write access
• Monitor for process behavior anomalies, such as the Qdrant process writing to unexpected file locations
• Use SentinelOne's behavioral AI to detect abnormal file access patterns from the Qdrant service

How to Mitigate CVE-2026-25628

Immediate Actions Required

• Upgrade Qdrant to version 1.16.0 or later immediately
• Review access control configurations to ensure only trusted administrators can access the logger API
• Audit recent API logs for any exploitation attempts targeting the /logger endpoint
• Restrict network access to Qdrant's management APIs using firewall rules or network segmentation

Patch Information

The vulnerability is fixed in Qdrant version 1.16.0. The patch implements proper access control checks on the /logger endpoint and restricts the ability to specify log file paths via API requests. According to the fix, the log file can now only be specified in the configuration file, preventing runtime manipulation through the API.

For detailed patch information, refer to the GitHub Security Advisory GHSA-f632-vm87-2m2f and the security commit.

Workarounds

• Restrict access to the /logger endpoint using a reverse proxy or API gateway with strict authentication requirements
• Implement network-level access controls to limit which hosts can reach Qdrant's service APIs
• Run Qdrant with minimal filesystem permissions to limit the impact of arbitrary file writes
• Deploy Qdrant in a containerized environment with restricted filesystem access and read-only root filesystems where possible

# Example: Restrict Qdrant API access with iptables
# Only allow localhost and trusted management hosts to access the API
iptables -A INPUT -p tcp --dport 6333 -s 127.0.0.1 -j ACCEPT
iptables -A INPUT -p tcp --dport 6333 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 6333 -j DROP