CVE-2026-65173 · NVIDIA AIStore AuthN Missing Authentication on Token-Revocation…

01 · The Real Story

Someone left the master key-revocation panel on the front porch of a house almost nobody lives in

CVE-2026-65173 targets the AuthN token-revocation endpoint (DELETE /v1/tokens) in NVIDIA AIStore for Linux, versions 0 through 4.9. An unauthenticated remote attacker can submit crafted token-revocation requests to the AuthN server (default port 52001), causing legitimate user tokens to be invalidated and broadcast across all registered AIStore clusters. The impact is denial of service (all authenticated users lose access to the storage tier) and integrity disruption (selective or wholesale invalidation of authentication tokens). The fix is to upgrade to AIStore v5.0 or later.

NVIDIA rated this CRITICAL at 9.1, which reflects the raw CVSS math — network-accessible, low complexity, no privileges, no interaction, high integrity and availability impact. But the vendor score ignores three massive real-world friction points: (1) AuthN is not enabled by default — NVIDIA's own docs state 'By default, the AIStore deployment does not launch the AuthN server,' meaning the vulnerable endpoint literally does not exist unless an operator opted in; (2) AIStore is a niche open-source AI object-storage platform with ~1.9k GitHub stars, deployed almost exclusively by ML/AI teams inside Kubernetes clusters, not a standard enterprise component; (3) the AuthN service on port 52001 is an internal microservice, almost never exposed to the internet. The vendor CVSS is technically correct in a vacuum but overstates real-world risk by at least two severity notches for the vast majority of environments.

"Unauthenticated token revocation in a niche AI storage service; real risk is high, not critical."

02 · The Attack Path

4 steps from start to impact.

STEP 01

Identify AIStore AuthN endpoint

The attacker scans the target network for the AuthN service, which listens on TCP port 52001 by default. In Kubernetes deployments, this is typically a ClusterIP service reachable only from within the cluster. The attacker needs network reachability to this port, which in most production deployments requires either internal network access or a misconfigured Kubernetes ingress.

Conditions required:

Network reachability to AuthN service on port 52001
AIStore deployment with AuthN explicitly enabled

Where this breaks in practice:

AuthN is not enabled by default — most AIStore deployments never launch it
Port 52001 is almost never exposed externally; typically behind Kubernetes ClusterIP or internal LB
AIStore itself is a niche product with a small installed base

Detection/coverage: Port scan for 52001; Kubernetes network policies should block external access. No dedicated Nessus/Qualys plugin known yet.

STEP 02

Send unauthenticated token-revocation request

The attacker crafts an HTTP DELETE request to /v1/tokens on the AuthN server, supplying a token value (or list of tokens) to revoke. Because the endpoint lacks authentication checks in versions <5.0, the server processes the request without verifying the caller's identity. The request format is a simple JSON body: {"token":"<target_token>"}. No special tooling is needed — curl suffices.

Conditions required:

Successful network access to AuthN endpoint from step 1
Knowledge of token format (JWT) — but arbitrary strings may also be accepted into the revocation list

Where this breaks in practice:

Attacker may not know valid token values to target specific users
Blind revocation of guessed/random tokens may have limited impact

Detection/coverage: AuthN access logs showing DELETE /v1/tokens from unexpected source IPs. WAF or API gateway rules blocking unauthenticated DELETE requests.

STEP 03

Revocation list broadcast to all clusters

Once the AuthN server accepts the revocation, it automatically broadcasts the updated revocation list to every registered AIStore cluster. This is by-design behavior intended for legitimate revocations, but an attacker abuses it to amplify impact across the entire AIStore fleet. All proxies in all registered clusters will now reject the revoked tokens.

Conditions required:

Successful token revocation from step 2
At least one AIStore cluster registered with the AuthN server

Where this breaks in practice:

If no clusters are registered with AuthN, the broadcast has no downstream impact
Organizations with monitoring on AuthN-to-cluster sync traffic may detect anomalous revocation bursts

