← Back to Feed CACHED · 2026-10-14 09:54:27 · CACHE_KEY CVE-2026-65162
CVE-2026-65162 · CWE-250 · Disclosed 2026-10-13

NVIDIA AIStore Legacy ETL PodSpec Init API Unauthenticated Kubernetes Privilege Escalation

ASSESSED — NOISGATE
Vendor
—
—
—
Reassessed
—
—
—
Verdict: —
Do you agree?
01 · The Real Story

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.

"Unauthenticated K8s pod injection in AIStore ETL API — high-value AI data tier, but K8s-internal by design."
02 · The Attack Path

5 steps from start to impact.

STEP 01

Reach the AIStore Proxy API

The attacker must be able to send HTTP requests to the AIStore proxy service, typically listening on port 8080. In Kubernetes deployments, this is a ClusterIP or NodePort service. No authentication is required — AIStore's optional AuthN module is disabled by default in most deployments, and all eight October 2026 AIStore CVEs carry a 'no privileges required' rating.
Conditions required:
  • Network path to AIStore proxy (internal K8s network, NodePort, or misconfigured ingress)
  • AIStore running an ETL-enabled build (aisnode image with -etl suffix)
Where this breaks in practice:
  • 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
Detection/coverage: Network-layer monitoring for unexpected HTTP traffic to AIStore proxy ports. Falco rules for unusual PUT /v1/etl calls.
STEP 02

Submit Malicious PodSpec via ETL Init API

The attacker sends 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.
Conditions required:
  • AIStore version < 5.0
  • ETL feature enabled in the aisnode build
Where this breaks in practice:
  • Kubernetes Pod Security Admission (PSA) in restricted or baseline mode 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
Detection/coverage: Kubernetes audit logs will show pod creation requests with privileged securityContext from the AIStore service account. Falco/Tetragon alerts on hostPID, hostNetwork, privileged pod specs.
STEP 03

Privileged Container Starts on Target Node

If admission controls do not intervene, Kubernetes schedules the attacker's pod on an AIStore target node. The pod runs with full host privileges: it can see all host processes (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.
Conditions required:
  • No Kubernetes admission controller blocking privileged pods
  • AIStore service account has sufficient RBAC to create pods in the namespace
Where this breaks in practice:
  • Well-configured clusters enforce PSA restricted profile which rejects all of these settings
  • Container runtime security (gVisor, Kata Containers) would sandbox even privileged pods
Detection/coverage: Runtime security tools (Falco, Sysdig Secure, Tetragon) alert on privileged container launch, host filesystem access, and host namespace sharing.
STEP 04

Node Compromise and Lateral Movement

With host-level access, the attacker reads kubelet credentials, service account tokens from other pods, and Kubernetes secrets stored on the node. They can pivot to other nodes in the cluster by abusing the kubelet API or stealing credentials. In AI/ML clusters, this means access to GPU workloads, training data managed by AIStore, model weights, and potentially cloud provider IAM roles attached to node instance profiles.
Conditions required:
  • Attacker's pod is running with host privileges
  • Node stores accessible secrets or credentials
Where this breaks in practice:
  • 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
Detection/coverage: EDR on nodes, Kubernetes threat detection (Microsoft Defender for Containers, Prisma Cloud, Aqua), anomalous kubectl or kubelet API calls from unexpected sources.
STEP 05

Data Exfiltration or Supply-Chain Poisoning

The attacker accesses all objects stored in the AIStore cluster — training datasets, model checkpoints, inference data. They can exfiltrate proprietary data or, more insidiously, poison training data or model artifacts to inject backdoors into downstream AI models. This is supply-chain-scale impact for organizations whose AI pipelines depend on the compromised AIStore instance.
Conditions required:
  • Attacker has node-level access to AIStore storage backends
  • Valuable data or models stored in AIStore
Where this breaks in practice:
  • 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
Detection/coverage: Data loss prevention (DLP) at network egress, anomalous data access patterns in AIStore audit logs, model integrity checks in CI/CD pipelines.
03 · Compensating Control

1
HIGH 8.5→LOW 3.0
SEVERITY REDUCED
Enforce Kubernetes Pod Security Admission in restricted or baseline mode on the AIStore namespace — PSA in 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.
2
HIGH 8.5→MEDIUM 5.5
SEVERITY REDUCED
Deploy Kubernetes NetworkPolicy or service mesh to restrict access to AIStore API ports — Create a NetworkPolicy that allows traffic to AIStore proxy (port 8080) only from authorized pods (e.g., training job pods, authorized ETL clients). Deny all other ingress. This breaks step 1 by preventing unauthorized callers from reaching the API. If using Istio/Cilium, apply L7 policies that restrict PUT /v1/etl to specific service accounts. Deploy within 30 days per the noisgate mitigation SLA.
3
HIGH 8.5→MEDIUM 6.0
SEVERITY REDUCED
Enable AIStore AuthN and enforce token-based authentication on all API endpoints — AIStore ships with an optional AuthN module that issues JWT tokens. Enabling it adds an authentication gate to the ETL init API, changing the attack from PR:N to PR:L. Configure AuthN with strong secrets and integrate with your identity provider. This does not fully mitigate the vulnerability (authenticated users can still submit malicious PodSpecs) but raises the bar significantly. Deploy within 30 days.
4
HIGH 8.5→LOW 3.0
SEVERITY REDUCED
Deploy OPA/Gatekeeper or Kyverno policies to block privileged pod attributes from the AIStore service account — Write admission policies that specifically deny pod creation requests from the AIStore service account if they contain 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.
5
HIGH 8.5→IGNORE 0.0
SEVERITY REDUCED
Upgrade AIStore to version 5.0 — The definitive fix. AIStore 5.0 removes the legacy PodSpec init API entirely, replacing it with a constrained runtime spec that does not accept raw Kubernetes security settings. This eliminates the vulnerability at its source. Apply within the noisgate remediation SLA of 180 days for HIGH severity, or sooner if compensating controls above are not feasible.
What doesn't work
  • 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.
04 · Intelligence Metadata

The supporting signals.

In-the-Wild ExploitationNone 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-ConceptNo 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 ScoreNot 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 InterpretationCVSS: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 VersionsNVIDIA 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 VersionsAIStore 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 ExposureMinimal 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 TimelineReserved 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 / ReporterNot 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 CVEsPart 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.

  1. NVIDIA Security Advisory NVIDIA-SA-2026-5889
  2. SecurityOnline — NVIDIA Fixes 18 AI Software Flaws, Led by CVSS 10.0 Bug in AIStore
  3. ThreatInt CVE Record — CVE-2026-65162
  4. Strix AI — CVE-2026-65162 AIStore Framework Vulnerability
  5. NVIDIA AIStore ETL Documentation
  6. Offseq Radar — CVE-2026-65162 Analysis
  7. NVIDIA AIStore GitHub — ETL Architecture
05 · The Call

Final Verdict
↓ DOWNGRADED to HIGH (8.5/10)

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 restricted or baseline mode, 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.

06 · Verification

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).

noisgate-verify.sh
BASHREAD-ONLYSAFE
#!/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