Qdrant disclosed that its distributed deployments can expose an unauthenticated internal interface even when the public API requires a key. Version 1.20.0 changes the authentication default, but operators must still configure an API key and isolate peer traffic.

Qdrant is a database for similarity search. Cluster nodes exchange data and coordinate their state through an internal gRPC interface, a service-to-service communication protocol, on port 6335 by default.

Who is exposed

The October 22 advisory, GHSA-frc7-44gm-99qq, lists versions before 1.20.0 as affected. Exposure requires distributed mode, with cluster.enabled: true, and network access to the internal listener. Single-node deployments do not start that listener.

Before 1.20.0, internal authentication was disabled by default. The listener shared the public API’s bind address unless the operator changed the configuration. A key protecting application requests therefore did not necessarily protect cluster operations.

Qdrant says an unauthenticated caller reaching that port could arrange to receive replicated data, modify cluster state or exhaust node memory. These are the vendor’s documented impacts, not a measured count of compromised databases.

Exploitation status: vendor-confirmed vulnerability; the reviewed advisories do not report attacks exploiting it. The advisory has no assigned CVE. Its GitHub advisory identifier is the stable reference.

Upgrade and configure together

The security documentation confirms an important condition: without an API key, enabling internal enforcement installs no authentication layer. Upgrading alone does not secure a keyless cluster.

  • Restrict port 6335 to the cluster’s own nodes. Apply that boundary inside the private network too. Application servers that need the public API should not automatically reach the peer interface.
  • Upgrade through the supported minor-version sequence to 1.20.0 or a later fixed release. Qdrant says mixed 1.19/1.20 clusters support rolling upgrades because 1.19 peers already attach the key.
  • Configure the same admin API key on every peer and keep service.enforce_internal_auth enabled. The setting exists from 1.18.0; earlier releases need an upgrade rather than that configuration-only workaround.
  • Encrypt internal traffic. Qdrant recommends cluster.p2p.enable_tls: true so peers do not send the key in plaintext. TLS encrypts and authenticates connections.
  • Separate the internal bind address where supported. From 1.19.2, cluster.p2p.host can select an internal IP; the advertised peer URI must match it.

For an already exposed cluster, closing the listener and updating are containment steps. They do not establish whether data was accessed during the earlier exposure window.

An older key-authorization flaw also matters

GHSA-3gph-6c29-p29v, published October 5, covers a separate flaw in 1.18.0 through versions before 1.19.2. With internal enforcement enabled, those versions still accepted read-only keys and JSON Web Tokens, signed access tokens, for privileged cluster operations.

1.19.2 fixed that acceptance rule. It did not enable internal authentication by default; 1.20.0 supplies that later change. Treat these as two related fixes, not interchangeable version numbers.

Qdrant says its managed Cloud clusters restrict peer ingress to the same cluster and are not materially affected. Hybrid and Private Cloud depend on the customer’s network-policy enforcement. Qdrant develops the database and sells those managed services; these deployment assurances come from the vendor.

Caveat: 1.20.0 does not add an internal message-size limit, so network isolation and protection of the admin key remain important after authentication is enabled.