Someone left the keys in the pod factory — any visitor to your AI cluster can order a fully-privileged container off the menu
CVE-2026-65162 is a vulnerability in NVIDIA AIStore's legacy ETL (Extract-Transform-Load) Kubernetes PodSpec initialization API, affecting all versions from 0 through 4.9 on Linux. AIStore is NVIDIA's open-source distributed object store purpose-built for AI/ML datasets — it runs inside Kubernetes clusters alongside GPU workloads, training data, and model artifacts. The PUT /v1/etl endpoint accepts a full Kubernetes Pod specification from the caller. In vulnerable versions, AIStore fails to strip or validate security-sensitive PodSpec fields: an unauthenticated attacker who can reach the API can submit hostNetwork: true, hostPID: true, hostIPC: true, securityContext.privileged: true, and hostPath volume mounts. AIStore's service account then dutifully creates that pod on the Kubernetes cluster, granting the attacker's container direct access to the underlying node's network, processes, and filesystem. This is not a memory-corruption exploit — it is an API-level design flaw that turns a legitimate orchestration feature into a container-escape primitive. Fixed in AIStore 5.0, where the legacy PodSpec init path is removed entirely in favor of a constrained runtime spec.
NVIDIA rated this a perfect CVSS 10.0 — AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — and the vector is technically accurate: no auth, no user interaction, changed scope (container → host), full CIA impact. However, the 10.0 overstates the real-world reach. AIStore is a niche, open-source AI data store. Its API listens on an internal Kubernetes service by default — it is not designed for internet exposure and no competent deployment exposes it. The attacker must already have network access inside the K8s cluster or to the cluster's API surface. Additionally, modern Kubernetes clusters running Pod Security Admission (PSA) in restricted or baseline mode, or OPA/Gatekeeper policies, will reject the privileged pod creation even if AIStore tries to submit it. These factors compress a theoretical 10.0 down to a practical HIGH (8.5): devastating if you reach it and your cluster lacks admission controls, but most deployments have at least one of those safety nets.
5 steps from start to impact.
Reach the AIStore Proxy API
- Network path to AIStore proxy (internal K8s network, NodePort, or misconfigured ingress)
- AIStore running an ETL-enabled build (aisnode image with
-etlsuffix)
- AIStore APIs are internal Kubernetes services — not designed for internet exposure
- Organizations using network policies or service mesh (Istio, Cilium) restrict pod-to-pod traffic
- Cloud-hosted K8s (EKS, GKE, AKS) default to private cluster APIs
PUT /v1/etl calls.Submit Malicious PodSpec via ETL Init API
PUT /v1/etl with a crafted YAML or JSON body containing a full Kubernetes PodSpec. The payload sets hostNetwork: true, hostPID: true, hostIPC: true, securityContext.privileged: true, and mounts the host root filesystem via a hostPath volume at /. AIStore versions < 5.0 do not validate or strip these fields, passing them directly to the Kubernetes API for pod creation. No existing tooling (Metasploit module, nuclei template) is publicly available for this CVE as of 2026-10-14.- AIStore version < 5.0
- ETL feature enabled in the aisnode build
- Kubernetes Pod Security Admission (PSA) in
restrictedorbaselinemode will reject the pod - OPA/Gatekeeper/Kyverno policies that block privileged containers, hostPath mounts, or host namespace access will prevent creation
- The AIStore service account may lack RBAC permissions to create pods with these security contexts in hardened clusters
hostPID, hostNetwork, privileged pod specs.Privileged Container Starts on Target Node
hostPID), use the host network stack (hostNetwork), access host IPC (hostIPC), and read/write the entire host filesystem via the hostPath mount. The attacker's container is effectively running as root on the node.- No Kubernetes admission controller blocking privileged pods
- AIStore service account has sufficient RBAC to create pods in the namespace
- Well-configured clusters enforce PSA
restrictedprofile which rejects all of these settings - Container runtime security (gVisor, Kata Containers) would sandbox even privileged pods
Node Compromise and Lateral Movement
- Attacker's pod is running with host privileges
- Node stores accessible secrets or credentials
- Clusters using encrypted etcd and minimal secret exposure reduce blast radius
- Node-level isolation (separate node pools for AIStore) limits lateral movement
- Short-lived credentials and workload identity federation reduce credential theft impact
kubectl or kubelet API calls from unexpected sources.Data Exfiltration or Supply-Chain Poisoning
- Attacker has node-level access to AIStore storage backends
- Valuable data or models stored in AIStore
- Organizations with data encryption at rest reduce readable data exposure
- Model signing and integrity verification would detect poisoned artifacts
- Network egress controls limit data exfiltration bandwidth
restricted mode rejects pods requesting hostNetwork, hostPID, hostIPC, privileged, or hostPath volumes — this breaks step 3 of the attack chain entirely, preventing the malicious pod from ever starting. Apply the pod-security.kubernetes.io/enforce: restricted label to the AIStore namespace. This is the single most effective compensating control. Deploy within the noisgate mitigation SLA of 30 days for HIGH severity.PUT /v1/etl to specific service accounts. Deploy within 30 days per the noisgate mitigation SLA.privileged: true, hostNetwork: true, hostPID: true, hostIPC: true, or hostPath volumes. This is defense-in-depth behind PSA and catches edge cases where PSA mode is warn rather than enforce. Deploy within 30 days.- Container image scanning (Trivy, Grype, Snyk) — This is an API-level design flaw in AIStore's Go code, not a vulnerable library or OS package in a container image. Image scanners will not flag this CVE unless they have a specific check for AIStore version metadata.
- Web Application Firewall (WAF) — AIStore's API is an internal Kubernetes service, not typically fronted by a WAF. Even if a WAF were in path, the malicious payload is a valid JSON/YAML PodSpec — there is no SQL injection or XSS pattern to match.
- RBAC on the AIStore application layer — AIStore's built-in RBAC (when AuthN is enabled) controls access to buckets and objects, but the ETL init API is a separate control plane endpoint that may not be covered by the same authorization model in versions < 5.0.
The supporting signals.
| In-the-Wild Exploitation | None observed. Not listed in CISA KEV as of 2026-10-14. No known campaigns targeting this CVE. NVIDIA states no active exploitation at disclosure. |
|---|---|
| Proof-of-Concept | No public PoC available. No repositories found on GitHub named after CVE-2026-65162. Not indexed on pocindex.io, ExploitDB, or nuclei templates as of 2026-10-14. However, exploitation is trivially weaponizable — it requires only a crafted HTTP PUT request with a malicious PodSpec payload. A competent attacker needs no memory corruption expertise, just Kubernetes API familiarity. |
| EPSS Score | Not yet scored. CVE was published 2026-10-13 — EPSS scoring typically lags 1-2 days after NVD publication. Given the niche product, expect a moderate EPSS (likely 5th–30th percentile range) once scored. |
| CVSS Vector Interpretation | CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H — Network-accessible, no auth, no user interaction, Scope: Changed (container boundary to host). The S:C is the key driver to 10.0 and is accurate: you escape the container to the host. The PR:N is accurate: AIStore ETL API has no authentication on the legacy init endpoint. |
| Affected Versions | NVIDIA AIStore framework versions 0 through 4.9 on Linux. All ETL-enabled builds (aisnode:*-etl images) are affected. Standard non-ETL builds are not affected as they lack the ETL API entirely. |
| Fixed Versions | AIStore 5.0+ removes the legacy PodSpec init path entirely. The replacement is a constrained runtime spec that does not accept raw Kubernetes PodSpec fields. The legacy PodSpec init is scheduled for full removal in v5.1. |
| Scanning / Internet Exposure | Minimal internet exposure expected. No dedicated GreyNoise or Shodan tags for AIStore as of 2026-10-14. AIStore listens on port 8080 (proxy) and 8081 (target) — these are generic ports that blend with other HTTP services. Shodan queries for AIStore-specific HTTP headers would be needed to fingerprint. The product is designed for internal K8s cluster use only. |
| Disclosure Timeline | Reserved 2026-07-21 by NVIDIA. Published 2026-10-13 as part of NVIDIA security advisory NVIDIA-SA-2026-5889 covering 8 AIStore CVEs. NVD entry awaiting full analysis. |
| Researcher / Reporter | Not publicly credited. The NVIDIA advisory (NVIDIA-SA-2026-5889) does not attribute discovery to a named researcher or organization. A prior AIStore CVE (CVE-2026-24270) was credited to David Mound of Shinobi Security. |
| Related CVEs | Part of an 8-CVE batch in NVIDIA-SA-2026-5889: CVE-2026-65173 (missing auth, 9.1), CVE-2026-65172 (missing authz, 8.6), CVE-2026-65101/65170 (SSRF, 8.6), CVE-2026-65103/65164 (path traversal, 8.1), CVE-2026-65161 (path traversal, 7.5). All require no authentication — indicates a systemic auth posture gap in AIStore's API surface. |
Sources.
- NVIDIA Security Advisory NVIDIA-SA-2026-5889
- SecurityOnline — NVIDIA Fixes 18 AI Software Flaws, Led by CVSS 10.0 Bug in AIStore
- ThreatInt CVE Record — CVE-2026-65162
- Strix AI — CVE-2026-65162 AIStore Framework Vulnerability
- NVIDIA AIStore ETL Documentation
- Offseq Radar — CVE-2026-65162 Analysis
- NVIDIA AIStore GitHub — ETL Architecture
Why this verdict
- Reachability friction (AV:N tempered by deployment reality): The CVSS assumes arbitrary network access, but AIStore's API runs as a Kubernetes ClusterIP service by design. It is not intended for — and rarely exposed to — the internet. The attacker needs either internal K8s network access (post-initial-access) or a misconfigured NodePort/Ingress/LoadBalancer. This compresses the reachable population significantly compared to an internet-facing appliance.
- Kubernetes admission controls (defense-in-depth layer not modeled by CVSS): Pod Security Admission in
restrictedorbaselinemode, OPA/Gatekeeper, or Kyverno policies will reject the privileged pod creation request even if AIStore submits it. This is a real, deployed control in mature K8s environments — it breaks step 3 of the attack chain entirely. CVSS does not account for platform-level defenses. - Niche installed base (low attacker ROI): AIStore is an open-source project with a specialized user base (AI/ML teams building custom data pipelines on NVIDIA GPU clusters). It is not a mass-market product like vCenter, Exchange, or FortiGate. The attacker pool with both the motivation AND the access to exploit this is narrow compared to widely-deployed infrastructure.
- No authentication is damning but scoped: The zero-auth API surface means that IF an attacker reaches it, friction drops to zero — there is no additional gate. This prevents a deeper downgrade and keeps the score at 8.5 rather than MEDIUM. A single misconfigured ingress rule turns this into an instant-win.
- Role multiplier: AIStore is canonically an AI data tier — 100% of deployments serve this function. In the high-value role (production AI pipeline holding proprietary training data and model artifacts), successful exploitation yields mass data egress and potential supply-chain poisoning of downstream AI models. This floor-sets the verdict at HIGH. The chain demonstrably succeeds in this role when K8s admission controls are absent. Blast radius: node → AI cluster → training data → downstream model integrity (supply-chain scale).
- Trivial weaponization: Unlike memory-corruption bugs requiring exploit development, this is a single HTTP PUT with a JSON payload. Once a PoC template circulates (days to weeks), any red teamer or attacker with cluster access can fire it. The time-to-weaponize is measured in hours, not weeks.
Why not higher?
The verdict stays at HIGH (8.5) rather than CRITICAL because (1) the product is not a canonical high-value infrastructure component in the hypervisor/IdP/PAM/CA/network-edge category — it is a niche AI data store, and while its data-tier role is high-value, it does not have the fleet-wide blast radius of domain controllers or hypervisors; (2) Kubernetes admission controllers are a meaningful, widely-deployed defense that breaks the chain at step 3 in mature environments; and (3) network reachability to the API requires either prior cluster access or a misconfiguration, meaningfully narrowing the attacker population compared to a true internet-facing unauth RCE.
Why not lower?
The verdict cannot go below HIGH because (1) every AIStore deployment IS the AI data tier — there is no low-value deployment role, so the blast radius floor applies to the entire installed base; (2) zero authentication means reachability equals exploitation with no additional friction; and (3) the attack is trivially weaponizable without exploit development expertise, meaning the window between PoC publication and mass exploitation will be very short for exposed instances.
Crowdsourced verification payload.
Run this script on any host with kubectl access to the Kubernetes cluster where AIStore is deployed. It checks the AIStore version by querying a running aisnode pod and also verifies whether Pod Security Admission is enforced on the AIStore namespace. Requires kubectl with read access to pods and namespace labels. Example: chmod +x check_cve_2026_65162.sh && ./check_cve_2026_65162.sh <aistore-namespace> (default namespace: ais).
#!/usr/bin/env bash
# CVE-2026-65162 Verification Script
# Checks NVIDIA AIStore version and Kubernetes Pod Security Admission status
# Usage: ./check_cve_2026_65162.sh [namespace]
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN
set -euo pipefail
NAMESPACE="${1:-ais}"
VULN_CVE="CVE-2026-65162"
FIXED_VERSION="5.0"
echo "=== ${VULN_CVE} Verification ==="
echo "Checking AIStore deployment in namespace: ${NAMESPACE}"
echo ""
# Check if kubectl is available
if ! command -v kubectl &>/dev/null; then
echo "ERROR: kubectl not found in PATH"
echo "RESULT: UNKNOWN"
exit 2
fi
# Check if namespace exists
if ! kubectl get namespace "${NAMESPACE}" &>/dev/null; then
echo "ERROR: Namespace '${NAMESPACE}' not found"
echo "RESULT: UNKNOWN"
exit 2
fi
# Find an aisnode pod
AISNODE_POD=$(kubectl get pods -n "${NAMESPACE}" -l app=ais -o jsonpath='{.items[0].metadata.name}' 2>/dev/null || true)
if [ -z "${AISNODE_POD}" ]; then
AISNODE_POD=$(kubectl get pods -n "${NAMESPACE}" --field-selector=status.phase=Running -o jsonpath='{.items[0].metadata.name}' 2>/dev/null || true)
fi
if [ -z "${AISNODE_POD}" ]; then
echo "ERROR: No running AIStore pods found in namespace '${NAMESPACE}'"
echo "RESULT: UNKNOWN"
exit 2
fi
echo "Found AIStore pod: ${AISNODE_POD}"
# Get AIStore version via the daemon API
AIS_VERSION=$(kubectl exec -n "${NAMESPACE}" "${AISNODE_POD}" -- \
curl -s http://localhost:8080/v1/daemon?what=config 2>/dev/null | \
grep -oP '"version"\s*:\s*"\K[^"]+' | head -1 || true)
if [ -z "${AIS_VERSION}" ]; then
# Fallback: check container image tag
AIS_VERSION=$(kubectl get pod -n "${NAMESPACE}" "${AISNODE_POD}" \
-o jsonpath='{.spec.containers[0].image}' 2>/dev/null | \
grep -oP ':\K[v]?[0-9]+\.[0-9]+' || true)
fi
if [ -z "${AIS_VERSION}" ]; then
echo "WARNING: Could not determine AIStore version"
echo "RESULT: UNKNOWN"
exit 2
fi
# Strip leading 'v' if present
AIS_VERSION_CLEAN=$(echo "${AIS_VERSION}" | sed 's/^v//')
echo "Detected AIStore version: ${AIS_VERSION_CLEAN}"
# Check if ETL-enabled build
ETL_ENABLED=$(kubectl get pod -n "${NAMESPACE}" "${AISNODE_POD}" \
-o jsonpath='{.spec.containers[0].image}' 2>/dev/null | \
grep -c 'etl' || echo "0")
if [ "${ETL_ENABLED}" -eq 0 ]; then
echo "NOTE: AIStore image does not appear to be ETL-enabled (no '-etl' suffix)"
echo " Non-ETL builds lack the vulnerable ETL init API endpoint"
echo "RESULT: PATCHED"
exit 0
fi
echo "ETL-enabled build detected"
# Version comparison
if printf '%s\n' "${FIXED_VERSION}" "${AIS_VERSION_CLEAN}" | sort -V | head -1 | grep -qx "${FIXED_VERSION}"; then
echo "Version ${AIS_VERSION_CLEAN} >= ${FIXED_VERSION}"
echo "RESULT: PATCHED"
exit 0
else
echo "Version ${AIS_VERSION_CLEAN} < ${FIXED_VERSION} -- AFFECTED"
fi
# Check Pod Security Admission on namespace
echo ""
echo "--- Compensating Control Check: Pod Security Admission ---"
PSA_ENFORCE=$(kubectl get namespace "${NAMESPACE}" \
-o jsonpath='{.metadata.labels.pod-security\.kubernetes\.io/enforce}' 2>/dev/null || true)
if [ -n "${PSA_ENFORCE}" ]; then
echo "PSA enforce level: ${PSA_ENFORCE}"
if [ "${PSA_ENFORCE}" = "restricted" ] || [ "${PSA_ENFORCE}" = "baseline" ]; then
echo "NOTE: PSA '${PSA_ENFORCE}' mode is active -- privileged pod creation will be blocked"
echo " Exploitation is mitigated but upgrade is still recommended"
fi
else
echo "WARNING: No PSA enforce label found on namespace '${NAMESPACE}'"
echo " Privileged pod creation is NOT blocked by PSA"
fi
echo ""
echo "RESULT: VULNERABLE"
exit 1