CVE-2026-93952: Arista VeloCloud Orchestrator Input Validation Flaw Under Active Exploitation
CISA added CVE-2026-93952, a critical improper input validation flaw in on-prem Arista VeloCloud Orchestrator, to the KEV catalog on 2026-09-22 with a 2026-09-25 remediation deadline. Remote, unauthenticated attackers may reach privileged internal functionality and compromise the orchestrator host.

CVE-2026-93952: Arista VeloCloud Orchestrator Input Validation Flaw Under Active Exploitation
TL;DR
CVE-2026-93952 is a critical improper input validation vulnerability in on-premises Arista VeloCloud Orchestrator (VCO) that allows a remote, unauthenticated attacker to reach privileged internal functionality and impact the orchestrator host. CISA added it to the Known Exploited Vulnerabilities catalog on 2026-09-22 with a federal remediation deadline of 2026-09-25, confirming real-world exploitation. If you run on-prem VCO, apply Arista's fix or documented mitigations immediately, restrict management-plane exposure, and hunt for post-exploitation activity in orchestrator and SD-WAN edge logs.
What is this vulnerability?
| Field | Detail |
|---|---|
| CVE | CVE-2026-93952 |
| Vendor / Product | Arista / VeloCloud Orchestrator (VCO), on-premises |
| Vulnerability name | Arista VeloCloud Orchestrator Improper Input Validation Vulnerability |
| Weakness | CWE-20 (Improper Input Validation) |
| CISA KEV added | 2026-09-22 |
| CISA KEV due date | 2026-09-25 |
| Known ransomware use | Unknown |
| CVSS 3.1 | 10.0 Critical (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H) — source: psirt@arista.com |
| CVSS 4.0 | 9.5 Critical (AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H) — source: psirt@arista.com |
| EPSS | 0.00424 (percentile 0.36318) |
Overview
CVE-2026-93952 is an improper input validation vulnerability (CWE-20) affecting Arista VeloCloud Orchestrator deployments, specifically the on-premises form factor. Arista's Product Security Incident Response Team (PSIRT) assigned the flaw a CVSS 3.1 base score of 10.0 and a CVSS 4.0 score of 9.5, both rated Critical. The vulnerability was published on 2026-09-22, and CISA added it to the Known Exploited Vulnerabilities catalog the same day, with a federal remediation due date of 2026-09-25. That three-day window is the clearest possible signal that exploitation has been observed in the wild and that the risk to exposed orchestrators is considered immediate rather than theoretical.
VCO is the management plane for SD-WAN estates now owned by Arista. Compromise of the orchestrator is a high-value outcome because it controls edge devices, policy, and overlay configuration across an entire enterprise network. An attacker who reaches privileged internal functionality inside VCO is not merely compromising a single appliance; they are positioned above the fabric that connects branches, data centers, and cloud workloads. Arista's advisory notes that hosted, including Dedicated, versions of VCO were impacted and have already been patched. That leaves on-premises deployments as the population that must act, and it is precisely that population which is most likely to be internet-exposed for remote operations and least likely to be covered by a vendor-managed patch pipeline.
Defenders running on-prem VCO instances should treat this as an emergency patch item. Anyone responsible for SD-WAN management infrastructure, identity integration, or the network control plane should prioritize this CVE, and federal agencies subject to BOD 26-04 must document completion against the 2026-09-25 deadline. The combination of a maximum-severity CVSS 3.1 score, a scope-changing impact profile, and same-day KEV listing with a three-day due date places this in the small set of vulnerabilities that justify out-of-band change windows.
Technical details
The root cause is improper validation of attacker-supplied input reaching a privileged internal code path in VCO. In CWE-20 terms, the application accepts data without sufficiently constraining its type, structure, or origin, allowing a remote, unauthenticated party to influence internal functionality that should only be reachable by trusted components or authenticated administrators. The vulnerable component is the VCO management interface exposed to the network, and the trust boundary that matters most is between the unauthenticated network and the orchestrator's internal service layer.
The CVSS 3.1 vector indicates network reachability (AV:N), low attack complexity (AC:L), no privileges required (PR:N), no user interaction (UI:N), and a scope change (S:C), meaning the impact can cross a trust boundary from the vulnerable component into the orchestrator host and the systems it manages. The CVSS 4.0 vector keeps the same impact profile but rates attack complexity as High (AC:H), which is consistent with a flaw that is reliably exploitable once the right request shape is identified but may require some reconnaissance or timing. Both vectors agree on the essentials: no authentication, no user interaction, and high impact across confidentiality, integrity, and availability.
Attack prerequisites are minimal from the attacker's perspective. The flaw is remotely reachable, requires no credentials, and does not depend on a victim opening a file or clicking a link. The practical prerequisite is network reachability to the VCO management interface, which in many deployments is exposed to the internet, to partner networks, or to broad internal segments to support remote administration and branch onboarding. Because VCO sits above the SD-WAN fabric, any code path that reaches privileged internal functionality can be leveraged to read configuration, alter policy, or interact with the underlying host.
Affected version ranges should be confirmed against Arista Security Advisory 0183, since the vendor patched hosted variants first and on-prem guidance is version-specific. In practical terms, the affected population is:
- On-premises VCO deployments that have not yet applied the vendor fix.
- On-prem VCO instances reachable from untrusted networks, including the public internet, guest segments, and partner or third-party networks.
- On-prem VCO instances whose management interface is reachable from broad internal ranges rather than a tightly scoped administrative enclave.
- Hosted and Dedicated VCO customers are noted by the vendor as already patched and are not the primary action population for this CVE.
No public proof-of-concept was referenced at disclosure time, but the KEV listing confirms real-world exploitation. Defenders should not treat the absence of a public exploit as a reason to deprioritize.
Impact
Successful exploitation can compromise the confidentiality, integrity, and availability of the VCO appliance and the data it manages. The CISA KEV summary is explicit on this point: a remote attacker may access privileged internal functionality and impact the VCO host, and successful exploitation may compromise the confidentiality, integrity, and availability of the orchestrator and data managed by the orchestrator.
Confidentiality impact includes exposure of orchestrator configuration, credentials, API tokens, certificates, and the topology of the SD-WAN estate. That data is exactly what an adversary needs to move laterally, impersonate trusted components, or plan follow-on operations against edge devices and the networks behind them. Integrity impact includes the ability to alter policy, push configuration to edge devices, or manipulate the management plane in ways that redirect, degrade, or silently observe traffic. Availability impact includes the potential to disrupt the orchestrator host itself, which can cascade into loss of centralized management for the entire WAN.
Because VCO is a scope-changing asset, a compromised orchestrator is not just one host. It is a pivot point into every branch and data center edge under its control. Downstream abuse scenarios include establishing persistence in the management plane, harvesting secrets for lateral movement, and using the orchestrator as a trusted channel to reach otherwise segmented networks. In SD-WAN architectures, the orchestrator is frequently trusted by edge devices and by identity systems, which means an attacker who controls it can often issue instructions that the rest of the fabric will accept without question.
Business exposure ranges from regulatory and reporting obligations under BOD 26-04 to operational outages, customer-facing SLA breaches, and long remediation timelines if the orchestrator must be rebuilt from scratch. Organizations should also consider the second-order cost of rotating every credential, token, and certificate that the orchestrator touched, and of validating that no unauthorized policy changes persist on edge devices after remediation.
Exploitability
CVE-2026-93952 was added to CISA's KEV catalog on 2026-09-22, the same day it was published, with a remediation due date of 2026-09-25. Same-day KEV listing with a three-day deadline is the strongest available public signal that exploitation is occurring and that the risk is considered immediate for federal and critical infrastructure environments.
The EPSS score at the time of this writing is 0.00424, at the 0.36318 percentile. That is a low probability-of-exploitation score in the next 30 days, and it is worth understanding why it does not contradict the KEV listing. EPSS is a statistical model trained on broad exploitation patterns and does not incorporate confirmed in-the-wild reporting the way KEV does. For a targeted management-plane appliance like VCO, the relevant question is not whether mass scanning will occur but whether a motivated adversary with knowledge of the flaw will use it against exposed orchestrators. KEV answers that question directly.
No public proof-of-concept or exploit code was referenced in the source material at disclosure time. Known ransomware use is listed as Unknown. Defenders should treat the KEV listing itself as the authoritative exploitation signal and should not wait for a public exploit to appear before remediating. KEV-listed flaws also tend to attract follow-on scanning and opportunistic exploitation after the initial reporting window, so post-patch monitoring matters.
KEV vs CVSS vs EPSS
| Signal | What it measures | Action for this CVE |
|---|---|---|
| CISA KEV | Confirmed in-the-wild exploitation, with a binding remediation deadline for federal agencies | Treat as emergency. Remediate by 2026-09-25 and document completion under BOD 26-04. |
| CVSS 3.1 (10.0) | Technical severity of the flaw: network-reachable, no auth, no user interaction, scope change, high CIA impact | Confirms this is a maximum-severity management-plane risk. Do not deprioritize based on EPSS. |
| CVSS 4.0 (9.5) | Updated severity model; same impact profile with attack complexity rated High | Reinforces critical severity; the High complexity rating suggests some reconnaissance may be needed, not that exploitation is unlikely. |
| EPSS (0.00424, 36th percentile) | Statistical likelihood of exploitation in the next 30 days across the broad population | Low score does not override KEV. Use it to inform prioritization of non-KEV assets, not to defer action on this one. |
Exploitation steps (defensive triage)
- Confirm whether the organization operates an on-premises VCO instance and whether it is reachable from untrusted networks, including the public internet and partner or guest segments. Inventory is the first blocker for most teams.
- Review Arista Security Advisory 0183 to identify the exact affected versions and the fixed build for the on-prem form factor, then map those versions against your asset inventory.
- Check VCO and upstream load balancer or reverse proxy logs for anomalous requests to management endpoints, especially malformed or unexpected parameters, unusual HTTP methods, or requests from unfamiliar source IPs.
- Correlate VCO authentication and audit logs for privileged actions that lack a corresponding legitimate administrator session, such as policy changes, API token creation, or configuration exports.
- Inspect the VCO host for signs of post-exploitation activity: new local accounts, modified cron or systemd units, unexpected outbound connections, or tampering with orchestrator services.
- Review SD-WAN edge device logs for configuration pushes or policy changes that did not originate from an approved change window.
- If compromise is suspected, follow CISA's Forensics Triage Requirements under BOD 26-04 and preserve logs before remediation. Evidence collection should precede cleanup.
- Apply the vendor fix or documented mitigations, then validate that the orchestrator is no longer reachable from untrusted networks and that no unauthorized changes persist.
Indicators of compromise
- HTTP requests to VCO management endpoints with malformed, oversized, or unexpected parameters, particularly from source IPs outside known administrator ranges.
- Authentication and audit log entries showing privileged operations without a matching interactive login, or log gaps around the time of suspected exploitation.
- New or modified API tokens, service accounts, or local users on the VCO host that cannot be tied to a change ticket.
- Unexpected outbound connections from the VCO appliance to unfamiliar destinations, which may indicate command-and-control or data staging.
- Configuration drift on SD-WAN edges, including policy, route, or VPN changes not initiated through approved workflows.
- File system changes on the VCO host, such as new binaries, modified scripts, altered service definitions, or unexpected scheduled tasks.
- Alerts from EDR or host monitoring on the VCO appliance for process injection, privilege escalation, or suspicious child processes spawned by orchestrator services.
- Network flow anomalies between the VCO and internal management subnets that deviate from the established baseline.
Mitigation and workarounds
Apply the vendor-provided fix for on-prem VCO as directed in Arista Security Advisory 0183. Hosted and Dedicated VCO customers have already been patched by the vendor and are not the primary action population. Because CISA set a 2026-09-25 due date under BOD 26-04, treat remediation as time-critical and document completion for compliance.
Where immediate patching is not possible, restrict network access to VCO management interfaces to trusted administrative networks only, enforce strong authentication and MFA for all orchestrator logins, and place the appliance behind a hardened reverse proxy or jump host with strict allowlists. These are compensating controls, not substitutes for the vendor fix, and they should be paired with heightened monitoring for the indicators listed above.
Rotate credentials, API tokens, and certificates that may have been exposed, and review orchestrator configuration against a known-good baseline. Validate that edge devices reflect only approved policy, and reconcile any drift against change records. Monitor for re-exploitation after patching, since KEV-listed flaws often attract follow-on scanning and opportunistic attempts.
If mitigations cannot be applied and the asset cannot be isolated, evaluate discontinuing use of the affected on-prem deployment per BOD 26-04 guidance for cloud services. Verification and re-scan are essential: confirm the fixed build is running, confirm the management interface is no longer broadly reachable, and confirm no unauthorized changes persist in the orchestrator or on managed edges.
Community reactions
CISA's addition of CVE-2026-93952 to the KEV catalog on the same day as publication, with a three-day remediation deadline, drove immediate attention from federal defenders and critical infrastructure operators. Security media and vendor advisories framed the issue around the high CVSS scores and the scope-changing nature of the flaw, emphasizing that orchestrator compromise is a network-wide event rather than a single-host incident. Community discussion has focused on the practical difficulty of patching management-plane appliances that are often internet-exposed for remote operations, and on the need to inventory on-prem VCO instances that may be forgotten or unmanaged. No public proof-of-concept was referenced at disclosure, but the KEV listing itself is the strongest signal that exploitation is occurring. Defenders have also highlighted the importance of the BOD 26-04 forensics triage requirements for organizations that suspect compromise.
FAQ
Is CVE-2026-93952 in the CISA KEV catalog? Yes. CISA added it on 2026-09-22, the same day it was published, confirming known exploitation in the wild.
What is the remediation due date? The federal remediation due date is 2026-09-25, three days after KEV listing. Organizations subject to BOD 26-04 must remediate and document completion by that date.
Is the vulnerability exploitable over the internet? The CVSS vectors indicate network reachability with no privileges and no user interaction required. Whether a specific instance is exploitable depends on whether its management interface is reachable from an untrusted network. Stakeholders are responsible for evaluating each asset's internet exposure under BOD 26-04.
Which products and versions are affected? On-premises Arista VeloCloud Orchestrator deployments are the primary affected population. Hosted, including Dedicated, versions were impacted and have already been patched by the vendor. Confirm exact affected and fixed builds against Arista Security Advisory 0183.
Does a public proof-of-concept exist? No public proof-of-concept or exploit code was referenced in the source material at disclosure time. The KEV listing is the authoritative exploitation signal and should drive remediation regardless.
What should I do if I cannot patch immediately? Restrict network access to VCO management interfaces to trusted administrative networks, enforce MFA, place the appliance behind a hardened reverse proxy or jump host, rotate potentially exposed credentials and tokens, and monitor closely for the indicators of compromise listed above. If mitigations cannot be applied and the asset cannot be isolated, evaluate discontinuing use of the affected on-prem deployment per BOD 26-04 guidance.
How do I verify remediation? Confirm the fixed build is running, confirm the management interface is no longer reachable from untrusted networks, review orchestrator and edge configuration against a known-good baseline, and confirm no unauthorized accounts, tokens, or scheduled tasks persist.