Critical Qdrant vulnerability allows unauthenticated access to clusters

Qdrant, an open-source vector database, disclosed a security flaw affecting distributed deployments where peers communicate over an internal gRPC API on port 6335. Before version 1.20.0, this port did not require authentication by default, even though the operator could enable service.enforce_internal_auth since version 1.18.0.

The vulnerability, reported by Davi Ottenheimer of Ottenheimer GmbH and independently by @zerovulnlabs, was received by Qdrant via CERT-Bund on 21 September 2026. It was independently reported through GitHub's private vulnerability reporting system.

An attacker with network access to port 6335 could call AddPeerToKnown and add a peer of their choice to the cluster. This would allow them to receive replicated shards, granting read access to stored data.

They could also send Raft messages that the consensus state machine processes without a sender check, allowing modification of cluster state, including collections and shard placement. Additionally, they could send unbounded messages to internal services and exhaust memory on the node.

Single-node deployments are not affected as they do not start the internal port. The internal listener binds to the same address as the public API, so the port is reachable wherever the public API is reachable, unless the network prevents it.

Fix and workarounds

From version 1.20.0, service.enforce_internal_auth defaults to enabled, requiring an API key to access the internal port. A distributed deployment with no API key remains unauthenticated on the internal port and logs a warning at startup since version 1.19.2.

Qdrant Cloud, which runs with a NetworkPolicy enforced by Calico, is not materially affected. Hybrid Cloud and Private Cloud deployments depend on the customer's CNI for enforcement.

For versions before 1.20.0, users can restrict port 6335 to the nodes of the same cluster using a firewall, security group, or NetworkPolicy. On v1.18.0 or later, they can set the same api_key on every peer, enable service.enforce_internal_auth, and restart peers one at a time. Enabling TLS for internal communication is also recommended.