As part of Cisco's ongoing commitment to proactive security and product quality

CVE-2026-20315 is an improper-access-control flaw (CWE-284) in the management cluster of Cisco Secure Workload (formerly Tetration), Cisco's microsegmentation and workload-visibility platform. The internal REST API endpoints accept requests without verifying caller identity, and authorization decisions default to a privileged context — effectively granting Site Admin rights to any anonymous network caller. Affected versions span 2.0.1.34 through the 3.10 and 4.0 branches prior to fixed releases 3.10.9.1 and 4.0.4.16. The flaw was disclosed on 2026-08-19 as part of a hardening advisory (cisco-sa-hardening-csw1-shSvndWP) covering five CVEs, three of which score ≥ 9.6. Exploitation is unauthenticated, requires no user interaction, and is classified by CISA as *automatable* with *total* technical impact.

Cisco's CVSS 10.0 rating is aggressive but defensible. The vector AV:N/AC:L/PR:N/UI:N/S:C reflects that the vulnerable API is reachable over the network, requires zero credentials, and the blast radius crosses scope boundaries — an attacker can read telemetry, modify enforcement policies, and alter agent configurations across tenant boundaries. Because Secure Workload is the *control plane* for data-center microsegmentation, a compromise here does not just expose one box; it lets the attacker disable or rewrite segmentation rules for every workload the platform manages. The vendor severity is essentially correct, and the only meaningful friction is that the management cluster is almost never internet-facing — it lives inside the data center. That limits the reachable population to post-initial-access attackers, but in that threat model the flaw is trivially weaponizable.

Why this verdict

• Unauthenticated, automatable, scope-crossing: The CVSS:3.1 vector is a perfect 10.0 — no credentials, no interaction, low complexity, full CIA impact across scope boundaries. CISA independently rates the technical impact as *total* and the exploitability as *automatable*. This is not an inflated vendor score.
• Role multiplier — security control plane: Cisco Secure Workload is deployed specifically as the microsegmentation enforcement engine for data centers. Compromising the management cluster lets an attacker disable segmentation rules, read workload telemetry, and modify agent configs *across all tenants*. The blast radius is fleet-scale: every workload under management loses its segmentation posture. This is analogous to compromising the management console of an EDR vendor — the chain ends in blanket defensive blindness and unrestricted lateral movement. ≥90% of Secure Workload installations occupy this high-value role by definition; the floor is CRITICAL.
• Friction is real but insufficient to break the floor: The management cluster is VLAN-isolated and not internet-facing in well-run deployments, limiting the reachable population to post-initial-access attackers. There is no public PoC and no observed exploitation. These factors justify a 0.4-point reduction from 10.0 but cannot pull the verdict below CRITICAL because the blast radius on successful exploitation is fleet-scale security-infrastructure compromise.
• No workarounds available: Cisco confirms no mitigations short of patching. The only compensating control is network-level access restriction to the management cluster — which should already exist but does not eliminate the risk from an insider or pivot scenario.
• Adjacent CVEs amplify the chain: The same advisory discloses CVE-2026-20317 (CVSS 10.0, authentication bypass), CVE-2026-20231 (CVSS 9.9, injection), CVE-2026-20318 (CVSS 9.6, input validation), and CVE-2026-20319 (CVSS 7.5, buffer overflow). An attacker with cluster access has *five* independent entry points, dramatically increasing the probability that at least one chain succeeds.

Why not higher?

The vendor already rates this a 10.0, and our reassessment of 9.6 is a marginal reduction, not an increase. A full 10.0 would imply zero friction — but the management cluster's typical VLAN isolation means that unauthenticated *internet* exploitation is not realistic in most deployments. The 0.4-point reduction reflects that prerequisite.

Why not lower?

Downgrading below CRITICAL would require evidence that the management cluster is routinely protected by additional authentication layers (e.g., mTLS, VPN gating) that would stop the unauthenticated API access even from the management VLAN — no such default protection exists. The component is a canonical security-infrastructure target: its *purpose* is fleet-wide policy enforcement, and compromise grants exactly that scope. The blast radius floor overrides the network-exposure friction. Five co-disclosed CVEs in the same advisory further preclude downgrade.