Detection/coverage: Monitoring AuthN sync events; unusual spikes in revocation list size; cluster-side logs showing mass token rejections.

STEP 04

Denial of service and authentication disruption

Legitimate users whose tokens were revoked lose access to all AIStore storage operations — object reads, writes, list operations, and ETL pipelines all fail with authentication errors. ML training jobs, data ingestion pipelines, and inference workloads dependent on AIStore halt. Recovery requires restarting AuthN, reissuing tokens, and re-authenticating all clients. In a targeted attack, the adversary could selectively revoke tokens for specific high-value service accounts to disrupt critical pipelines while leaving others operational, making the disruption harder to diagnose.

Conditions required:

Successful broadcast from step 3
Active users/services holding the revoked tokens

Where this breaks in practice:

Impact is recoverable — restart AuthN and reissue tokens
No data destruction or exfiltration occurs
Monitoring and alerting on auth failures provides rapid detection

Detection/coverage: Spike in 401/403 errors across AIStore clusters; ML pipeline failure alerts; AuthN service health checks.

03 · Compensating Control

HIGH 7.0→LOW 3.0

SEVERITY REDUCED

Restrict network access to AuthN port 52001 — Deploy a Kubernetes NetworkPolicy or firewall rule that limits inbound TCP/52001 to only the AIStore proxy pods and authorized admin workstations. This is the single most effective control — it eliminates the unauthenticated remote attack vector entirely. Deploy within 30 days per the noisgate mitigation SLA for HIGH severity.

HIGH 7.0→LOW 2.5

SEVERITY REDUCED

Place an authenticating reverse proxy in front of AuthN — Route AuthN traffic through an API gateway (e.g., Kong, Envoy, Istio ingress) that enforces mTLS or bearer-token authentication before requests reach the AuthN service. This adds the missing authentication layer at the network edge. Deploy within 30 days per the noisgate mitigation SLA.

HIGH 7.0→MEDIUM 5.5

SEVERITY REDUCED

Monitor AuthN logs for anomalous DELETE /v1/tokens requests — Set up alerting on the AuthN service logs for any DELETE requests to the /v1/tokens endpoint from unexpected source IPs or at unusual rates. While this does not prevent exploitation, it provides rapid detection and enables incident response within minutes. Implement immediately as a detection complement to the network controls.

HIGH 7.0→IGNORE 0.0

SEVERITY REDUCED

Upgrade to AIStore v5.0+ — The definitive fix. AIStore v5.0 adds authentication to the token-revocation endpoint. Test in staging and deploy within 180 days per the noisgate remediation SLA for HIGH severity. If running v4.x in production, coordinate the upgrade with your ML platform team to validate compatibility.

What doesn't work

WAF rules alone — AIStore uses a custom HTTP API, not standard web traffic. Most WAFs don't have signatures for AIStore-specific endpoints, and the DELETE /v1/tokens request looks like legitimate API traffic. A generic WAF will not block this without custom rules.
Disabling AuthN entirely — While this removes the vulnerable endpoint, it also removes all access control from the AIStore cluster, potentially creating a worse security posture (unauthenticated access to all stored data).
Rotating tokens more frequently — The attacker can revoke tokens faster than you can reissue them. Token rotation doesn't address the root cause and creates an operational burden without security benefit against this specific attack.

04 · Intelligence Metadata

The supporting signals.

