Arista has patched a VeloCloud Orchestrator (VCO) security hole that has been actively leveraged in the wild, one that the vendor says “may allow a remote attacker to access privileged internal functionality and impact the VCO host.”The Arista security advisory added that the hole “may compromise the confidentiality, integrity, and availability of the orchestrator and data managed by the orchestrator.”Furthermore, it said, “there is no configuration that can prevent the exposure.” The company advised customers with the affected software, VeloCloud Orchestrator On-Prem (formerly VeloCloud Orchestrator by Broadcom), to upgrade to a fixed release as soon as possible: VCO 5.2.3.14 and later in the 5.2 train, VCO 6.1.3.4 and later in the 6.1 train, or VCO 6.4.2.4 and later in the 6.4 train.It also said that, because compromises to the VCO platform could give attackers access to VeloCloud Edge devices, organizations should consider other incident response activities such as credential rotation, review of administrator activity, validation of managed device state, and restoration or replacement of affected instances from trusted sources.About as bad as it getsFrank Dickson, group VP for security at IDC, described the hole as a “CISO day wrecker.” “This is the rare kind of perfect 10 that you never want to see: an unauthenticated command-injection flaw that’s already being exploited in the wild is what CISO have nightmares about,” Dickson said. “To make things worse, there’s no configuration workaround because the VCO web interface is exposed by default.”Consultant Brian Levine, executive director of FormerGov, agreed.“A CVSS‑10, unauthenticated command‑injection flaw in a network orchestrator is about as bad as it gets. Once an attacker owns the management plane, they effectively own every connected edge device,” he said. “The enterprise implication is straightforward: treat SD‑WAN and orchestration platforms as Tier‑0 assets, restrict their exposure, and patch them with the same urgency you reserve for identity infrastructure.”He pointed out, “this is another reminder that ‘segmentation’ built on compromised network gear is an illusion. If your control plane is exposed to the internet, you’ve already lost the first battle.”Noah Kenney, principal consultant at Digital 520, added, “A management plane that an unauthorized stranger can run commands on is close to the worst-case scenario.”Concerning questionsGiuseppe Trotta, principal security researcher at Malwarebytes, also noted that the technical details disclosed raise concerning questions. “Arista reportedly secured its cloud-hosted infrastructure before on-premises deployments, highlighting a harsh reality that organizations that choose on-prem for compliance, sovereignty, or control often face slower access to critical security fixes during active exploitation,” he said. And because many enterprises unknowingly leave VCO management interfaces internet-accessible for use by vendors and integrators, this turns a single vulnerability into a potential enterprise-wide compromise.He added that patch management in this case may be tricky. “The patch could be a difficult operational challenge for mature organizations that rely on SD-WAN automation through tools such as Ansible and Terraform. Any change to backend command execution may disrupt existing workflows.”A familiar failureThe consultants and analysts also highlighted Arista’s statement that the functionality being compromised “was intended to be for internal use only and is not intended to be remotely accessible.”‘Not intended to be remotely accessible’ isn’t the same as ‘not remotely accessible,’ IDC’s Dickson said. “This is a textbook case of internal functionality that was never actually sufficiently walled off from the exposed interface, which is why a single unauthenticated request could reach it.”Kenney added the internal-only mindset is not only dangerous now, but is going to be increasingly so now that attackers have discovered the weakness.“What happened here is a familiar failure,” he said. “Someone writes an internal function and assumes the only thing calling it will be another trusted part of the system, so they don’t sanitize the input the way they would on a public endpoint, because the caller is supposed to be you.” But then, he said, at some point, a change leaves the endpoint reachable from outside, and now a stranger is feeding input to a function written to trust whoever called it. “The code never changed. Its exposure did,” he said.It was the outcome of a pair of colliding decisions, Kenney said. “’This is internal. It doesn’t need hardening’ was fine when it was made and ‘this has to be reachable for the product to work’ was also fine. But nobody went back and checked whether the first was still true after the second happened.”Arista declined a request for more information, saying in an email, “We have no comment beyond what is publicly available in the published CVE.”M&A bluesAnother factor that may have played a role in this situation is that VeloCloud is a relatively new part of Arista’s portfolio, having only been part of the company for a little more than a year. M&A due diligence often doesn’t explore new potential security risks as deeply as it should.“The orchestration layer, often inherited through acquisition, is newer and holds the most privilege over everything downstream,” Kenney pointed out. “Attackers stopped throwing themselves at the hardened data plane and started going after the console that controls it.”To make things worse, VeloCloud passed through VMware and Broadcom before it came to Arista, and by the time code has changed hands that many times, the people who knew which functions quietly assumed a trusted caller are probably gone.“Testing confirms features still work, but it rarely rechecks whether an old internal-only assumption survived the move,” he said.