Arista VeloCloud Edge HA Part 2: CVE-2026-86107, CVE-2026-86108, CVE-2026-86109, and the Fix
Arista VeloCloud Edge HA Part 2: CVE-2026-86107, CVE-2026-86108, CVE-2026-86109, and the Fix
Part 1 went deep on how HA actually works between two VeloCloud Edges and on CVE-2026-86106, the unauthenticated command-execution bug living inside the HA peer channel. That was the headline CVE of Arista’s 9 September 2026 batch, CVSS 9.6, but it shipped alongside three more VeloCloud Edge and Gateway vulnerabilities in the same round of advisories. None of the three needs the same architectural detour Part 1 took, but all three matter, and all four collapse into a single upgrade decision, which is really the point of this post.
CVE-2026-86107: an out-of-bounds write in VCMP tunnel processing
VCMP is the encapsulation VeloCloud Edges and Gateways use for overlay traffic, the mechanism I covered in detail in Part 3 of the Arista/VMware SD-WAN Deep Dive series: UDP-transported, one tunnel per underlay path per peer. CVE-2026-86107 is an out-of-bounds write (CWE-787) in how both Edge and Gateway reassemble tunnelled IP fragments arriving over an existing VCMP tunnel.
The access requirement is real but not trivial: you need an already-authenticated overlay relationship with the target, meaning you’re either a legitimate peer that’s gone rogue or you’ve compromised one first. From that position, sending specially crafted fragmented packets across the tunnel triggers the bug, and the affected process crashes and restarts, a denial of service rather than code execution. CVSS 3.1 base score is 5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H), the AC:H reflecting that getting a fragmentation pattern to actually hit the bug isn’t a one-shot trivial trigger, and A:H alone in the impact triad because a crashed-and-restarting VCMP process means a real but temporary loss of that tunnel, not data exposure or tampering. There’s no interim mitigation Arista can offer here beyond limiting overlay peer relationships to devices you actually trust and revoking credentials for anything you suspect has been compromised, since the fragment-processing path itself can’t be disabled without breaking the tunnel it’s part of.
CVE-2026-86108: OS command injection via the management workflow
CVE-2026-86108 (CWE-78) sits in VeloCloud Edge’s management and configuration handling: insufficient validation of input supplied through those workflows lets a value that should be treated as ordinary configuration data get interpreted as an operating-system command instead. Successful exploitation runs commands with elevated privileges on the Edge.
Reaching it needs one of two starting positions: control of a compromised Orchestrator, or valid credentials to submit parameters through an already-established management interface. Neither is a bystander’s vantage point, which is reflected in the CVSS 3.1 score of 8.0 (AV:N/AC:H/PR:H/UI:N/S:C/C:H/I:H/A:H), PR:H doing the real work of scoping this down from a 9-plus bug to a high-severity-but-privileged one. The S:C scope change here follows the same shape as Part 1’s HA bug: a flaw in the management-plane input handling reaches past that boundary into full OS-level command execution on the Edge. Until patched, Arista’s guidance is what you’d expect for a privileged-access bug: keep VeloCloud Orchestrator Super Admin and Operator roles restricted to people who genuinely need them, protect Orchestrator credentials properly, and leave the Local UI’s default access restrictions in place rather than loosening them for convenience. None of that closes the hole, it just shrinks who’s in a position to open it.
CVE-2026-86109: a signature-validation gap in the update mechanism
The fourth CVE is arguably the most uncomfortable of the batch, because it’s a flaw in the thing you’d otherwise trust to protect you from the other three: the software update workflow itself. CVE-2026-86109 exists because that workflow doesn’t restrict which digest algorithm gets used to verify an update artifact’s signature before installing it. Left unrestricted, that’s an opening to bypass the signature check altogether and get an unauthorised update installed.
Exploiting it needs either elevated privileges to upload a package to the Orchestrator, or direct credentialed access to an Edge itself, so again this isn’t an anonymous-attacker bug. CVSS 3.1 base score is 6.6 (AV:N/AC:H/PR:H/UI:N/S:U/C:H/I:H/A:H). The practical concern is less the score and more what it protects against: if you can’t trust the update path to reject a maliciously signed artifact, every other patch in this post is only as good as the process that delivers it. Arista’s interim advice is procedural rather than technical, since there’s no config setting that restores digest enforcement early: restrict who can push software updates, protect Orchestrator credentials, source software only through official Arista channels, and watch for update activity nobody meant to trigger.
One advisory batch, one upgrade
Here’s the detail that actually simplifies things: all four CVEs from this batch, Part 1’s HA bypass included, are fixed in exactly the same set of releases. Every affected version line moves to the same targets:
| Train | Fixed in |
|---|---|
| 5.2.x | 5.2.7.0 or later |
| 6.1.x | 6.1.5.0 or later |
| 6.4.x | 6.4.2 or later |
| Any earlier train | 7.0.0 or later |
That means there’s no scenario where you patch three of these and leave one outstanding by accident, provided the upgrade actually happens. A device sitting on any pre-fix build is exposed to all four at once, not a subset, since none of them were introduced at different points in the code’s history that the version table would otherwise split apart.
What to actually do this week
Upgrade first, everything else is a stopgap. Every mitigation across all four advisories, the HA cabling guidance from Part 1 included, is explicitly interim. None of them closes the underlying issue.
Use CloudVision’s Compliance Dashboard to triage the fleet, rather than checking Edge software versions one site at a time. Arista’s own recommendation for this batch was to subscribe to advisory notifications and lean on the dashboard specifically because ten advisories landing on one day makes manual triage impractical past a handful of sites.
Review HA cabling on every affected pair while you’re in there. Part 1’s mitigation for CVE-2026-86106, direct port-to-port HA interconnects with nothing shared or reachable in between, is worth confirming even on sites you’re confident are already built correctly, since it’s the only thing standing between an adjacent attacker and full compromise on unpatched software.
Tighten Orchestrator role assignment, since CVE-2026-86108 and CVE-2026-86109 both narrow to “who has Super Admin, Operator, or upload privilege” as the real gating factor once you’re past the network-position requirement.
Don’t treat this as the last batch. Arista has said plainly that this volume of disclosure is expected to continue for months as its AI-assisted research pipeline keeps finding issues faster than the old cadence did. Whatever process gets this round patched is worth keeping standing, not standing up once and retiring.