On November 13, 2025, security researchers at ByteDance's Volcengine team responsibly disclosed CVE-2025-64513, a critical vulnerability in Milvus that earned a CVSS score of 9.3. The flaw allowed unauthenticated attackers to bypass all authentication checks by manipulating a single HTTP header, granting full administrative access to Milvus clusters without credentials.
The Milvus maintainers deserve recognition for their rapid response—patches were released simultaneously with disclosure, and the team provided clear mitigation guidance for organizations unable to upgrade immediately. This is responsible vulnerability management done right.
But CVE-2025-64513 reveals something larger than a single authentication bug. It exposes a fundamental tension in how vector databases approach security: authentication controls who can access your data, but encryption determines what they can do with it once inside.
What Happened: The Technical Details
Milvus Proxy's authentication mechanism relied on validating a sourceId header to distinguish internal component requests from external client requests. The system base64-decoded this header value and compared it to a hardcoded constant: @@milvus-member@@. If the values matched, requests bypassed standard authentication entirely.
This trust-based validation worked as intended for internal components but created a security boundary that any attacker with network access could cross. The vulnerability affected Milvus versions 2.4.0–2.4.23, 2.5.0–2.5.20, and 2.6.0–2.6.4—essentially all production deployments prior to the November patches.
Attack complexity: Low. An attacker needed only network access and the ability to add a crafted HTTP header to requests.
Impact scope: Complete. Once inside, attackers could read, modify, or delete all vector embeddings, create or drop databases, and execute administrative commands across the entire cluster.
The Milvus team addressed the vulnerability in versions 2.4.24, 2.5.21, and 2.6.5 by removing trust-based header validation and requiring all requests to pass through standard authentication mechanisms. Organizations unable to patch immediately received guidance to filter the sourceId header at the gateway level—a pragmatic interim mitigation.
Why This Matters Beyond Milvus
CVE-2025-64513 follows a pattern we've seen across the vector database ecosystem: authentication and access control implementations designed for internal ML pipelines, then exposed to adversarial network environments without fundamental security architecture redesigns.
Vector databases evolved from research and internal-only machine learning workflows where network isolation served as the primary security boundary. As these systems scaled to production environments—cloud deployments, multi-tenant architectures, externally facing APIs—authentication became a feature addition rather than an architectural foundation.
The result? Organizations now run authentication-only security models protecting data that poses fundamentally different risks than traditional databases. Vector embeddings aren't hashed, aren't salted, and aren't one-way transformations—they're mathematically invertible representations of source data. The OWASP AI Security and Governance Checklist explicitly identifies embedding inversion attacks as LLM08:2025, recognizing that compromised vector databases can reveal the original sensitive data they were meant to protect.
The Authentication vs. Encryption Gap
Consider what CVE-2025-64513 actually exposed in a typical enterprise deployment:
Scenario 1: Healthcare RAG System
A hospital runs semantic search on patient records using Milvus. The vulnerability allowed an attacker to bypass authentication and access the vector database. With standard Milvus architecture, those embeddings exist in plaintext—in memory during queries, in logs recording operations, in backups stored for disaster recovery. The attacker now has mathematical representations of patient medical histories that can be reconstructed through inversion attacks.
Scenario 2: Financial Services Document Q&A
A bank embeds client financial documents for AI-powered analyst queries. CVE-2025-64513 gives an attacker admin access. Even after the authentication vulnerability is patched, the plaintext embeddings remain in database memory, admin console caches, and query logs. One compromised credential in the future—insider threat, phished admin, or another CVE—exposes the same data.
The patch fixed the authentication bypass. It didn't address what happens when authentication legitimately succeeds but the data inside remains vulnerable to reconstruction, exfiltration, or insider access.
The Architectural Lesson
The lesson from CVE-2025-64513 isn't "don't use Milvus"—it's that perimeter security models fundamentally don't match the threat landscape for AI data. Authentication vulnerabilities will always exist. Credentials will always be phished. Insiders will always have access. The question organizations need to answer isn't whether their authentication will be bypassed, but what adversaries can access once inside.
Traditional database security encrypts data at rest (on disk) and in transit (over the network). Vector databases need a third layer: encryption-in-use—ensuring embeddings remain cryptographically protected even during query execution in memory. This shifts the security model from "keep attackers out" to "limit what they can do when they get in."
That means moving toward zero-trust architectures where:
- Vector embeddings are encrypted before entering any database system
- Decryption happens only for the minimum necessary operations
- Encryption keys remain under customer control (BYOK/HYOK models)
- Logs, backups, and memory dumps contain ciphertext, not reconstructable data
- Authentication breaches become contained incidents rather than catastrophic exposures
This isn't theoretical. The OWASP AI Security and Governance Checklist explicitly identifies embedding inversion as a critical vulnerability class (LLM08:2025) because compromised vector databases can mathematically reconstruct the sensitive source data they were meant to protect.
The architectural direction is clear: defense-in-depth for AI infrastructure means layering authentication (who gets in) with cryptographic controls (what they can access) and customer-controlled key management (who can decrypt). That's the model we're building with CyborgDB—not as a replacement for systems like Milvus, but as cryptographic infrastructure that can protect vector data regardless of which database sits underneath.
What Organizations Should Do Now
Immediate (Next 48 Hours):
- Upgrade Milvus to versions 2.4.24, 2.5.21, or 2.6.5 to patch CVE-2025-64513
- Audit access logs for suspicious sourceId header patterns (base64-encoded @@milvus-member@@ in request headers)
- Implement network segmentation if patching is delayed—restrict Milvus Proxy access to known application servers only
Medium-Term (Next 30 Days):
- Inventory sensitive embeddings: Which vector collections contain data derived from PII, PHI, financial records, or proprietary documents?
- Assess threat model: Does your security architecture protect against insider threats, credential compromise, and memory-based attacks—or only perimeter breaches?
- Evaluate encryption requirements: For regulated data or high-value IP, determine whether authentication-only access controls meet your compliance and risk tolerance thresholds
Long-Term Architecture (Next Quarter):
- Adopt defense-in-depth principles: Layer authentication (who gets in) with encryption (what they can access) and customer-controlled keys (who can decrypt)
- Build compliance audit trails: Document your cryptographic controls for SOC2, HIPAA, and FedRAMP requirements—"we have strong authentication" increasingly isn't sufficient
- Plan for regulatory evolution: AI-specific data protection regulations are emerging globally—encryption-in-use positions you ahead of mandates rather than scrambling to comply after incidents
A Note on Responsible Disclosure
The security community owes thanks to ByteDance's Volcengine team for discovering and responsibly reporting CVE-2025-64513, and to the Milvus maintainers for their coordinated response. This is how vulnerability disclosure should work: researchers find flaws, vendors patch quickly, and the community receives clear mitigation guidance.
We write about CVE-2025-64513 not to criticize Milvus—all complex software has vulnerabilities—but to examine what it reveals about systemic architecture choices across the vector database ecosystem. Authentication will always have bugs. Keys will always be phished. Admins will always have access. The question isn't whether your perimeter will be breached; it's what adversaries can do once inside.
Encryption-in-use architecture shifts that calculus fundamentally.
Further Reading
Understand the Vulnerability:
Learn About Vector Database Security:
- CyborgDB Documentation - our approach to encryption-in-use for vector databases
Questions to Ask Your Security Team:
- If an attacker bypassed authentication tomorrow, what plaintext data would they access in our vector database?
- Do our embeddings contain data subject to HIPAA, GDPR, or PCI-DSS requirements?
- Who controls the encryption keys for our vector database—our organization, or our cloud provider?
- What's our answer when enterprise customers ask: "How do you cryptographically protect our data in your AI systems?"
