A CVSS 10.0 in NVIDIA AIStore's PodSpec API: how to check if you are exposed in 15 minutes

A CVSS 10.0 in a storage system is rare. A CVSS 10.0 because a component accepts a Kubernetes PodSpec from a caller and applies it is the most predictable bug in our ecosystem, and NVIDIA AIStore is just the latest product to ship it. I have run Kubernetes in production for years, and I have watched this exact shape show up in workflow engines, notebook spawners and homegrown deploy tools. This post is the runbook I would want at 7pm: what the flaw is, five commands that tell you if you are exposed, and the order to fix it.

Key points

• The flaw: CVE-2026-65162 sits in NVIDIA AIStore's legacy ETL Kubernetes PodSpec initialization API. A remote, unauthenticated caller can supply host-namespace and container-security settings, which means a privileged pod, a host filesystem mount, or another service account. The CVSS 3.1 vector is AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, and the scope-changed flag (S:C) is what takes it to 10.0, because the blast radius is the node and the cluster, not AIStore.
• Who is affected: AIStore versions 0 through 4.9. NVIDIA's fix is AIStore 5.0 (git tag v1.5.0, image tag v5.0), and AIStore 5.1 removes PodSpec initialization entirely.
• Incident or patch ticket: three answers decide it. Is a 4.x aisnode image running? Can anything outside the AIStore namespace reach the proxy API? Does the AIStore service account hold create on pods with no admission policy behind it? Two yeses means page the on-call.
• Remediate in this order: upgrade to 5.0, cut reachability with a default-deny NetworkPolicy, and put a targeted admission policy in front of every pod the AIStore service account creates. The last two remove the attack path on an unpatched build, in well under an hour.
• The bug class: Argo Workflows patched three podSpecPatch bypasses in 2026 alone. Kubernetes defines no safe subset of a PodSpec, and managed Kubernetes on Amazon EKS, Google GKE or Azure AKS does not patch application-layer components like AIStore for you.

What exactly is the NVIDIA AIStore PodSpec vulnerability (CVE-2026-65162)?

CVE-2026-65162 is a flaw in NVIDIA AIStore's legacy ETL PodSpec initialization API that lets a remote attacker hand AIStore a pod definition with host-namespace and container-security settings, which AIStore then creates in your cluster with its own service account. NVIDIA scores it CVSS 3.1 10.0 because the attack is network-reachable, low complexity, needs no privileges and no user interaction, and changes scope from AIStore to the cluster (NVD).

NVIDIA AIStore is open-source, scale-out object storage for AI and ML datasets. It runs as proxies (gateways) and targets (storage nodes), usually deployed on Kubernetes with the AIS Kubernetes Operator, and its ETL feature launches a transformation container co-located with each target (AIStore ETL docs).

NVIDIA published the CVE on October 13, 2026 in Security Bulletin 5889, alongside seven other AIStore CVEs: path traversal, SSRF, a missing-authentication bug in token revocation (CVE-2026-65173, 9.1) and missing authorization on the ETL management API (CVE-2026-65172, 8.6). Every one of them is fixed in 5.0. The brief I started from described this as AIStore's "Kubernetes PodSpec API". NVIDIA's own wording narrows it to the legacy ETL PodSpec init path, and CISA's SSVC enrichment listed exploitation as "none" at publication. The ID, score and vector in the brief all match.

Reading the vector field by field

The FIRST CVSS v3.1 specification defines a scope change as a vulnerability in one component that impacts resources beyond its security scope. Every other field here describes an easy attack. S:C is the single field that turns "AIStore bug" into "cluster compromise".

The mechanic

In AIStore 4.9, the legacy PUT /v1/etl request carries a base64-encoded Kubernetes Pod in an InitSpecMsg. The validator checks the container count, the port name and the readiness probe. Nothing in it looks at securityContext.privileged, hostPID, hostNetwork, hostPath volumes or serviceAccountName. All of those are legal Kubernetes, which is why this validation belongs at admission time, not inside the application.