1. Restrict management cluster access to a dedicated jump-host or PAM-gated bastion immediately — Deploy firewall ACLs or VLAN ACLs that limit Layer-3/4 access to the Secure Workload management cluster exclusively to authorized admin jump-hosts. This is the single highest-impact compensating control — it reduces the reachable attack surface to a handful of hardened endpoints. Deploy within 3 days per noisgate mitigation SLA for CRITICAL findings.
2. Enable and alert on API audit logs — Ensure the Secure Workload cluster's API audit logging is enabled and forwarded to your SIEM. Create detection rules for: (1) API calls from non-admin source IPs, (2) unauthenticated API sessions, (3) policy modification events outside change windows. Deploy within 3 days.
3. Monitor for policy-change drift — If you use policy-as-code or GitOps for microsegmentation rules, add a drift-detection job that compares the live policy state against the approved baseline every 15 minutes and alerts on divergence. This catches unauthorized policy rewrites from Step 4 of the attack path.
4. Patch to 3.10.9.1 or 4.0.4.16 — Apply the vendor patch as the definitive remediation. For on-premises deployments, schedule the upgrade within the 90-day noisgate remediation SLA for CRITICAL findings, with preference for accelerating to within 2 weeks given the severity. SaaS deployments are already patched by Cisco.
5. Audit for signs of prior exploitation — Review API access logs and policy change history for the period between deployment and patching. Look for unauthenticated API calls, unexpected Site Admin sessions, or policy modifications not correlated with change tickets.

Run this script on each Cisco Secure Workload cluster node (or query the cluster's version API from an admin workstation). Requires SSH access to the cluster or curl access to the management API. Example: bash check_csw_cve202620315.sh 10.1.2.3

#!/usr/bin/env bash
# check_csw_cve202620315.sh — Check Cisco Secure Workload for CVE-2026-20315
# Usage: bash check_csw_cve202620315.sh [cluster_ip_or_hostname]
# Requires: curl, access to the Secure Workload management API
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail

TARGET="${1:-localhost}"

echo "[*] Checking Cisco Secure Workload version on ${TARGET}..."

# Attempt to get version from the cluster info endpoint
VERSION=$(curl -sk --max-time 10 "https://${TARGET}/openapi/v1/cluster" 2>/dev/null | \
  grep -oP '"version"\s*:\s*"\K[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' 2>/dev/null || true)

if [ -z "$VERSION" ]; then
  # Fallback: try to read from RPM or local version file
  if command -v rpm &>/dev/null; then
    VERSION=$(rpm -q --qf '%{VERSION}' tetration-os 2>/dev/null || true)
  fi
  if [ -z "$VERSION" ]; then
    VERSION=$(cat /etc/tetration/version 2>/dev/null || cat /opt/tetration/version 2>/dev/null || true)
  fi
fi

if [ -z "$VERSION" ]; then
  echo "UNKNOWN — Could not determine Cisco Secure Workload version."
  echo "Manually verify the cluster version against fixed releases: 3.10.9.1 or 4.0.4.16"
  exit 2
fi

echo "[*] Detected version: ${VERSION}"

# Parse major.minor
MAJOR=$(echo "$VERSION" | cut -d. -f1)
MINOR=$(echo "$VERSION" | cut -d. -f2)
PATCH=$(echo "$VERSION" | cut -d. -f3)
BUILD=$(echo "$VERSION" | cut -d. -f4)

vulnerable=false

if [ "$MAJOR" -lt 3 ]; then
  # Version 2.x — vulnerable, must migrate
  vulnerable=true
elif [ "$MAJOR" -eq 3 ]; then
  if [ "$MINOR" -lt 10 ]; then
    # 3.0 through 3.9 — vulnerable, must migrate
    vulnerable=true
  elif [ "$MINOR" -eq 10 ]; then
    # 3.10.x — fixed in 3.10.9.1
    if [ "$PATCH" -lt 9 ]; then
      vulnerable=true
    elif [ "$PATCH" -eq 9 ] && [ "${BUILD:-0}" -lt 1 ]; then
      vulnerable=true
    fi
  fi
elif [ "$MAJOR" -eq 4 ]; then
  if [ "$MINOR" -eq 0 ]; then
    # 4.0.x — fixed in 4.0.4.16
    if [ "$PATCH" -lt 4 ]; then
      vulnerable=true
    elif [ "$PATCH" -eq 4 ] && [ "${BUILD:-0}" -lt 16 ]; then
      vulnerable=true
    fi
  fi
fi

if [ "$vulnerable" = true ]; then
  echo "VULNERABLE — Version ${VERSION} is affected by CVE-2026-20315."
  echo "Upgrade to 3.10.9.1 or 4.0.4.16 immediately."
  exit 1
else
  echo "PATCHED — Version ${VERSION} is not affected by CVE-2026-20315."
  exit 0
fi

Sources

1. NVD — CVE-2026-20315
2. Cisco Advisory — cisco-sa-hardening-csw1-shSvndWP
3. SecurityWeek — Cisco Patches Critical Vulnerability in Secure Workload
4. BleepingComputer — Max Severity Cisco Secure Workload Flaw
5. The Hacker News — Cisco Patches CVSS 10.0 Secure Workload REST API Flaw
6. Cisco Secure Workload Platform Datasheet
7. Cisco DevNet — Secure Workload APIs