CVE-2026-10814: Milvus weak hash — HIGH

Q: Is CVE-2026-10814 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-10814, increasing the risk of exploitation.

Q: How to fix CVE-2026-10814?

1. Upgrade Milvus to the first release incorporating patch commit 3d932f1c3e065351c4440c27abe1e6479752544d — verify with maintainers which release tag this landed in. 2. If immediate upgrade is not feasible, harden OS-level access to Milvus hosts: restrict shell access to named accounts, enforce least-privilege for service accounts, and audit who has local access to the database node. 3. In Kubernetes environments, enforce pod-level security contexts to prevent container escapes that could yield local Milvus host access. 4. Audit existing Milvus RBAC grantee assignments via the Milvus SDK/API to detect unexpected privilege configurations or anomalous role memberships. 5. For multi-tenant deployments with strict data isolation requirements, consider separate Milvus instances per tenant until the patch is applied. 6. Monitor Milvus logs for unexpected collection access patterns, particularly queries from roles not normally associated with sensitive collections.

Q: What systems are affected by CVE-2026-10814?

This vulnerability affects the following AI/ML architecture patterns: RAG pipelines, vector databases, semantic search infrastructure, AI agent knowledge bases, multi-tenant AI platforms.

Q: What is the CVSS score for CVE-2026-10814?

CVE-2026-10814 has a CVSS v3.1 base score of 7.0 (HIGH). The EPSS exploitation probability is 0.09%.

CISO Take

Milvus up to version 2.6.13 uses a weak hashing algorithm for grantee IDs in its root coordinator's key-value catalog (kv_catalog.go), creating the potential for hash collisions that could allow a local attacker to impersonate authorized RBAC grantees and access collections they should not be permitted to query. With CVSS 4.5, high attack complexity, and a local-only attack vector, this is not remotely exploitable and presents no CISA KEV listing or public exploit — real-world exploitation requires an existing foothold on the Milvus host. The primary concern for CISOs is multi-tenant deployments where Milvus collections partition access to proprietary embeddings or RAG knowledge bases: a cross-tenant authorization bypass could expose confidential document chunks and vector representations. Upgrade to a build incorporating commit 3d932f1c or restrict local host access as an interim control.

Sources: NVD ATLAS GitHub Advisory

What is the risk?

Medium risk overall. The local attack vector and high complexity substantially reduce exploitability — a threat actor needs an existing presence on the host and sufficient understanding of the weak hash function to engineer a collision against a target grantee ID. No public exploit code exists and the vulnerability is not in CISA KEV. Risk elevates in multi-tenant Milvus clusters where different teams or application workloads share a single instance, because the grantee permission model is the primary data isolation boundary. Organizations with strict data-classification requirements for AI training material or RAG indexes should treat this as higher priority despite the medium CVSS score.

How does the attack unfold?

Local Access

Attacker obtains low-privilege local access to the Milvus host via a compromised developer account, lateral movement from an adjacent pod, or container escape.

AML.T0012

Hash Collision Crafting

Attacker analyzes the weak hash function in kv_catalog.go and generates a grantee ID string that collides with a privileged role's stored hash.

AML.T0106

Authorization Bypass

The colliding grantee ID is accepted by Milvus's RBAC authorization layer as matching a privileged grantee, granting unauthorized access to protected collections.

AML.T0055

Vector Data Exfiltration

Attacker queries unauthorized Milvus collections, exfiltrating proprietary embeddings, RAG-indexed document chunks, or sensitive metadata underlying the AI system.

AML.T0085

Local Access

Attacker obtains low-privilege local access to the Milvus host via a compromised developer account, lateral movement from an adjacent pod, or container escape.

AML.T0012

Hash Collision Crafting

Attacker analyzes the weak hash function in kv_catalog.go and generates a grantee ID string that collides with a privileged role's stored hash.

AML.T0106

Authorization Bypass

The colliding grantee ID is accepted by Milvus's RBAC authorization layer as matching a privileged grantee, granting unauthorized access to protected collections.

AML.T0055

Vector Data Exfiltration

Attacker queries unauthorized Milvus collections, exfiltrating proprietary embeddings, RAG-indexed document chunks, or sensitive metadata underlying the AI system.

