The vector string is worth reading before the description. Both scales carry the same four access terms: network attack vector, low complexity, no privileges required, no user interaction [2][3]. Under CVSS 3.1, that set with high confidentiality, integrity and availability impact scores 9.8 when scope is unchanged. Arista published S:C, and set 4.0's subsequent-system metrics to high, which is where the last two tenths come from [20]. That is the engineering claim buried in the score: whatever the injected command reaches is not confined to the thing that parsed the request. The description says the same in words, that exploitation may impact the VCO host itself [5].
The path exists because functionality Arista describes as intended for internal use only answers from outside [6]. CWE-78 is the class [4].
The applicability note does the work the platform list cannot. Affected platforms run through the EOS series catalogue, CloudVision in every delivery form, VeloCloud Gateway and Edge [12]. The instruction that governs is different: check your software release against the affected software list, and if it is not there the deployment is not vulnerable regardless of hardware [11]. The list extends to cEOS-lab, which says more about the advisory template than about your lab container. Note the 7.0 train in particular. Its only listed fix is 7.0.0.1, the first patch build, so a deployment on 7.0 as shipped has nowhere to step but forward [19].
A 10.0 is a claim about a deployment where the attacker can reach the web interface. Arista offers one pre-patch lever: restricting VCO web interface access to trusted administrative networks reduces risk of exposure [14]. Whether you have that lever depends on something the advisory does not state, which is whether the vulnerable path is served on the same listener your edges use to reach the orchestrator. If it is, "trusted administrative networks" costs you management reachability, and the advisory does not tell you which. That is the question to answer before the change window, not during it.
Detection is retrospective and thin. The guidance is to read web access logs for unusual URL-like path components, encoded characters, references to local or internal services, or high request rates [15], then correlate backend application and system logs at the same timestamps for unexpected command execution, file creation, database export or archive artifacts [16]. One address is named, 8.19.75.217 [17].
The artifact list also tells you what to assume was taken if any of that lands. Arista lists unexpected access to VCO database contents, configuration data, device inventory, credentials, certificates and key material as worth review [16]. For an SD-WAN control plane, that inventory is the fleet's trust material. So the honest post-patch position on-prem is that the orchestrator's stored secrets stay suspect until the logs come back clean, and clean means backend and system logs you were already keeping before you knew to look. Hosted and Dedicated instances are being patched by Arista [8]. On-prem is where the window is yours to open.
