Validated Research Published: Aug 5, 2026

Vector Databases Are Not Just Vectors: Orca Exposure Findings and Milvus Authentication Failures

Orca found Internet-exposed vector databases containing source text, personal data, medical records, credentials, and internal configuration, then validated that credentials from one support-ticket index could reach external SaaS systems. Separately, two critical Milvus vulnerabilities bypassed authentication through a trusted sourceID header and unauthenticated APIs on port 9091. Together, the findings show that a vector database is both a sensitive data store and an AI infrastructure control boundary.

Authentication BypassCredential ExposureIdentity & AccessData GovernanceVector Database
6 applicable AIDEFEND defenses
Source: The AI Data You Forgot to Lock: How Exposed Vector Databases Put Organizations at Risk 
Author: Roi Nisimi
Original article: May 19, 2026

Threat Analysis

  • Vector databases can retain readable source material. Orca found original text, metadata, personal and medical records, credentials, and internal configuration in publicly reachable deployments. In controlled validation, the team used plaintext SaaS credentials from one support-ticket index to authenticate to the corresponding external services.
  • CVE-2025-64513 trusted a caller-controlled identity claim. A crafted sourceID made a vulnerable Milvus proxy treat an external request as internal, bypassing password and API-key checks. Fixes were released in 2.4.24, 2.5.21, and 2.6.5.
  • CVE-2026-26190 exposed two paths on port 9091. The /expr route used a predictable value derived from the default etcd.rootPath, while /api/v1/* routes lacked authentication. A reachable attacker could read secrets, manage users and collections, disrupt service, and under stated conditions write files.
  • Exposure is not evidence of malicious exploitation. Orca confirmed real data exposure and disclosed it to affected organizations. The Milvus advisories show practical exploitability, but there is currently no public evidence that either vulnerability has been used in an actual attack.

Applicable AIDEFEND Defenses (6)

AID-H-003.010
Deployed AI Software Vulnerability Remediation Lifecycle
Very High
Inventory the Milvus versions and image digests actually running, compare them with both advisories, rebuild on a currently supported fixed release, stage the rollout, and use fleet readback to prove that vulnerable instances have exited. This directly closes the two product defects; network controls remain necessary but do not substitute for the vendor fixes.
AID-I-002.001
Internal AI Network Segmentation
Very High
Place vector data and management interfaces in dedicated private segments, then enforce default-deny, port-specific rules between exact workloads. Removing public reachability and blocking Milvus port 9091 from unapproved peers prevents an external caller from reaching the vulnerable handlers in the first place.
AID-H-005.005
Embedding & Vector Store Confidentiality
High
Remove secrets and unnecessary personal data before embedding, encrypt vector stores and backups, and restrict raw-record and vector exports. These controls directly reduce the information Orca found at risk, although encryption at rest cannot protect records returned through a compromised live API.
AID-H-004.002
Service & API Authentication
High
Require every data and management route, including internal handlers, to authenticate an explicit workload identity and authorize it for the requested operation. Mutual TLS and workload credentials prevent callers from gaining authority merely by supplying a trusted-looking header, but this control must accompany rather than replace Milvus upgrades.
AID-E-001.001
Root & Long-Lived Credential Object Eviction
High
If a vector store actually exposed passwords, API keys, client secrets, or long-lived certificates, revoke or rotate the exact incident-scoped credential population at its authoritative issuers and update every consumer. This ends continued use of the leaked credential objects; it does not retroactively prevent the original disclosure.
AID-M-001.005
Public AI Endpoint & Agent-Service Exposure Discovery
Medium
Scan from an external vantage point without enterprise credentials, verify which vector and administrative routes are genuinely reachable, and reconcile each service with its owner, environment, authentication requirement, and approved exposure. This finds orphaned or accidentally public deployments, but a discovery result still requires a separate remediation owner.

What Defenders Should Do Now

  • Remove vector database and management ports from public exposure. Block Milvus port 9091 at firewalls, security groups, and Kubernetes NetworkPolicy unless an exact operational dependency requires it.
  • Upgrade Milvus to a currently supported release that includes both security fixes. Treat stripping inbound sourceID headers and changing etcd.rootPath as temporary, incomplete mitigations rather than final fixes.
  • Inventory what each vector store actually retains, including source chunks, metadata, backups, credentials, and support content. Remove secrets and data that the retrieval use case does not require.
  • Test every data and management route from an untrusted network and identity. Confirm that authentication on the primary API does not leave an auxiliary metrics, debug, or REST listener open.
  • For any confirmed exposure, preserve evidence, identify accessed records, notify the appropriate owners, and revoke or rotate the exact credentials that were present.

Conclusion

The common failure is treating the vector layer as low-risk AI plumbing. Orca showed that it can hold readable source records and working credentials; the Milvus advisories showed that secondary trust shortcuts and management listeners can bypass the authentication defenders thought they had enabled. AIDEFEND  maps this case to separate controls: supported-version remediation, private network boundaries, authenticated workload access, data minimization, exposure discovery, and incident-scoped credential eviction.