The realistic kill chain has four steps:

1. Reach the AIStore proxy API from anywhere that can route to it.
2. Submit an ETL init with a privileged pod, hostPID: true and a hostPath mount of /, pinned to a chosen node.
3. Read the node's kubelet credentials and every service account token mounted by pods on that node.
4. Move laterally to secrets, cloud credentials, model weights and the training data AIStore was built to serve.

AIStore's ETL legitimately creates pods. The AIS operator binds the <cluster>-sa service account to a namespaced Role with create, update and delete on pods and services (operator source). The fix is authorization plus admission control, not removing the capability, and NVIDIA's own 5.0 release notes say it plainly: "Kubernetes-level controls create privilege-escalation and node-compromise risks."

Am I affected? How do I check my Kubernetes cluster in the next 15 minutes?

Run five checks in order (version, reachability, RBAC, admission posture, evidence of abuse) and within 15 minutes you will know whether you have an incident or a patch ticket. Each check is one command with a decision rule.

Step 1, version. List every AIStore image and operator-declared image:

kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{.spec.containers[*].image}{"\n"}{end}' | grep -iE 'aisnode|aistore'
kubectl get aistores.ais.nvidia.com -A -o jsonpath='{range .items[*]}{.metadata.namespace}/{.metadata.name}{"\t"}{.spec.nodeImage}{"\n"}{end}'

Decision rule: any aisnode tag at v4.9 or below is vulnerable, and so is a floating latest you cannot resolve to a version. Before 5.0, ETL was compiled into the default image, so every 4.x build has the code path.

Step 2, reachability.

kubectl get svc -A | grep -E 'LoadBalancer|NodePort'
kubectl get ingress -A
kubectl get networkpolicy -n <ais-namespace>

Decision rule: anything reachable from a developer laptop is reachable from any compromised pod in the cluster, and anything with a public IP is reachable from the internet. "Nobody can reach it" is usually wrong: Shadowserver found 381,645 Kubernetes API servers answering 200 OK on the open internet in a single 2022 scan. No NetworkPolicy in the AIStore namespace means every pod in the cluster can call the proxy API.

Step 3, RBAC blast radius.

kubectl auth can-i --list -n <ais-namespace> --as=system:serviceaccount:<ais-namespace>:<cluster>-sa
kubectl get clusterrolebindings -o json | jq -r '.items[] | select(any(.subjects[]?; .name == "<cluster>-sa")) | .metadata.name'

Decision rule: create on pods is expected with the operator, and it is enough to own a node if nothing blocks privileged specs. Any ClusterRoleBinding to that account, or get on secrets, widens the damage to every namespace, production included.

Step 4, admission posture.

kubectl get ns <ais-namespace> -o jsonpath='{.metadata.labels}'
kubectl get validatingadmissionpolicies,validatingwebhookconfigurations

Decision rule: look for pod-security.kubernetes.io/enforce set to baseline or restricted, or a Kyverno, Gatekeeper or ValidatingAdmissionPolicy rule that covers pods in this namespace. warn and audit modes do not count: the Pod Security Admission docs say violations in those modes are "otherwise allowed". Only enforce rejects the pod.

Step 5, evidence of abuse.

kubectl get pods -A -o json | jq -r '
  .items[]
  | select(
      any(.spec.containers[], .spec.initContainers[]?; .securityContext.privileged == true)
      or .spec.hostPID == true or .spec.hostNetwork == true or .spec.hostIPC == true
      or any(.spec.volumes[]?; .hostPath.path == "/"))
  | "\(.metadata.namespace)/\(.metadata.name)  sa=\(.spec.serviceAccountName)  node=\(.spec.nodeName)"'
kubectl get pods,svc -A -l app.kubernetes.io/name=etl -o wide

