Qdrant's advisory GHSA-f632-vm87-2m2f, published on 5 February 2026 and tracked as CVE-2026-25628, describes an arbitrary file append through the /logger endpoint. The record was still being updated in August 2026, and the version boundary differs between sources, which makes it a good test of whether your vector database is on anyone's patch list. The details also expose a habit common in RAG stacks: the vector store is treated as internal plumbing, not as a server that takes requests from many callers.
What's affected
- Qdrant, versions from 1.9.3. The GitHub advisory says patched in 1.15.6. The NVD description says fixed in 1.16.0. Upgrade to 1.16.0 or later and both statements are satisfied.
- The flaw.
POST /loggeraccepts an attacker-controlledon_disk.log_filepath, so a caller can append to arbitrary files. Read-only access is enough. The endpoint requires authentication but performs no authorization check. - Impact. The advisory lists overwriting configuration, reading files through the web UI in container deployments, and potentially privilege escalation. Its impact section says remote code execution. CVSS is 8.5, weakness CWE-73.
- Not affected. Qdrant Cloud, because its configuration directory is not writable.
How to check if you're exposed
Find the version and who can reach the service:
curl -s http://localhost:6333/ | grep -o '"version":"[^"]*"'
kubectl get pods -A -o jsonpath='{range .items[*]}{.spec.containers[*].image}{"\n"}{end}' | grep -i qdrant
Then check whether the API is reachable from places it should not be, and whether your application uses an admin key where a narrower one would do. A key that only reads vectors still counts as an authenticated user for this bug.
What to do now
- Upgrade Qdrant to 1.16.0 or later.
- Until then, restrict
/loggerto management users or disable it at the proxy, and limit the log file path to a dedicated logs directory, as the advisory suggests. - Keep the vector store off public networks. Only the retrieval service should reach it.
- Use separate keys for the retrieval service and for administration. Qdrant supports an API key and a read-only key through its service configuration.
- Make the container filesystem read-only except for the storage volume.
How this could have been avoided
- Authorization on every route, not just authentication. The endpoint checked who you were and not what you were allowed to do. Review any admin-style route in your own services for the same gap.
- Network isolation. A vector store reachable only from the retrieval service turns a low-privilege bug into a non-event for outsiders.
- A non-writable configuration directory. This is exactly why Qdrant Cloud was not affected. Copy the idea in self-hosted deployments with read-only root filesystems.
- Version inventory. If vector databases are not in your SBOM and patch process, a February advisory can sit unread until August.
The rest of the pipeline
The vector store is one stage. OWASP's 2026 LLM Top 10 lists Vector and Embedding Weaknesses as LLM09 and Data and Model Poisoning as LLM05, and the fixes line up with pipeline stages.
| Stage | Question | Control |
|---|---|---|
| Ingestion | Who can add documents? | Restrict writers. Record source and author for every chunk. |
| Parsing | What does the parser trust? | Run parsers in a sandbox with no credentials. Pin versions. |
| Indexing | Does each chunk carry access rules? | Store tenant and ACL metadata with the vector. |
| Retrieval | Where is the access check? | Apply the filter inside the vector query, not after results return. |
| Prompting | What can retrieved text do? | Treat it as data. Never let it change tool permissions. |
| Output | Can users trace an answer? | Return citations and log which chunks were used. |
The retrieval row is the one that fails most often. If you fetch the top ten chunks and then drop the ones the user cannot see, one missed code path leaks data, and the user gets fewer useful answers than expected.
Why it matters
RAG gives an LLM a second place to take instructions from: the documents. Anyone who can write to a wiki, a ticket queue or a shared drive that you index can speak to the model. That makes the write path to your corpus part of your security boundary.
The Qdrant bug is a reminder that the storage layer is software with its own advisories. Attackers do not have to trick the model if they can reach the database.
Quick check
Why is a read-only API key not enough protection for this bug?
The advisory says minimal privileges are required, and read-only access suffices. The /logger endpoint authenticated the caller but did not check authorization, so even a low-privilege key could append to files.
Where should a tenant filter be applied in retrieval?
Inside the vector query itself, so unauthorized chunks are never returned to the application, rather than filtered out afterward.
