CVE-2026-20223

Cisco · Secure Workload

Cisco Secure Workload contains an access validation flaw in internal REST APIs that permits unauthenticated, remote attackers to perform unauthorized configuration changes as a Site Admin.

Executive summary

An unauthenticated remote code execution vulnerability in Cisco Secure Workload allows attackers to bypass authentication and gain full administrative control over site resources.

Vulnerability

This is an authentication bypass vulnerability affecting internal REST API endpoints. Unauthenticated attackers can send specifically crafted requests to these endpoints, successfully masquerading as a Site Admin user.

Business impact

A successful exploitation grants an attacker full administrative privileges, leading to unauthorized data exfiltration, modification of network security policies, and complete compromise of the Secure Workload environment. Given the critical CVSS score of 10.0, this vulnerability presents an immediate, catastrophic risk to organizational security and operational integrity.

Remediation

Immediate Action: Apply the latest security patches provided by Cisco immediately.

Proactive Monitoring: Audit REST API access logs for anomalous, high-privilege requests originating from unauthorized or external IP addresses.

Compensating Controls: Implement strict network segmentation and restrict access to the Secure Workload management interfaces to trusted administrative subnets only.

Exploitation status

Public Exploit Available: false

Analyst recommendation

The severity of this flaw necessitates immediate remediation. Administrators must prioritize applying vendor-supplied updates to all affected Secure Workload instances to close the authentication bypass vector and prevent unauthorized administrative access.

Deep Dive

Am I vulnerable, and what should I do?

Operational write-up published 2026-05-27. Detection rules are starter content — validate before deploying.

Am I vulnerable?

Affected versions

Product	Vulnerable range
Cisco Secure Workload 3.9	All releases (no fixed train — upgrade out)
Cisco Secure Workload 3.10	All versions prior to 3.10.8.3
Cisco Secure Workload 4.0	All versions prior to 4.0.3.17

Cisco's SaaS clusters were patched automatically. On-premises operators must install the fixed release themselves; this is the only fix Cisco publishes — there is no workaround.

Diagnostic checks

Web UI (operator): log in as Site Admin or Customer Support, open Platform → Upgrade (or Help → About), and read the running cluster software version. Vulnerable if it reports 3.9.x or earlier, 3.10.x where x < 8.3, or 4.0.x where x < 3.17.
OpenAPI (authenticated, read-only): curl -s -H 'Authorization: <signed-OpenAPI-credentials>' 'https://<cluster-fqdn>/openapi/v1/cluster_info' | jq '.'. Inspect the returned software/release field against the table above. Run from an admin workstation only — do not probe unauthenticated endpoints.
Reachability audit (run from outside the admin network): curl -sk -o /dev/null -w '%{http_code}\n' --max-time 5 https://<secure-workload-mgmt-vip>/. Any TCP response (200/301/302/401/403) from a non-admin segment means the management plane is reachable from that segment and the unauthenticated attack vector is live. A timeout or connection-refused is the desired posture pending patching.
Inventory sweep: query your CMDB or Cisco Smart Account for assets typed Cisco Secure Workload (formerly Tetration) and reconcile each cluster's last-reported software version against the fixed releases.

Vulnerability

CVE-2026-20223 is a missing-authentication flaw (CWE-306) in internal REST API endpoints that ship with Cisco Secure Workload. An unauthenticated attacker who can reach the cluster's management VIP sends a crafted HTTP request and is treated as a Site Admin — the highest privilege in the platform — without ever presenting a token, cookie, or API key. Cisco rates the bug CVSS 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H); the scope-changed vector reflects that compromise of one tenant boundary collapses into full Site Admin across tenants in multi-tenant deployments.

The relevant attack surface is the internal REST API, not the customer-facing web portal. SOCFortress's writeup frames this as the "internal fallacy" — the assumption that endpoints labeled internal warrant lower security standards. Any network-reachable endpoint is functionally external once the management plane is reachable from an attacker's vantage point. Security Online flags a detection pitfall that follows from the same property: teams that monitor only the front-end user portal will miss automated REST-layer exploitation entirely. SOCRadar reiterates the cross-tenant blast-radius dimension that the CVSS scope change encodes.

There is no public proof-of-concept, no exploit kit, and no confirmed in-the-wild exploitation as of 2026-05-27. That window — gap between disclosure and exploitation — is the entire mitigation budget. CWE-306 bugs against named-vendor management planes typically attract weaponization quickly because the auth-bypass primitive is short to reverse-engineer from a binary diff of the patched release.

Threat model