Decision rule: GPU device plugins and CNI agents will show up here legitimately. Anything carrying the AIStore ETL label (app.kubernetes.io/name=etl) with host access, or an ETL you don't recognize, is an incident.

One caveat matters more than the rest. An empty result proves little if audit logging is off. The kube-apiserver logs nothing unless --audit-policy-file is set (Kubernetes auditing docs), and on Amazon EKS every control plane log type is turned off by default. A short-lived exploit pod leaves no trace in kubectl get pods.

Triage verdict matrix

How do I remediate the AIStore CVE without taking my AI workloads down?

Upgrade to AIStore 5.0 first, since NVIDIA lists it as the fixed release for all eight CVEs in Bulletin 5889. If you can't ship that today, a default-deny NetworkPolicy plus an admission policy scoped to the AIStore service account removes the attack path on a vulnerable build in under an hour, and neither touches running targets.

Upgrade. Pin aistorage/aisnode:v5.0 (or v5.0-etl if you use ETL, since 5.0 moved ETL into a separate build). 5.0 is a mandatory bridge: 4.x clusters must pass through it before 5.1. It also refuses to start with a single collapsed public and intra-cluster listener, so read the upgrade notes and back up cluster metadata before you roll. Roll proxies, then targets, and check object reads during the roll, not after it. Once stable, move to 5.1, which deletes PodSpec ETL initialization outright.

Network. Default-deny ingress on the AIStore namespace, with explicit allows for AIStore's own pods and the namespaces that consume data:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: ais-default-deny
  namespace: ais
spec:
  podSelector: {}
  policyTypes: [Ingress]
  ingress:
    - from:
        - podSelector: {}            # proxies, targets and ETL pods
        - namespaceSelector:
            matchLabels:
              kubernetes.io/metadata.name: training

Remove any public LoadBalancer in front of the proxy and put authentication in front of what must stay reachable. Verify your CNI enforces policies: the Kubernetes docs state that a NetworkPolicy "without a controller that implements it will have no effect". Kubernetes leaves NetworkPolicy behavior for hostNetwork pods undefined, so firewall those at the node or security-group level.

Admission, scoped to the AIStore identity. Enforcing Pod Security Admission restricted on the AIStore namespace will often break the targets themselves, because operator deployments commonly use hostPath for state and data. Scope the rule to pods that the AIStore service account creates instead. The StatefulSet controller creates the targets, so they are unaffected. ValidatingAdmissionPolicy has been stable since Kubernetes 1.30:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: ais-created-pods-guard
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["pods"]
  matchConditions:
    - name: created-by-aistore
      expression: "request.userInfo.username == 'system:serviceaccount:ais:ais-sa'"  # <namespace>:<cluster>-sa
  validations:
    - expression: "!has(object.spec.hostPID) || !object.spec.hostPID"
    - expression: "!has(object.spec.hostIPC) || !object.spec.hostIPC"
    - expression: "!has(object.spec.hostNetwork) || !object.spec.hostNetwork"
    - expression: "!has(object.spec.volumes) || object.spec.volumes.all(v, !has(v.hostPath))"
    - expression: "object.spec.containers.all(c, !has(c.securityContext) || !has(c.securityContext.privileged) || !c.securityContext.privileged)"
    - expression: "!has(object.spec.initContainers) || object.spec.initContainers.all(c, !has(c.securityContext) || !has(c.securityContext.privileged) || !c.securityContext.privileged)"
    - expression: "!has(object.spec.serviceAccountName) || object.spec.serviceAccountName == 'default'"
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: ais-created-pods-guard
spec:
  policyName: ais-created-pods-guard
  validationActions: [Deny]

Kyverno and Gatekeeper can express the same rule. Adjust the service account allowlist if your ETL pods legitimately run as something other than default.

RBAC. The operator re-applies its Role on reconcile, so hand-editing it will not stick. Delete any extra ClusterRoleBinding or secrets grant you found in step 3, re-run kubectl auth can-i --list to prove it took effect, and accept that namespaced create on pods is only safe with the admission policy above.

