Qdrant API key

ID

qdrant_apikey

Severity

high

Remediation Complexity

trivial

Remediation Risk

high

Remediation Effort

low

Vendor

Qdrant

Family

API Token

Description

Qdrant is an open-source vector database, offered as a managed service by Qdrant Cloud. Clusters authenticate clients with an API key sent in the api-key header.

Qdrant API keys are opaque: they carry neither a vendor prefix nor a fixed length. This detector therefore combines the variable name with a minimum length and a minimum entropy, and reports at medium confidence. Nothing in the value identifies the vendor, so this detector also requires the variable name to name the service. A key passed under an unrelated name is reported by the generic API key detectors instead.

Qdrant also issues JWT-based database keys with granular access control; those start with eyJ and are reported by the jwt detector.

When the cluster endpoint appears in the same file, it is used to check whether the key is live; a confirmed live key is escalated to critical.

Security

A leaked Qdrant key grants an attacker the same access as the application that owns it:

  • Unauthorized usage is billed to your account, and automated high-volume calls can run up a large charge before anyone notices.

  • Whatever is sent through the leaked key — prompts, documents, query results — is exposed to whoever holds it.

  • The key can read, modify or delete the vectors and metadata in the index. Those usually hold embedded copies of proprietary documents or personal data, so the leak is a data-exfiltration path and not only a billing problem.

  • The key does not expire on its own, so the exposure lasts until it is revoked.

Examples

The following is a leak of a Qdrant key:

QDRANT_URL=https://my-cluster.eu-central-1.aws.cloud.qdrant.io
QDRANT_API_KEY=gA3ILuZFaOlN...UIi4Bq1

Mitigation / Fix

  1. Follow your policy for handling leaked secrets, which normally requires revoking the key. Go to [Qdrant Cloud > Cluster > API Keys], delete the leaked key and create a new one. For a self-hosted deployment, change service.api_key in the configuration and restart the node.

    Revoke the leaked key, do not merely disable it.

  2. Remove the leaked key from the source code or committed configuration file, and replace its usages with the new value. Environment variables, local files or secret vaults could be used for passing the key, instead of hardcoding the value, as documented in How to Prevent Hard-Coded Secrets.

  3. Review the usage and audit logs for the key, to confirm that it was not used by unintended actors while it was exposed.

  4. Apply the usual precautions for API keys: never commit them, pass them through environment variables or a secret manager, use a separate key per environment, monitor usage for unusual spikes, and rotate them periodically.

You should consider any sensitive data in commits with secrets as compromised.

Remember that secrets may be removed from history in your projects, but not in other users' cloned or forked repositories.

Reference