Attackers are exploiting an unauthenticated command-injection flaw in on-premises Arista VeloCloud Orchestrator deployments. Arista disclosed CVE-2026-16812 on July 27, assigned it CVSS 10.0 scores under versions 3.1 and 4.0, and said the affected web interface is exposed by default.
The vulnerable surface cannot be disabled through a VCO configuration. An attacker needs network access to the web interface but does not need VCO tenant or operator credentials. Hosted and Dedicated VCO services were patched before the advisory and are not affected. The exposure applies to on-premises VCO releases in four supported trains.
An internal VCO function became remotely reachable
Arista classifies CVE-2026-16812 as OS command injection, CWE-78. Its advisory says functionality intended only for internal use became remotely accessible, allowing an attacker to reach privileged internal functionality and affect the VCO host.
The public record does not identify the vulnerable request path, the injected command syntax, the actor, or when exploitation began. It also does not describe a reliable exploit signature. Those omissions matter because defenders cannot reduce the investigation to one URL, process name, or payload string.
Figure details
An unauthenticated client with network access sends an HTTPS request to the on-premises VCO web interface. Arista says no tenant or operator credentials are required and an internal function is remotely reachable. The flaw can affect the VCO host and managed data. A dashed outward path marks Arista's qualified warning that compromise of the VCO platform may also allow access to managed VeloCloud Edge devices. The advisory does not establish direct unauthenticated access to those Edge devices.
Four VCO release trains require fixed builds
Affected releases are VCO 5.2.x before 5.2.3.14, 6.1.x before 6.1.3.4, 6.4.x before 6.4.2.4, and 7.0.x before 7.0.0.1. Arista lists fixed releases for the 5.2, 6.1, and 6.4 trains. End-of-support versions were not assessed.
Network restriction can reduce exposure while operators patch, but Arista states that no VCO configuration prevents the web-interface exposure. The compensating control is to limit interface access to trusted administrative networks. It does not remove the vulnerable code or prove that an earlier request failed.
CISA added the flaw to its Known Exploited Vulnerabilities catalog on July 27 and set a July 30 remediation deadline for federal civilian agencies. CISA directs organizations to apply vendor mitigations and follow its forensics-triage requirements.
Patching does not answer whether the orchestrator was used
Arista’s advisory now identifies three IP addresses observed conducting attacks: 8.19.75.217, 206.72.242.124, and 206.72.242.162. Operators should block those addresses and search retained VCO logs for connections from them. Arista still warns there is no single definitive indicator of compromise, so a clean result does not close the investigation.
The web-log review should also look for unusual path components, encoded characters, references to local or internal services, and high request rates. Arista tells operators to correlate the same timestamps across backend application logs, system logs, database logs, and filesystem metadata. Unexpected outbound HTTP or HTTPS, command execution, file creation, database exports, archive artifacts, and access to configuration data, credentials, certificates, or key material all warrant investigation. Preserve those records before remediation where operations allow it.
The potential blast radius extends beyond the host. Arista warns that compromise of the VCO platform may allow access to managed VeloCloud Edge devices. Its post-remediation guidance calls for credential rotation, review of administrator activity, validation of managed-device state, and restoration or replacement of affected orchestrator instances from trusted sources.
This is a qualified possibility, not confirmation that every exploited VCO led to an Edge compromise. The advisory publishes no victim count, accessed-data scope, actor name, attack start date, request path, injected command syntax, or Edge-device indicator.
Defenders should close the VCO investigation with host and Edge evidence
Inventory every on-premises VCO instance and compare its release with the four affected ranges. Install the fixed build for the active train and restrict the web interface to trusted administrative networks. Confirm separately that Hosted or Dedicated service is actually vendor-operated before excluding it from the inventory.
Block the three published attack IPs, then preserve and correlate VCO web, backend application, system, and database logs with relevant filesystem timestamps. Investigate unusual requests, unexpected outbound web traffic, commands, files, exports, archives, and sensitive-data access. Examine administrator activity and managed Edge state for changes outside the approved configuration, and rotate credentials that the orchestrator could expose or use. If the review finds suspicious activity, or if those records cannot cover the likely exposure window, restore or replace the VCO instance from a trusted source and treat managed devices as part of the incident scope.
Close the incident only when every VCO instance runs a fixed version, web access is restricted, the published IPs and correlated host evidence produce no unexplained activity, administrator actions are accounted for, managed-device state matches the approved baseline, and required credentials have been rotated. Missing backend, system, database, or web logs, missing filesystem timestamps, or an unverified Edge state leave the compromise question open.