Improper access control in Azure Cosmos DB

CVE-2026-66803 (dubbed CosmosEscape by Wiz) is an improper access control flaw in Azure Cosmos DB's Gremlin API query engine. The custom .NET-based engine failed to restrict reflection techniques, allowing an attacker with a standard Azure account and a Gremlin-enabled Cosmos DB instance to escape the query sandbox, achieve arbitrary code execution on the multi-tenant DB Gateway, and extract a platform-wide signing secret — the so-called *Cosmos Master Key*. That key unlocked a regional Config Store directory containing every customer's account metadata, subscription IDs, and tenant IDs, and could retrieve the primary key for *any* Cosmos DB account across all API types (SQL, MongoDB, Cassandra, Gremlin) and all Azure regions. The theoretical blast radius was total: full read/write access to every Cosmos DB database on the platform, including internal Microsoft data like Teams messages and Copilot conversation histories.

Microsoft's CVSS 10.0 rating accurately reflects the *theoretical* impact of this chain — unauthenticated-equivalent cross-tenant access to every database on one of Azure's flagship services is about as bad as cloud vulns get. However, the vendor score is misleading for enterprise patch prioritization because (a) the hotfix was deployed server-side within 48 hours of the November 2025 report, (b) the long-term architectural remediation eliminating the Cosmos Master Key entirely was completed across all regions by July 2026, (c) Microsoft confirmed no evidence of customer impact or unauthorized access outside Wiz's controlled testing, and (d) there is no customer-side patch to apply — this was fixed at the platform level. For a defender managing 10,000 hosts, this CVE does not generate a single patch task.

Why this verdict

• Cloud-managed fix eliminates the patch queue entirely. Unlike on-prem software, the defender has no binary to update, no host to reboot, no change window to schedule. Microsoft remediated the vulnerability at the platform level before public disclosure. This is the primary driver of the downgrade from CRITICAL to LOW.
• No exploitation evidence and no public PoC. Microsoft's investigation found zero unauthorized access outside Wiz's controlled testing. The EPSS score of 0.00494 is consistent with a vulnerability that cannot be re-exploited post-fix. The Black Hat presentation (August 6) may release technical details, but the attack surface no longer exists.
• Role multiplier: Cosmos DB is canonically a high-value production database engine hosting regulated and mission-critical data — ordinarily this would floor the verdict at HIGH or CRITICAL. However, the floor rule applies to vulnerabilities *the defender must act on*. Here, the vulnerability existed in Microsoft's control plane, not in customer-deployed software. The blast radius was Microsoft's responsibility, and they closed it. The residual customer risk is limited to the theoretical possibility that keys were compromised during the ~8-month window (November 2025 – July 2026), which Microsoft says did not happen.
• Residual risk is limited to key hygiene. The only customer-side action that reduces residual risk is rotating Cosmos DB primary/secondary keys as a precautionary measure. This is good hygiene, not an emergency.

Why not higher?

A higher severity (MEDIUM or above) would be appropriate if (a) the vulnerability were still exploitable, (b) a customer-side patch or configuration change were required, or (c) there were evidence of in-the-wild exploitation during the exposure window. None of these conditions are met. Assigning MEDIUM+ would create false urgency in the patch queue and displace attention from vulnerabilities the defender can actually act on.

Why not lower?

IGNORE would be defensible, but the 8-month window between hotfix and full architectural remediation creates a non-zero chance that a sophisticated actor independently discovered and exploited the chain before the Master Key was eliminated. Rotating Cosmos DB keys is a real action item that justifies a LOW rather than IGNORE rating. Additionally, the Black Hat presentation on August 6 may reveal details that change the calculus — defenders should monitor for new intelligence.

1. Rotate all Cosmos DB primary and secondary keys — As a precaution against the theoretical possibility of key compromise during the November 2025 – July 2026 exposure window, regenerate primary and secondary keys for all Cosmos DB accounts, especially those using the Gremlin API. Update connection strings in all dependent applications. No noisgate mitigation SLA applies at LOW severity — treat as backlog hygiene, but completing this within 30 days is reasonable given the precautionary nature.
2. Enable and review Cosmos DB diagnostic logs — Turn on full diagnostic logging for all Cosmos DB accounts if not already enabled. Review logs from November 2025 through July 2026 for unexpected authentication events, unfamiliar source IPs, or anomalous query patterns that could indicate exploitation during the exposure window.
3. Verify Microsoft Defender for Cloud alerts — Check Microsoft Defender for Cloud for any alerts related to Cosmos DB anomalous access. Microsoft's investigation found no customer impact, but independent verification using your own telemetry is prudent.
4. Monitor Black Hat USA disclosure (August 6, 2026) — Wiz will present full technical details at Black Hat. While the vulnerability is patched, the presentation may reveal new attack patterns or adjacent risks in Cosmos DB that require updated compensating controls.