AML.T0085

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
Milvus	go	< 0.10.3-0.20260602041816-3d932f1c3e06	`0.10.3-0.20260602041816-3d932f1c3e06`
1.4K OpenSSF 5.4 7 dependents Pushed 7d ago 50% patched ~41d to patch Full package profile →
Milvus	pip	—	No patch
1.4K OpenSSF 5.4 7 dependents Pushed 7d ago 50% patched ~41d to patch Full package profile →

How severe is it?

CVSS 3.1

7.0 / 10

EPSS

0.1%

chance of exploitation in 30 days

Higher than 1% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

Exploit Available

Exploitation: MEDIUM

Sophistication

Moderate

Exploitation Confidence

medium

○ CISA SSVC: Public PoC

○ Public PoC indexed (trickest/cve)

Composite signal derived from CISA KEV, VulnCheck KEV, CISA SSVC, EPSS, Metasploit, Exploit-DB, trickest/cve, Nuclei templates, and inthewild.io exploitation reports.

What is the attack surface?

AV Local

AC High

PR Low

UI None

S Unchanged

C High

I High

A High

What should I do?

6 steps

Upgrade Milvus to the first release incorporating patch commit 3d932f1c3e065351c4440c27abe1e6479752544d — verify with maintainers which release tag this landed in.
If immediate upgrade is not feasible, harden OS-level access to Milvus hosts: restrict shell access to named accounts, enforce least-privilege for service accounts, and audit who has local access to the database node.
In Kubernetes environments, enforce pod-level security contexts to prevent container escapes that could yield local Milvus host access.
Audit existing Milvus RBAC grantee assignments via the Milvus SDK/API to detect unexpected privilege configurations or anomalous role memberships.
For multi-tenant deployments with strict data isolation requirements, consider separate Milvus instances per tenant until the patch is applied.
Monitor Milvus logs for unexpected collection access patterns, particularly queries from roles not normally associated with sensitive collections.

What does CISA's SSVC say?

Decision Track*

Exploitation poc

Automatable No

Technical Impact partial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth Bypass Data Extraction Privacy Violation RAG Framework AML.T0012 - Valid Accounts AML.T0055 - Unsecured Credentials AML.T0085 - Data from AI Services AML.T0106 - Exploitation for Credential Access

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15 - Accuracy, Robustness, and Cybersecurity

ISO 42001

A.9.3 - AI System Security Controls

NIST AI RMF

MANAGE 2.2 - Mechanisms to sustain AI risk management

OWASP LLM Top 10

LLM08 - Vector and Embedding Weaknesses

Frequently Asked Questions

What is CVE-2026-10814?

Milvus up to version 2.6.13 uses a weak hashing algorithm for grantee IDs in its root coordinator's key-value catalog (kv_catalog.go), creating the potential for hash collisions that could allow a local attacker to impersonate authorized RBAC grantees and access collections they should not be permitted to query. With CVSS 4.5, high attack complexity, and a local-only attack vector, this is not remotely exploitable and presents no CISA KEV listing or public exploit — real-world exploitation requires an existing foothold on the Milvus host. The primary concern for CISOs is multi-tenant deployments where Milvus collections partition access to proprietary embeddings or RAG knowledge bases: a cross-tenant authorization bypass could expose confidential document chunks and vector representations. Upgrade to a build incorporating commit 3d932f1c or restrict local host access as an interim control.

Is CVE-2026-10814 actively exploited?

Proof-of-concept exploit code is publicly available for CVE-2026-10814, increasing the risk of exploitation.

How to fix CVE-2026-10814?

1. Upgrade Milvus to the first release incorporating patch commit 3d932f1c3e065351c4440c27abe1e6479752544d — verify with maintainers which release tag this landed in. 2. If immediate upgrade is not feasible, harden OS-level access to Milvus hosts: restrict shell access to named accounts, enforce least-privilege for service accounts, and audit who has local access to the database node. 3. In Kubernetes environments, enforce pod-level security contexts to prevent container escapes that could yield local Milvus host access. 4. Audit existing Milvus RBAC grantee assignments via the Milvus SDK/API to detect unexpected privilege configurations or anomalous role memberships. 5. For multi-tenant deployments with strict data isolation requirements, consider separate Milvus instances per tenant until the patch is applied. 6. Monitor Milvus logs for unexpected collection access patterns, particularly queries from roles not normally associated with sensitive collections.

