NVIDIA AIStore 舊版 ETL API 接受呼叫方提供的 Kubernetes 安全設定，涉及 CVE-2026-65162

AIStore's legacy ETL API accepted Kubernetes security settings from the caller

Storage systems for AI workloads sit between a cluster and a dataset, and increasingly they do more than store bytes: they run transformation jobs next to the data. CVE-2026-65162 in NVIDIA AIStore is a warning about what happens when the configuration of those jobs is taken from the network.

The record

The CVE entry describes NVIDIA AIStore for Linux and a vulnerability in the legacy ETL Kubernetes PodSpec initialization API. A remote attacker may supply Kubernetes host-namespace and container-security settings. The record lists consequences across code execution, privilege escalation, information disclosure, data tampering and denial of service. Affected versions are listed as 0 through 4.9.
The CVSS 3.1 score is 10.0 with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Scope is changed, which reflects the fact that a successful exploit escapes the vulnerable component's own boundary and affects the host environment.

What ETL means in this product

AIStore implements Extract, Transform, Load as jobs that run inside Kubernetes pods, orchestrated by the storage cluster and executed near the data. That design is the product's value: moving computation to the data avoids shipping terabytes across a network.
It also means the storage cluster holds credentials that can create workloads. An API that accepts a PodSpec is accepting instructions about what workload runs, under which identity, and with what access to the node.
Container security settings in a PodSpec are not cosmetic. hostNetwork, hostPID and hostIPC share the host's network stack, process table and inter-process communication namespace. privileged: true removes most of the kernel-enforced isolation. Added capabilities, host path mounts and node selectors decide what the workload can touch.
When those fields can be supplied by a remote caller, the caller is not configuring a job. They are choosing the escape route.

Why the word legacy matters

The record names the legacy ETL PodSpec initialization API. Legacy interfaces are a familiar source of this class of bug for a structural reason: they were designed when the cluster was trusted, and the fields they accepted matched what the calling code needed at the time.
Later, exposure changes. The storage cluster becomes reachable from an application network. The API gets credentials. The interface remains, because something still calls it. Nothing in that sequence adds an authorisation check.
The fix pattern for these interfaces usually involves either removing them or restricting the accepted fields to a safe allowlist, rejecting pod-level security settings and host namespaces entirely. Both approaches share the property that the decision moves from "validate the submitted value" to "this value is not a caller's input".

Reading the impact

A CVSS 10.0 is often read as a score to triage rather than a description to act on. Here the individual components tell the story more clearly than the number.
Confidentiality: the ETL workload can read data volumes and, through a privileged or host-mounted container, node-level file systems and service account tokens.
Integrity: it can write to the dataset it was permitted to read, and to any mount it obtained.
Availability: the same privileges allow terminating pods, exhausting node resources, or removing data the storage cluster is responsible for.
The scope change is the important one. A fixed component would keep the attacker inside the ETL workload. Scope changed means the workload is a starting point for the cluster.

Who should look

The deployments at risk are those where the AIStore cluster is reachable beyond a tightly controlled management network, and where the legacy ETL interface has not been removed. That is a specific configuration question, not a version-only question, which makes internal inventory more reliable than any external count.
The operational context adds pressure. AI infrastructure tends to be built quickly, by teams whose expertise is data and models, on clusters shared with research workloads. The storage cluster's service account is often the most privileged identity in that namespace, because it needs to create jobs.

Remediation

Apply NVIDIA's update for the affected release line. The CVE record covers versions 0 through 4.9, so confirm the deployed build rather than assuming a container tag reflects it.
Disable the legacy ETL initialization API where it is not in active use. The record's own mitigation points at disabling or restricting it.
Restrict network access. The ETL and management endpoints should be reachable from the orchestration control plane and authorised operators, not from an application namespace that also runs untrusted workloads.
Audit PodSpecs the cluster has created. A workload with hostNetwork, hostPID, privileged, host path mounts or unexpected capabilities that no operator wrote is direct evidence of the issue, and also the artifact you need for an incident review.
Reduce the storage service account. A dedicated identity that can create ETL pods but not read every secret in the namespace limits what a successful call yields.

Detection notes

Kubernetes audit logs record pod creation with the requesting identity and the object sent. Comparing the object against the template the storage cluster normally produces finds anomalies quickly: a pod that suddenly requests host namespaces or privilege elevation stands out in a way that a name-based search does not.
The second signal is the service account. A token from the storage cluster's identity used from an unexpected source, or used to list secrets, indicates the interface was reached and the workload did more than transform data.

Closing

An API that accepts a workload specification accepts control over where that workload runs and what it can reach. For a system that already holds data and credentials, the safe design is to accept parameters and build the specification itself.

References

CVE.org record for CVE-2026-65162: https://www.cve.org/CVERecord?id=CVE-2026-65162
NVIDIA product security advisory 5889: https://github.com/NVIDIA/product-security/tree/main/2026/5889
NVIDIA product security landing page: https://www.nvidia.com/en-us/security/