In-the-Wild Exploitation	No evidence. Not listed on CISA KEV. No campaigns or threat actor usage reported as of 2026-10-14. Disclosed only yesterday (2026-10-13).
Proof-of-Concept	None public. No PoC found on pocindex.io, GitHub, ExploitDB, or Nuclei templates. No CVE-specific repos on GitHub. Exploitation is trivially simple (single `curl` command), so weaponization requires no formal PoC.
EPSS Score	Not yet scored. CVE was published 2026-10-13; EPSS typically populates within 1-3 days of NVD analysis. Expected to be low given niche product and no exploitation history.
CVSS Vector	CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H — Network-accessible, low complexity, no auth needed. No confidentiality impact. High integrity and availability impact. The vector is accurate for the raw technical capability but doesn't account for deployment-context friction.
Affected Versions	NVIDIA AIStore framework versions 0 through 4.9 on Linux. All releases prior to v5.0 are affected.
Fixed Versions	AIStore v5.0 (current latest is v5.1). Upgrade path: `v4.x → v5.0+`. No distro backports apply — AIStore is deployed from source, containers, or Helm charts, not via OS package managers.
Scanning/Exposure	Minimal internet exposure. No AIStore-specific GreyNoise tags observed. Shodan/Censys show negligible public-facing AIStore instances — the product is deployed internally in Kubernetes clusters. Censys reported 268k AI-related endpoints broadly, but AIStore's AuthN on port 52001 is almost exclusively internal.
Disclosure Timeline	CVE reserved 2026-07-21. Published in NVIDIA Security Bulletin 5889 on 2026-10-13 alongside 17 other AIStore/AI-stack CVEs. Part of a batch of 8 AIStore flaws, all requiring no privileges.
Reporting	Credited to NVIDIA internal security team via bulletin 5889. No external researcher attribution found.
Related CVEs	Part of a batch: CVE-2026-65162 (CVSS 10.0, ETL RCE), CVE-2026-65170 (SSRF, 8.6), CVE-2026-65172 (missing authz, 8.1), CVE-2026-65161/65164 (path traversal). The RCE in -65162 is the higher-priority sibling.

Sources.

05 · The Call

Final Verdict

↓ DOWNGRADED to HIGH (7.0/10)

Why this verdict

AuthN is off by default — the vulnerable surface doesn't exist in most deployments. NVIDIA's documentation explicitly states the AuthN server is not launched by default. Only organizations that explicitly opted into token-based access control are exposed. This eliminates a large fraction of the installed base from the vulnerable population.
Niche product with small installed base. AIStore has ~1.9k GitHub stars and is used by specialized AI/ML teams for training-data storage. It is not a standard enterprise component like Active Directory, vCenter, or a network edge appliance. The total number of production AIStore deployments with AuthN enabled is likely in the low thousands globally.
Internal-only network exposure in typical deployments. AIStore runs inside Kubernetes clusters, and the AuthN service on port 52001 is a ClusterIP or internal-only service. Reaching it requires either internal network access (post-initial-compromise) or a misconfigured ingress — both of which compound the friction significantly.
Impact ceiling is DoS and auth disruption, not RCE or data theft. The CVSS vector correctly shows C:N — no confidentiality impact. The attacker can revoke tokens (causing service disruption) but cannot read data, execute code, or escalate privileges. Recovery is straightforward: restart AuthN and reissue tokens.
No exploitation activity, no PoC, no KEV listing. The CVE was disclosed yesterday with zero evidence of in-the-wild exploitation, no public proof-of-concept, and no CISA KEV entry. While exploitation is trivially simple if reachable, the absence of activity reflects the small attack surface.
Role multiplier: AIStore occupies the role of an AI/ML data-storage tier — analogous to MinIO or a specialized S3 backend. (a) Low-value role: dev/sandbox AI experiments — DoS is inconsequential. (b) Typical role: internal ML training data store — DoS disrupts pipelines but is recoverable within hours. (c) High-value role: production AI inference pipeline storage — disruption could impact customer-facing AI services, but blast radius is cluster-level, not domain/fleet/supply-chain. AIStore is NOT in the canonical high-value-role catalog (not identity, not hypervisor, not CI/CD, not backup, not network edge). The worst plausible outcome is cluster-level AI pipeline DoS, which does not meet the HIGH floor trigger for 'domain takeover / fleet compromise / mass data egress.' The HIGH verdict is justified by the unauthenticated-remote nature but the niche deployment and DoS-only impact prevent CRITICAL.

Why not higher?