Who would exploit this: The most credible operators are targeted intrusion actors — state-aligned groups and sophisticated initial-access brokers — who specifically pursue enterprise security and segmentation infrastructure to neutralize defenses before broader campaigns. Opportunistic ransomware affiliates are a secondary concern because Secure Workload appliances typically live on internal admin VLANs and are not exposed to the public internet by default, which limits mass-scanning value but does not eliminate it where misconfigurations exist. Insider risk is non-trivial: anyone with footing on the management network can reach the REST API unauthenticated and assume Site Admin.

What they're after:

Disable or rewrite east-west microsegmentation policy to enable ransomware-style lateral movement across the data center
Exfiltrate the application-dependency map and workload inventory for precise downstream targeting
Establish stealthy persistence by whitelisting attacker traffic and modifying enforcement rules
Harvest credentials and tokens from configured connectors (vCenter, AD, CMDB integrations) to pivot into adjacent admin systems
Stage destructive impact by removing segmentation guardrails ahead of encryption or wiper deployment

Attack chain: An attacker who has reached the Secure Workload management network — via VPN, a compromised jump host, an exposed admin interface, or an adjacent foothold on the admin VLAN — sends a crafted request to an internal REST API endpoint and is treated as a Site Admin without authenticating. From there, the operator typically enumerates monitored workloads and the application-dependency graph, then modifies segmentation policy to permit attacker-controlled traffic while suppressing alerting. The intrusion then pivots laterally into the workloads and integrated platforms that Secure Workload governs, often planting persistence inside policy objects so changes survive operator review.

Blast radius: Site Admin on Secure Workload yields the full microsegmentation control plane: read or rewrite east-west policy across every enrolled workload, plus the topology and dependency map of the protected estate — effectively a blueprint of crown-jewel applications and their talkers. Configured integrations (vCenter, Active Directory, CMDB, cloud connectors) expose service accounts and API tokens that frequently carry elevated rights into those adjacent systems, enabling pivots well beyond the appliance. Because Secure Workload is the enforcement authority, an attacker can silently permit their own lateral traffic and disable visibility for defenders during follow-on activity.

Mitigation

Patch

Train	Fixed version	Advisory
3.9 and earlier	No fixed release on this train	Migrate to 3.10.8.3 or 4.0.3.17
3.10	3.10.8.3	cisco-sa-csw-pnbsa-g8WEnuy
4.0	4.0.3.17	cisco-sa-csw-pnbsa-g8WEnuy

Cisco-hosted SaaS clusters were patched automatically. On-prem operators must install the fixed software themselves; Cisco recommends contacting TAC for deployment guidance on long-lived clusters.

Configuration mitigation

Cisco explicitly states there is no workaround. The configuration below is defense-in-depth, not a fix — if the management plane remains reachable from the attacker's segment after these changes, the vulnerability is still exploitable. Use it to shrink exposure while you stage the patch.

Restrict Secure Workload management/API reachability to a dedicated admin network:

# Pseudocode policy intent for upstream firewall / security group governing the Secure Workload cluster's management VIP.
# Only the admin jump network should reach the cluster management/API VIP.
# Replace placeholders with your environment's values.

allow from <ADMIN_JUMP_CIDR>           to <SECURE_WORKLOAD_MGMT_VIP> port 443
allow from <SECURE_WORKLOAD_MGMT_VIP>  to <ADMIN_JUMP_CIDR>           established
deny  from any                          to <SECURE_WORKLOAD_MGMT_VIP> port 443 log

# Also audit: load balancer rules, NAT entries, VPN split-tunnel routes,
# and cloud security groups for any path that exposes the cluster mgmt VIP
# to broader enterprise networks.

Compensating controls

Audit REST API access logs for high-privilege configuration changes (user/role/scope mutations, policy edits) originating from IPs outside the admin subnet or from non-standard user-agents.
Rotate API tokens for any Secure Workload integration that holds elevated rights into adjacent systems (vCenter, AD, cloud connectors). A pre-patch token in attacker hands survives the upgrade.
Verify VPN, jump-host, and load-balancer rules around the cluster management VIP — a path that bypasses the admin VLAN defeats every other control here.
Heighten review of policy changes during the patch window and lock change-management approvals to known operators only.

Detection (starter rules — validate before deploying)

These rules are AI-generated starter content. Test against your own telemetry and tune falsepositives before deploying to production.

Network and log signals