Run this from any workstation with the Azure CLI (az) installed and authenticated. It checks whether your Cosmos DB keys have been rotated since the exposure window opened. Invoke with: bash cosmos_key_check.sh. Requires az login with Reader role on the target subscription(s).

#!/usr/bin/env bash
# cosmos_key_check.sh — Check Cosmos DB key rotation status post-CosmosEscape (CVE-2026-66803)
# Run on any workstation with Azure CLI installed and authenticated.
# Requires: az login, Reader role on target subscriptions.
# Output: VULNERABLE (keys not rotated since Nov 2025), PATCHED (keys rotated), or UNKNOWN.

set -euo pipefail

EXPOSURE_START="2025-11-20"
TODAY=$(date -u +%Y-%m-%d)

echo "[*] CosmosEscape Key Rotation Audit (CVE-2026-66803)"
echo "[*] Checking all Cosmos DB accounts in current subscription..."
echo ""

ACCOUNTS=$(az cosmosdb list --query '[].{name:name, rg:resourceGroup, kind:kind}' -o tsv 2>/dev/null)

if [ -z "$ACCOUNTS" ]; then
  echo "[*] No Cosmos DB accounts found in current subscription."
  echo "RESULT: UNKNOWN — no Cosmos DB accounts to evaluate"
  exit 2
fi

VULN_COUNT=0
PATCHED_COUNT=0
TOTAL=0

while IFS=$'\t' read -r NAME RG KIND; do
  TOTAL=$((TOTAL + 1))
  # Check activity log for key regeneration events since exposure start
  REGEN_EVENTS=$(az monitor activity-log list \
    --resource-group "$RG" \
    --start-time "${EXPOSURE_START}T00:00:00Z" \
    --query "[?contains(operationName.value, 'Microsoft.DocumentDB/databaseAccounts/regenerateKey')]" \
    -o tsv 2>/dev/null | head -1)

  USES_GREMLIN=""
  if [ "$KIND" = "GlobalDocumentDB" ]; then
    # Check if Gremlin API is enabled
    CAPABILITIES=$(az cosmosdb show --name "$NAME" --resource-group "$RG" \
      --query 'capabilities[].name' -o tsv 2>/dev/null)
    if echo "$CAPABILITIES" | grep -qi 'EnableGremlin'; then
      USES_GREMLIN=" [GREMLIN API ENABLED - DIRECTLY AFFECTED]"
    fi
  fi

  if [ -n "$REGEN_EVENTS" ]; then
    echo "[+] PATCHED: $NAME (keys rotated post-exposure)$USES_GREMLIN"
    PATCHED_COUNT=$((PATCHED_COUNT + 1))
  else
    echo "[-] VULNERABLE: $NAME (keys NOT rotated since $EXPOSURE_START)$USES_GREMLIN"
    VULN_COUNT=$((VULN_COUNT + 1))
  fi
done <<< "$ACCOUNTS"

echo ""
echo "[*] Summary: $TOTAL accounts checked, $PATCHED_COUNT rotated, $VULN_COUNT not rotated"

if [ "$VULN_COUNT" -gt 0 ]; then
  echo "RESULT: VULNERABLE — $VULN_COUNT account(s) have not had keys rotated since the exposure window"
  exit 1
else
  echo "RESULT: PATCHED — all Cosmos DB account keys rotated post-exposure"
  exit 0
fi

Sources

1. Wiz Research — CosmosEscape: Taking Over Every Database in Azure Cosmos DB
2. The Hacker News — Azure Cosmos DB Flaw Exposed Platform-Wide Key
3. GBHackers — CosmosEscape Vulnerability Enables Full Takeover
4. CybersecurityNews — CosmosEscape Vulnerability Details
5. SC Media — Critical Azure Cosmos DB Flaw Risked Cross-Tenant Compromise
6. TechTimes — Wiz Research Breached Azure Cosmos DB Gateway
7. IT Brief UK — Microsoft Fixes Cosmos DB Flaw After Data Access Risk