CRITICAL would require either a broader blast radius (fleet/domain/supply-chain impact) or a more severe impact type (RCE, credential theft, data exfiltration). This CVE delivers DoS and integrity disruption to a niche, internal-only, optional authentication service. The affected component is not in the canonical high-value-role catalog, the impact is recoverable, and the vulnerable population is small. There is no evidence of exploitation or weaponization to override the friction analysis.

Why not lower?

Despite the heavy friction, the vulnerability is unauthenticated, network-accessible, and trivially exploitable with a single HTTP request. If an attacker does reach the AuthN endpoint — whether through internal access, a misconfigured ingress, or a cloud VPC peer — they can instantly disrupt all authentication across every registered AIStore cluster with no detection evasion required. The broadcast-amplification effect (one request → all clusters affected) elevates this above a typical MEDIUM-severity DoS. Organizations that did enable AuthN presumably did so because they need access control, making the disruption more consequential in those environments.

06 · Verification

Crowdsourced verification payload.

Run this script on any host with network access to the AIStore AuthN endpoint. Invoke as: bash check_cve_2026_65173.sh <AUTHN_HOST> [PORT] where <AUTHN_HOST> is the AuthN server hostname/IP and [PORT] defaults to 52001. Requires curl and jq. No elevated privileges needed — it performs a read-only health check and a non-destructive probe of the token-revocation endpoint.

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# CVE-2026-65173 Checker — NVIDIA AIStore AuthN Token Revocation
# Tests whether the AuthN token-revocation endpoint accepts unauthenticated requests.
# Exit codes: 0=VULNERABLE, 1=PATCHED, 2=UNKNOWN

set -euo pipefail

AUTHN_HOST="${1:-}"
AUTHN_PORT="${2:-52001}"

if [ -z "$AUTHN_HOST" ]; then
  echo "Usage: $0 <AUTHN_HOST> [PORT]"
  echo "Example: $0 authn.aistore.svc.cluster.local 52001"
  exit 2
fi

BASE_URL="http://${AUTHN_HOST}:${AUTHN_PORT}"

echo "[*] Probing AuthN at ${BASE_URL} ..."

# Step 1: Check if AuthN is reachable
HTTP_CODE=$(curl -s -o /dev/null -w "%{http_code}" --connect-timeout 5 "${BASE_URL}/v1/users" 2>/dev/null || true)
if [ -z "$HTTP_CODE" ] || [ "$HTTP_CODE" = "000" ]; then
  echo "UNKNOWN — AuthN service not reachable at ${BASE_URL}"
  echo "AuthN may not be enabled (it is off by default)."
  exit 2
fi
echo "[*] AuthN is reachable (HTTP $HTTP_CODE on /v1/users)."

# Step 2: Attempt unauthenticated DELETE /v1/tokens with a dummy token
# Using a clearly fake token value to avoid any real impact.
DUMMY_TOKEN="CVE-2026-65173-CHECK-$(date +%s)"
RESPONSE=$(curl -s -w "\n%{http_code}" -X DELETE "${BASE_URL}/v1/tokens" \
  -H "Content-Type: application/json" \
  -d "{\"token\":\"${DUMMY_TOKEN}\"}" \
  --connect-timeout 5 2>/dev/null || true)

RESP_CODE=$(echo "$RESPONSE" | tail -1)
RESP_BODY=$(echo "$RESPONSE" | head -n -1)

echo "[*] DELETE /v1/tokens response: HTTP $RESP_CODE"

if [ "$RESP_CODE" = "200" ] || [ "$RESP_CODE" = "204" ]; then
  echo "VULNERABLE — AuthN accepted unauthenticated token revocation (CVE-2026-65173)."
  echo "Affected: AIStore < 5.0. Upgrade to v5.0+ immediately."
  exit 0
elif [ "$RESP_CODE" = "401" ] || [ "$RESP_CODE" = "403" ]; then
  echo "PATCHED — AuthN correctly rejected unauthenticated revocation request."
  exit 1
else
  echo "UNKNOWN — Unexpected response code $RESP_CODE. Manual review needed."
  echo "Response body: $RESP_BODY"
  exit 2
fi