The only customers exposed are the ones who followed the hardening advice.

CVE-2026-93952 is a CVSS 10.0 improper input validation flaw in on-premises Arista VeloCloud Orchestrator. Arista disclosed it on 22 September 2026, having found it already in use against real deployments. CISA added it to the Known Exploited Vulnerabilities catalog the same day, with a federal remediation deadline of 25 September — three days.

The detail that should stop you is in the applicability note, not the severity score. Only orchestrators configured to authenticate their Edge devices with certificates are exposed. The deployments that followed the stronger authentication guidance are in scope. The ones still running the weaker option are not.

WHAT ACTUALLY HAPPENED

VeloCloud Orchestrator is the control plane of a VeloCloud SD-WAN. It is the server that provisions, configures, monitors and updates every Edge device across every branch office in the deployment. Administrators do not log into branch routers one at a time; they express intent in the orchestrator and it propagates.

The flaw is CWE-20, improper input validation. A remote attacker with no credentials and no prior foothold reaches privileged internal functionality and can compromise the VCO host itself. Arista's own advisory goes further than vendor language usually does: compromise of the orchestrator platform may give attackers access to the Edge devices it controls.

That sentence is the whole incident. The vulnerability is on one host. The consequence is on every site that host manages.

It did not arrive alone. The same KEV update on 22 September carried three other edge-infrastructure flaws under active exploitation: two in Check Point products — an improper certificate validation weakness in Security Gateway VPN negotiation and a pre-authentication path traversal in the Management web service — and a pre-authentication heap overflow in F5 BIG-IP APM. Four products, one catalogue update, one deadline. Every one of them sits at the network edge or in the system that manages it.

WHY BEST PRACTICE BECAME THE PRECONDITION

Certificate-based Edge authentication is the recommended configuration. It is what you deploy instead of shared secrets. It is what the hardening guide tells you to enable, what a consultant configures on day one, and what an auditor gives you credit for.

Here it is the requirement for exploitation.

This is uncomfortable, and it deserves more than a shrug. Security guidance is not a function where more controls always mean less risk. Every control is code. Certificate handling in particular is notoriously difficult code — parsing, chain validation, revocation, identity mapping — and it runs before authentication completes, which means it runs before any of your access controls apply. The Check Point flaw in the same KEV batch is also a certificate validation failure. That is not a coincidence; it is a category.

The lesson is not "stop using certificates." Certificate-based authentication remains the right choice, and shared secrets remain the wrong one. The lesson is that "we followed best practice" is a compliance statement, not an exposure assessment. Hardening changes your risk profile. It does not delete it, and sometimes it relocates it into code paths that are newer, more complex and less exercised than the ones you replaced.

When an advisory lands, the first question cannot be "are we configured securely?" It has to be "are we configured the way this advisory describes?" Those are different questions, and this week they have opposite answers.

WHAT AN ORCHESTRATOR ACTUALLY CONTROLS

Most organisations size the blast radius of a compromised server by what is stored on it. For a control plane, that calculation is wrong. What matters is what it can command.

An attacker holding the VCO does not need to traverse your WAN to reach a branch, exploit its Edge device, or move laterally through a network you have spent years segmenting. The orchestrator already has an authenticated, expected, continuously used channel to every Edge. It pushes configuration down that channel as a matter of routine.

Configuration is the payload. Tunnel definitions decide which sites talk to which. Routing policy decides which traffic leaves through which path. Business policy decides what gets inspected and what does not. An operator who can rewrite those can quietly add a path that exits through infrastructure they control, disable inspection on a specific flow, or open reachability between two segments your architecture diagram shows as isolated — and none of it involves malware, an exploit against the branch, or anything an endpoint agent would ever see.

It also looks legitimate. A configuration change arriving at an Edge from the orchestrator is exactly what an Edge expects. Your monitoring will record a policy push, because that is what happened.

THE PATCH GAP YOU MAY NOT HAVE

Fixed releases exist for the 5.2 and 6.4 trains. At disclosure, the 6.1 and 7.0 trains had none. If you run either, you are exposed, you know you are exposed, and there is nothing to install.

Arista had already patched the Hosted and Dedicated versions of VCO. This is the shared responsibility boundary made concrete: same product, same flaw, and the customers who consume it as a service were remediated before the advisory was public, while on-premises operators started a three-day race.

That is worth remembering the next time an on-premises deployment is justified on security grounds. Running it yourself means you control the patch timing. It also means you own the patch latency, including the days when no patch exists at all.

WHAT TO DO NOW

CHECK YOUR EDGE AUTHENTICATION MODE TODAY — certificate-based Edge authentication plus an on-premises orchestrator puts you in scope until forensics say otherwise; this is a five-minute check that decides whether the rest of this list is urgent.

ISOLATE IF YOUR TRAIN HAS NO FIX — 6.1 and 7.0 operators should restrict VCO reachability to a management network now rather than wait for a release; an access control list is available today and a patch is not.

RECONCILE CONFIGURATION, NOT JUST THE HOST — compare deployed Edge profiles, tunnel definitions, routing and business policy against your intended baseline, because a silent configuration push is the entire payoff of this access and it survives patching.

TREAT THE ORCHESTRATOR AS COMPROMISED UNTIL PROVEN OTHERWISE — exploitation predates disclosure, so an upgraded VCO is patched, not cleared; review administrative accounts, API tokens, scheduled jobs and outbound connections from the host.

FORWARD ORCHESTRATOR LOGS OFF-BOX — an attacker with control of the platform can edit its local audit trail but cannot reach the copy already in your SIEM, and change records are the only evidence that separates a legitimate policy push from a hostile one.

INVENTORY EVERY CONTROL PLANE YOU OWN — SD-WAN orchestrators, wireless controllers, NAC, virtualisation management, network automation servers: each is a single host that commands a fleet, and each deserves the patch latency you currently reserve for internet-facing web servers.

THE UNCOMFORTABLE PART

There is a pattern running through September's KEV additions, and it is not about any one vendor. Cisco ISE, Check Point Management Server, F5 BIG-IP APM, VMware vCenter, now VeloCloud Orchestrator. Every one of them is a management or policy system. Every one was attacked before it was patched.

Attackers stopped working their way in from the edge toward the centre. They go straight for the system that already holds authenticated access to everything, because that system was built to be trusted by design and, in most estates, is watched less carefully than a public web server.

So ask the boring question about your own network. How many hosts can reconfigure every other host — and for each one, could you produce an evidenced answer about who changed what last month?