HTTP requests to Cisco Secure Workload REST API paths under /openapi/v1/ (e.g., /openapi/v1/users, /openapi/v1/roles, /openapi/v1/scopes, /openapi/v1/role_scopes) returning 200 OK with no prior authenticated session establishment in the same TCP/TLS flow
Requests to internal/undocumented REST endpoints (paths not listed in the published /openapi/v1/ schema, including endpoints under /api/, /internal/, or /admin/ prefixes) returning 200 OK from source IPs that have never previously authenticated to the Secure Workload management interface
REST API calls to the Secure Workload management interface missing the standard Authorization: Bearer header, API key headers (X-Tetration-Key / X-Tetration-Sig), or session cookies, that still return 200 OK rather than 401/403
Sudden spike in Site Admin-scoped configuration mutations (user creation, role assignment, scope changes, policy edits, RBAC changes) occurring outside documented change windows or from non-standard source subnets
Audit log entries for Site Admin actions where the actor User-Agent string is curl/*, python-requests/*, Go-http-client/*, empty, or otherwise does not match the standard browser/Terraform/Ansible User-Agent used by legitimate operators
POST/PUT/PATCH/DELETE requests to Secure Workload REST endpoints from source IPs outside the established management/admin subnet or jump-host range
NGINX front-end access logs showing HTTP 200 OK responses to state-changing methods on /openapi/v1/* paths without a preceding successful authentication request from the same client IP within the session window
TLS client fingerprints (JA3/JA4) on the Secure Workload management VIP that do not match known-good admin browser/SDK fingerprints, paired with 200 OK responses to sensitive endpoints

Sigma

title: Cisco Secure Workload Unauthenticated REST API Access (CVE-2026-20223)
id: 8f3d2a14-6b9e-4c27-9f5e-2a1b4c7d8e09
status: experimental
description: Detects potentially unauthenticated HTTP requests to Cisco Secure Workload (Tetration) REST API endpoints that return HTTP 200 OK without a corresponding Authorization header, API key header, or session cookie. CVE-2026-20223 is an access-validation flaw allowing unauthenticated remote attackers to invoke internal REST APIs and act as Site Admin. Tune the cs-uri-stem patterns and host list to your environment before deploying.
author: CVE Brief
date: 2026/05/27
references:
    - https://www.cve.org/CVERecord?id=CVE-2026-20223
tags:
    - attack.initial_access
    - attack.t1190
    - attack.privilege_escalation
    - attack.t1068
logsource:
    category: webserver
detection:
    selection_path:
        cs-uri-stem|startswith:
            - '/openapi/v1/users'
            - '/openapi/v1/roles'
            - '/openapi/v1/scopes'
            - '/openapi/v1/role_scopes'
            - '/openapi/v1/rbac'
            - '/openapi/v1/site_config'
            - '/openapi/v1/auth'
            - '/api/internal/'
            - '/internal/'
    selection_status:
        sc-status:
            - 200
            - 201
            - 204
    selection_method:
        cs-method:
            - 'POST'
            - 'PUT'
            - 'PATCH'
            - 'DELETE'
    filter_authenticated:
        cs(Authorization)|contains:
            - 'Bearer '
            - 'Basic '
    filter_apikey:
        cs-header|contains:
            - 'X-Tetration-Key'
            - 'X-Tetration-Sig'
    filter_cookie:
        cs(Cookie)|contains:
            - 'session_id='
            - 'csrftoken='
            - 'tetration_session='
    filter_suspicious_ua:
        cs(User-Agent)|startswith:
            - 'curl/'
            - 'python-requests/'
            - 'Go-http-client/'
            - 'Wget/'
            - 'Java/'
            - 'PostmanRuntime/'
    condition: selection_path and selection_status and (selection_method or filter_suspicious_ua) and not (filter_authenticated or filter_apikey or filter_cookie)
fields:
    - c-ip
    - cs-method
    - cs-uri-stem
    - sc-status
    - cs(User-Agent)
    - cs(Referer)
falsepositives:
    - Legitimate Site Admin activity during incident response from unexpected source IPs (jump hosts, VPN concentrators rotated, on-call laptops)
    - Automated platform health checks or internal monitoring probes hitting REST endpoints with non-standard or absent authentication headers
    - Terraform/Ansible/CI automation using API tokens passed via non-standard headers not matched by the filters
    - Internal load balancer or reverse-proxy health probes that strip or rewrite Authorization headers before reaching the NGINX front-end
    - Penetration tests and authorized red-team exercises
level: high

Rule notes

The Sigma rule flags state-changing REST API requests to Secure Workload's user/role/scope/RBAC endpoints that return success (200/201/204) but lack any of the expected authentication artifacts (Bearer/Basic Authorization, X-Tetration API key/signature headers, or session cookies), or that use scripted-client User-Agents. Known limitations: NGINX access-log formats vary (field names like cs(Authorization) and cs-header may need mapping to your SIEM's parser), authenticated attackers replaying valid tokens will not trigger, and legitimate automation using header schemes outside the filter list will produce false positives — tune the path list and authentication-header filters against your own access logs before deploying. No YARA rule is published: a web auth bypass leaves no on-disk artifact suited to YARA matching.