Rotate. If step 5 turned up evidence, treat every service account token and every secret mountable on the affected nodes as burned, including registry credentials, cloud credentials and model storage keys. Mandiant's M-Trends 2026 puts the global median dwell time at 14 days, so assume the attacker had time to look around.

Audit logging. Turn it on. It is the cheapest control most teams skip and the only one that answers "how long has this been happening".

Remediation order

Why do user-supplied PodSpec APIs keep producing high-severity CVEs?

Any component that accepts a PodSpec, a pod patch, Helm values or raw YAML from a caller and applies it with its own credentials is a privilege-escalation primitive by design, because Kubernetes defines no safe subset of a pod unless you add admission control yourself. The CVE is in AIStore this month, and the same shape shipped in Argo Workflows three times this year.

Argo Workflows' maintainers published CVE-2026-31892 in March 2026: a podSpecPatch in a submitted Workflow bypassed templateReferencing: Strict. The follow-up CVE-2026-42296 in May covered hostNetwork, securityContext and serviceAccountName taking the same merge path. Then CVE-2026-54526 in August found ArtifactGC.PodSpecPatch reaching the same sink. All three are fixed and rated 8.1 to 8.9, and I cite them to show how hard this class is to close even for a mature, well-maintained project. Kubeflow Pipelines, Ray on Kubernetes, JupyterHub's KubeSpawner, CI runners and internal deploy tools all expose some form of "describe a pod and I will run it". None of them carries CVE-2026-65162, and each needs the same admission guardrails.

Five fields do the damage:

• securityContext.privileged, which hands the container the host's devices and kernel capabilities.
• hostPath volumes, which mount the node filesystem, kubelet credentials included.
• hostNetwork and hostPID, which drop the pod into the node's network and process namespaces.
• serviceAccountName, which swaps in a more powerful identity from the same namespace.
• nodeSelector and tolerations, which is how an attacker lands on your GPU nodes instead of a random worker.

AI infrastructure is disproportionately exposed. GPU nodes already run privileged device plugins, drivers and host mounts, so teams waive the restricted baseline in exactly the namespaces that hold model weights and training data. And Kubernetes is where that data now lives: 66% of organizations hosting generative AI models use Kubernetes for some or all of their inference, and 82% of container users run Kubernetes in production (CNCF 2025 Annual Cloud Native Survey).

The data on configuration backs this up. Red Hat's 2024 Kubernetes security report found that 40% of respondents detected misconfigurations in their container or Kubernetes environments and 67% delayed or slowed deployments over security concerns. Datadog's State of Cloud Security found 10% of GKE clusters run with a privileged service account, and 13% of EKS clusters have a node role that is dangerously over-permissioned.

The clock is what turns this into an emergency. Google's Mandiant team measured the average time-to-exploit at five days in 2023, and M-Trends 2026 estimates it at -7 days, meaning exploitation routinely starts before a patch exists. VulnCheck found 23.43% of KEVs in the first half of 2026 exploited on or before CVE publication day. If your upgrade process takes two weeks, the upgrade process is the vulnerability.

So generate PodSpecs from a constrained, declarative input, and never accept them as input.

Does managed Kubernetes (EKS, GKE, AKS) protect me from an application-layer CVE like this one?

No. Amazon EKS, Google GKE and Azure AKS secure and patch the control plane, but all three providers' published shared responsibility models leave the workloads you deploy, AIStore included, with you. The real question is whether a named human owns your application-layer patch pipeline, not whether your cluster is managed.

The providers say so in their own documentation:

