{"id":8913,"date":"2026-07-29T00:43:54","date_gmt":"2026-07-29T00:43:54","guid":{"rendered":"https:\/\/cybersecurityinfocus.com\/?p=8913"},"modified":"2026-07-29T00:43:54","modified_gmt":"2026-07-29T00:43:54","slug":"arista-patches-maximum-severity-vulnerability-that-is-already-being-exploited","status":"publish","type":"post","link":"https:\/\/cybersecurityinfocus.com\/?p=8913","title":{"rendered":"Arista patches maximum severity vulnerability that is already being exploited"},"content":{"rendered":"
\n
\n
\n
\n
<\/div>\n

Arista has patched a VeloCloud Orchestrator (VCO) security hole that has been actively leveraged in the wild, one that the vendor says \u201cmay allow a remote attacker to access privileged internal functionality and impact the VCO host.\u201d<\/p>\n

The Arista security advisory<\/a> added that the hole \u201cmay compromise the confidentiality, integrity, and availability of the orchestrator and data managed by the orchestrator.\u201d<\/p>\n

Furthermore, it said, \u201cthere is no configuration that can prevent the exposure.\u201d <\/p>\n

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.<\/p>\n

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.<\/p>\n

About as bad as it gets<\/h2>\n

Frank Dickson<\/a>, group VP for security at IDC, described the hole as a \u201cCISO day wrecker.\u201d\u00a0<\/p>\n

\u201cThis is the rare kind of perfect 10 that you never want to see: an unauthenticated command-injection flaw that\u2019s already being exploited in the wild is what CISO have nightmares about,\u201d Dickson said. \u201cTo make things worse, there\u2019s no configuration workaround because the VCO web interface is exposed by default.\u201d<\/p>\n

Consultant Brian Levine<\/a>, executive director of FormerGov, agreed.<\/p>\n

\u201cA CVSS\u201110, unauthenticated command\u2011injection 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,\u201d he said. \u201cThe enterprise implication is straightforward: treat SD\u2011WAN and orchestration platforms as Tier\u20110 assets, restrict their exposure, and patch them with the same urgency you reserve for identity infrastructure.\u201d<\/p>\n

He pointed out, \u201cthis is another reminder that \u2018segmentation\u2019 built on compromised network gear is an illusion. If your control plane is exposed to the internet, you\u2019ve already lost the first battle.\u201d<\/p>\n

Noah Kenney<\/a>, principal consultant at Digital 520, added, \u201cA management plane that an unauthorized stranger can run commands on is close to the worst-case scenario.\u201d<\/p>\n

Concerning questions<\/h2>\n

Giuseppe Trotta<\/a>, principal security researcher at Malwarebytes, also noted that the technical details disclosed raise concerning questions.\u00a0<\/p>\n

\u201cArista<\/a> 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,\u201d 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.<\/p>\n

He added that patch management in this case may be tricky. \u201cThe 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.\u201d<\/p>\n

A familiar failure<\/h2>\n

The consultants and analysts also highlighted Arista\u2019s statement that the functionality being compromised \u201cwas intended to be for internal use only and is not intended to be remotely accessible.\u201d<\/p>\n

\u2018Not intended to be remotely accessible\u2019 isn\u2019t the same as \u2018not remotely accessible,\u2019 IDC\u2019s Dickson said. \u201cThis 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.\u201d<\/p>\n

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.<\/p>\n

\u201cWhat happened here is a familiar failure,\u201d he said. \u201cSomeone writes an internal function and assumes the only thing calling it will be another trusted part of the system, so they don\u2019t sanitize the input the way they would on a public endpoint, because the caller is supposed to be you.\u201d 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. \u201cThe code never changed. Its exposure did,\u201d he said.<\/p>\n

It was the outcome of a pair of colliding decisions, Kenney said. \u201c\u2019This is internal. It doesn\u2019t need hardening\u2019 was fine when it was made and \u2018this has to be reachable for the product to work\u2019 was also fine. But nobody went back and checked whether the first was still true after the second happened.\u201d<\/p>\n

Arista declined a request for more information, saying in an email, \u201cWe have no comment beyond what is publicly available in the published CVE.\u201d<\/p>\n

M&A blues<\/h2>\n

Another factor that may have played a role in this situation is that VeloCloud is a relatively new part of Arista\u2019s portfolio<\/a>, having only been part of the company for a little more than a year. M&A due diligence often doesn\u2019t explore new potential security risks as deeply as it should.<\/p>\n

\u201cThe orchestration layer, often inherited through acquisition, is newer and holds the most privilege over everything downstream,\u201d Kenney pointed out. \u201cAttackers stopped throwing themselves at the hardened data plane and started going after the console that controls it.\u201d<\/p>\n

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.<\/p>\n

\u201cTesting confirms features still work, but it rarely rechecks whether an old internal-only assumption survived the move,\u201d he said.<\/p>\n<\/div>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"

Arista has patched a VeloCloud Orchestrator (VCO) security hole that has been actively leveraged in the wild, one that the vendor says \u201cmay allow a remote attacker to access privileged internal functionality and impact the VCO host.\u201d The Arista security advisory added that the hole \u201cmay compromise the confidentiality, integrity, and availability of the orchestrator […]<\/p>\n","protected":false},"author":0,"featured_media":8914,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-8913","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-education"],"_links":{"self":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/8913"}],"collection":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"replies":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=8913"}],"version-history":[{"count":0,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/posts\/8913\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=\/wp\/v2\/media\/8914"}],"wp:attachment":[{"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=8913"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=8913"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cybersecurityinfocus.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=8913"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}