What systems are affected by CVE-2026-10814?

This vulnerability affects the following AI/ML architecture patterns: RAG pipelines, vector databases, semantic search infrastructure, AI agent knowledge bases, multi-tenant AI platforms.

What is the CVSS score for CVE-2026-10814?

CVE-2026-10814 has a CVSS v3.1 base score of 7.0 (HIGH). The EPSS exploitation probability is 0.09%.

What is the AI security impact?

Affected AI Architectures

RAG pipelinesvector databasessemantic search infrastructureAI agent knowledge basesmulti-tenant AI platforms

MITRE ATLAS Techniques

AML.T0012 Valid Accounts

AML.T0055 Unsecured Credentials

AML.T0085 Data from AI Services

AML.T0106 Exploitation for Credential Access

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.9.3

NIST AI RMF: MANAGE 2.2

OWASP LLM Top 10: LLM08

What are the technical details?

Original Advisory

A vulnerability has been found in milvus-io milvus up to 2.6.13. This vulnerability affects unknown code of the file internal/metastore/kv/rootcoord/kv_catalog.go of the component Grantee ID Hash Handler. The manipulation leads to use of weak hash. The attack needs to be performed locally. The attack's complexity is rated as high. It is stated that the exploitability is difficult. The exploit has been disclosed to the public and may be used. The identifier of the patch is 3d932f1c3e065351c4440c27abe1e6479752544d. Applying a patch is the recommended action to fix this issue.

Exploitation Scenario

An attacker with low-privilege local access to a Kubernetes node or bare-metal server running Milvus — obtained via a compromised developer account, a lateral movement from another pod, or a sidecar container — inspects the Milvus source code or binary to identify the weak hash function used in kv_catalog.go for grantee ID comparison. The attacker then generates candidate grantee ID strings offline until finding one that produces the same hash as a privileged grantee (for example, the admin role or a role with read access to a collection containing proprietary LLM fine-tuning data). By registering or manipulating metadata entries using this colliding ID, the attacker is treated as the privileged grantee by Milvus's authorization layer. The attacker then directly queries the protected collection, exfiltrating the full set of vector embeddings and stored source document chunks that back the organization's RAG pipeline — potentially exposing proprietary knowledge, PII from ingested documents, or trade secrets encoded in the embedding space.

Weaknesses (CWE)

CWE-327 Use of a Broken or Risky Cryptographic Algorithm Primary CWE-327 Use of a Broken or Risky Cryptographic Algorithm Primary CWE-328 Use of Weak Hash Primary CWE-327 Use of a Broken or Risky Cryptographic Algorithm CWE-328 Use of Weak Hash

CWE-327 — Use of a Broken or Risky Cryptographic Algorithm: The product uses a broken or risky cryptographic algorithm or protocol.

[Architecture and Design] When there is a need to store or transmit sensitive data, use strong, up-to-date cryptographic algorithms to encrypt that data. Select a well-vetted algorithm that is currently considered to be strong by experts in the field, and use well-tested implementations. As with all cryptographic mechanisms, the source code should be available for analysis. For example, US government systems require FIPS 140-2 certification [REF-1192]. Do not develop custom or private cryptographic algorithms. They will likely be exposed to attacks that are well-understood by cryptographers. Reverse engineering techniques are mature. If the algorithm can be compromised if attackers find out how it works, then it is especially weak. Periodically ensure that the cryptography has not become obsolete. Some older algorithms, once thought to require a billion years of computing time, can now be broken in days or hours. This includes MD4, MD5, SHA1, DES, and other algorithms that were once regarded as strong. [REF-267
[Architecture and Design] Ensure that the design allows one cryptographic algorithm to be replaced with another in the next generation or version. Where possible, use wrappers to make the interfaces uniform. This will make it easier to upgrade to stronger algorithms. With hardware, design the product at the Intellectual Property (IP) level so that one cryptographic algorithm can be replaced with another in the next generation of the hardware product.

Source: MITRE CWE corpus.