• Amazon EKS: "AWS is responsible for the Kubernetes control plane, which includes the control plane nodes and etcd database", while customers own "the configuration of the nodes and the containers themselves" (EKS security docs).
• Google GKE: customers "maintain your workloads, including your application code, build files, container images, data, Role-based access control (RBAC)/IAM policy, and containers and pods that you are running" (GKE shared responsibility).
• Azure AKS: "Microsoft manages the control plane and core platform. You manage your node configuration, workloads, networking configuration, and data" (AKS support policies).

Self-hosting also costs things nobody budgets. You triage CVEs, run admission policies, store audit logs and staff an on-call rotation for a storage layer holding your training data. You also upgrade on the provider's clock: EKS gives a minor version 14 months of standard support plus 12 of extended support, GKE at least 14 months, and AKS supports three GA minor versions at a time.

This is where Qovery fits, and I'll be precise about it. Qovery runs in your own AWS, GCP, Azure or Scaleway account, or on your existing Kubernetes cluster, so the data and the GPU nodes stay yours. Cluster upgrades, per-environment RBAC and the deployment path are handled for you, so a team can run Kubernetes without managing it directly and ship without a dedicated DevOps engineer. Qovery does not patch AIStore for you, and it does not read NVIDIA bulletins on your behalf. What it removes is the class of setup where application components hold create-pod rights and developers hand raw PodSpecs to something that applies them.

Ownership matrix

If nobody on your team can name the person who would have patched this CVE within 24 hours, you are self-hosting more than you meant to.

What should an AI platform's deployment path look like after this CVE?

The target state is one writer to the cluster. Developers describe what they want to run (image, resources, GPU class, environment variables) and a single deployment controller compiles that into a PodSpec under policies developers cannot override. No application-layer component should hold create-pod rights outside its own namespace, and none should apply a pod spec it received from a caller.

1. One writer to the cluster. A single deployment controller owns pod creation, and everything else requests rather than applies.
2. Least privilege by namespace. Per-environment RBAC, so a compromised AI namespace cannot reach production secrets or production nodes.
3. Enforce admission, don't just advise. PSA restricted with documented, reviewed exceptions for GPU device plugins, instead of a blanket waiver across the namespace.
4. Make upgrades boring. If rolling a component or a cluster version is a two-week project, you will not patch a CVSS 10.0 in 24 hours, whatever your intentions.
5. Validate the patch in an ephemeral copy of production. Spin up an environment that mirrors production, GPU node pools included, run the AIStore 5.0 upgrade there, then roll the real thing.

This is the deployment path we built Qovery around: git-push deployments, preview environments per pull request, managed cluster upgrades, per-environment RBAC, auto-stop for non-production environments, and databases backed by managed cloud services. All of it runs inside your own AWS, GCP, Azure or Scaleway account, or your existing Kubernetes cluster.

How do I audit and harden this from Claude Code or Cursor?

You can hand the triage to your coding agent. Install the Qovery Agent Skills once and every compatible agent can inspect what is deployed, where it runs and what it is allowed to do. The Qovery MCP Server is read-only by default, so nothing changes unless you ask for it.

curl -fsSL https://skill.qovery.com/install.sh | bash

# Or scope the install to the current project
curl -fsSL https://skill.qovery.com/install.sh | bash -s -- --project

# Add the Qovery MCP Server to Claude Code over OAuth, read-only by default
claude mcp add --transport http qovery https://mcp.qovery.com/mcp --callback-port 4242

# Write access, only when you explicitly want it (also requires write access enabled in the Qovery Console)
claude mcp add --transport http qovery "https://mcp.qovery.com/mcp?read_write=true" --callback-port 4242

Four skills matter for this job. qovery-troubleshoot and qovery-optimize inspect a running environment, qovery-preview spins up an environment to validate the patched release, and qovery-deploy rolls it out. Then ask in plain language: "show me every service running in my AI environment and what each one is allowed to do", or "spin up a preview environment with the AIStore v5.0 image". The setup is in the AI agent quickstart and the Claude Code integration page.

The kubectl checks above still apply, because an agent can run them just as you can.