Arista VeloCloud Edge HA Part 1: How Failover Actually Works, and CVE-2026-86106

Arista VeloCloud Edge HA Part 1: How Failover Actually Works, and CVE-2026-86106

On 9 September 2026 Arista published ten security advisories in one batch: eight against EOS, and four against VeloCloud Edge and Gateway. I’ve already written about Enhanced HA as a design exercise, building a resilient spoke around it, and the Arista/VMware SD-WAN Deep Dive series has covered the wider architecture. Neither of those posts went down into the wire itself: what two Edges actually exchange across the HA link, second by second, to keep one of them silently ready to become the other.

That gap matters now, because the first of the four September CVEs lives entirely inside that channel. CVE-2026-86106 is an unauthenticated command-execution bug in the HA peer protocol, CVSS 3.1 base score 9.6, and you cannot understand why it scores that high, or why Arista’s own mitigation is entirely about cabling rather than configuration, without understanding what the HA link is for and what it assumes about whatever’s talking to it.

Arista’s own framing of this disclosure round is worth noting before getting into the mechanism. The company has said publicly that its own security research increasingly runs through frontier AI models (it’s named Anthropic, Google, and OpenAI models specifically), and that customers should expect “an elevated volume of security advisories and batched releases” for months to come as that pipeline keeps finding things faster than the old process did. I covered the same pattern on the EOS side of the fence when Cisco started doing something similar with its own hardening releases back in August. This is now clearly an industry-wide shift, not a one-vendor story.

Why two Edges in the first place

A VeloCloud Edge is a single point of failure by default: one box, one WAN attachment, one place for the SD-WAN overlay to terminate. High Availability pairs two identical Edges so a hardware fault, a crashed process, or a dead WAN circuit on one of them doesn’t take the site off the overlay. The pair presents to the Orchestrator, and to everything downstream on the LAN, as a single logical Edge. Only the Active member actually talks upward to the control plane; the Standby sits ready, synchronised, and silent until it needs to take over.

That single-logical-Edge illusion is maintained by continuous, private communication between the pair, over a link that exists for no other purpose. Understanding what crosses that link, and what doesn’t get checked when it does, is the whole story.

The HA interconnect

Two Edges in an HA pair are wired together over a dedicated interconnect, normally a single Ethernet port reserved for exactly this (GE1 is the default on most current platforms; older 520/540 boxes use LAN1). Arista’s own administration guide is blunt about how this link should be built: a direct, port-to-port cable between the two Edges, no switch in the middle. The guide states plainly that VeloCloud SD-WAN does not recommend running an L2 switch between the pair’s HA ports, and it sets a hard latency ceiling of 100 milliseconds for the link to stay stable. Non-directly-connected HA pairs (both units homed off a shared switch instead of cabled straight to each other) aren’t a supported configuration at all.

That’s an unusually specific piece of guidance for what looks, on the surface, like an ordinary Ethernet link, and it only makes sense once you know what actually depends on it.

What actually crosses that link

The HA interconnect is not just a heartbeat wire. Four distinct things ride it continuously:

Heartbeats. The Active and Standby exchange a steady heartbeat to prove liveness to each other. The default failure-detection window is 700 milliseconds; since Release 5.2.0 an “HA Failover Detection Time Multiplier” lets you stretch that up to 7 seconds, which matters on Edges pushing enough traffic that heartbeat packets can queue behind everything else.

Configuration sync. Every change pushed from the Orchestrator to the Active Edge is mirrored to the Standby over this same link, so the Standby is never running a stale config when it’s promoted.

Session state sync. Established flow state moves from Active to Standby continuously, which is what lets a failover happen without every session on the wire dying and having to re-establish from scratch.

Routing state sync. Where BGP is configured on the site, locally-learned routes are synchronised across the pair automatically, and an optional BGP Graceful Restart mode lets neighbouring routers hold onto their routes toward this site across a failover instead of flapping them.

None of this is optional or lightly used. A pair that’s actually doing its job is running all four continuously, which is exactly why the interconnect’s own bandwidth needs sizing properly (Arista’s guidance: at least as large as the smaller of the two WAN circuits, if the Active Edge is going to push traffic out through its partner’s local circuit under Enhanced HA).

Which Edge is Active, and how that gets decided

The election isn’t based on uptime, priority weighting, or anything an operator sets explicitly. It’s a deterministic comparison of interface counts: whichever Edge has more configured LAN interfaces (Layer 2 and Layer 3 combined) becomes Active. If that’s a tie, it falls to whichever Edge has more WAN interfaces. And critically, there’s no preemption if the two Edges end up perfectly tied on both counts, meaning the outcome can come down to build order rather than anything meaningful about the hardware.

The practical consequence worth knowing: once a pair has settled on an Active member, a fixed Edge coming back up after an earlier fault does not automatically reclaim the Active role. It rejoins as Standby and stays there. If you’ve ever looked at a healthy HA pair and wondered why the “original” Edge 1 is sitting in Standby months after a single blip, this is why, and it’s working as designed.

The three deployment shapes

Arista supports three wiring models for a pair, and which one you’re running changes what the failure-arbitration story below looks like:

Standard HA puts both Edges on the same WAN-side L2 segment, sharing circuits through an upstream switch. The Standby’s ports sit blocked except for the HA interface itself; the Active one carries everything.

Enhanced HA (the model I built around in the spoke-design post) gives each Edge its own dedicated WAN circuits, no shared L2 required. The Active Edge can still originate traffic over its partner’s local circuit, but it does so by reaching across the HA link to use it, not by sharing a switch port.

Mixed-mode HA combines the two, some circuits shared, some dedicated, within the same pair.

Enhanced HA is the one I’d default to for anything with genuinely diverse WAN transports, precisely because it removes the shared switch as a single point of failure. But it also changes how split-brain has to be caught, which is the piece that matters most here.

Split-brain, and the two independent defences against it

Split-brain is the failure mode HA design exists to prevent: the HA interconnect itself dies (not a WAN circuit, the link between the two Edges specifically) while both units are otherwise healthy, and each one, unable to see its partner, concludes it should become Active. Two Edges both actively forwarding for the same site is not a graceful degradation, it’s a broadcast storm and a genuinely broken network.

Arista layers two independent mechanisms against this, and they cover different topologies:

A Layer 2 broadcast heartbeat. In a Standard HA deployment where both Edges still share an upstream WAN switch even though the direct HA cable has died, the Active Edge sends a broadcast heartbeat (EtherType 0x9999) out across every WAN interface, hunting for its Standby on that shared broadcast domain by means other than the dead direct link.

Gateway-based arbitration. This is the mechanism that actually matters for Enhanced HA, where there’s no shared L2 segment for a broadcast heartbeat to ride. When a second Edge tries to stand up overlay tunnels while believing itself to be Active, the cloud or partner Gateway on the other end recognises that a tunnel already exists from the legitimate Active member. It refuses the second Edge’s tunnel and instructs it to fall back to Standby. Arista’s own documentation calls this out explicitly as the sole means of detecting and preventing split-brain in an Enhanced HA deployment. Without a shared WAN switch to broadcast across, the Gateway sitting at the far end of the overlay is the only thing left in a position to say “no, I already have an Active peer for this site.”

That’s worth sitting with for a second, because it tells you exactly where the trust boundary in this design actually sits. The Gateway arbitrates who gets to claim Active status on the overlay side, where a tunnel has to be legitimately re-established and the Gateway is a real third party with its own view of the world. But nothing arbitrates who gets to speak on the private HA interconnect itself. That link was never designed to need it: it’s a dedicated port-to-port cable, and the entire security model for everything crossing it, heartbeats, config sync, session sync, the peer functions that drive an election or a failover, rests on the assumption that anything transmitting on that wire is, definitionally, the other half of the pair. There’s no handshake to prove that. There’s no certificate, no shared secret, nothing equivalent to the Gateway’s arbitration check for this specific channel. Physical dedication of the link was the security control.

CVE-2026-86106

That assumption is exactly what breaks. Arista’s advisory (Security Advisory 0179) describes CVE-2026-86106 as an authentication bypass affecting VeloCloud Edge units running with HA enabled: an unauthenticated actor with network access to the private HA interconnect can trigger sensitive HA peer functions without any verification at all, leading to elevated command execution on the affected Edge. Given everything above, that’s precisely the failure you’d predict from a channel whose entire security model was “only the real partner Edge is physically wired to this port.” Anyone who can get frames onto that link, not just the legitimate Standby, gets to invoke the same peer functions the real pair uses for election, failover, and sync.

The CVSS 3.1 vector is AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, base score 9.6. Worth walking through why an Adjacent-vector bug (not Network) still lands almost at the ceiling:

AV:A caps this below what a purely remote, internet-reachable bug would score, because you genuinely need Layer 2 access to the dedicated HA port, not just IP reachability to the Edge. That’s the one thing standing between this and a 10.0.

Everything else stacks against you once you have that access. AC:L because triggering it is trivial, not some multi-step race. PR:N and UI:N because the HA peer protocol has no authentication gate at all, so there’s no credential to steal and no user to trick. S:C, Scope Changed, is the detail that pushes this from “a bad HA bug” to “full device compromise”: the vulnerable component is the HA peer-sync mechanism specifically, but exploiting it reaches past that mechanism’s own boundary into command execution on the underlying Edge OS. C:H/I:H/A:H follows directly from that: not degraded HA, not a dropped session, complete compromise of confidentiality, integrity, and availability on the box.

Why the fix is topology, not configuration

There’s no config knob that closes this in already-shipped software, which is why Arista’s interim guidance is entirely about how the cable is run rather than what’s set on it: use a direct, dedicated port-to-port connection for the HA link, and never extend it through a shared switch or a VLAN that anything else can reach. Given the design just walked through, that guidance isn’t a workaround bolted on after the fact, it’s restating the assumption the whole HA channel was built on, because right now that assumption is the only thing standing between a device on the wrong VLAN and a fully compromised Edge.

The real fix is the software update. CVE-2026-86106 is resolved in 7.0.0 and later, 6.4.2 and later on the 6.4.x train, 6.1.5.0 and later on 6.1.x, and 5.2.7.0 and later on 5.2.x. Every version before those is affected, back through the 5.2.6.x, 6.1.4.x, and 6.4.1.x lines and everything earlier.

Part 2 covers the other three CVEs from the same batch, CVE-2026-86107 through CVE-2026-86109, all affecting the same VeloCloud Edge and Gateway software and all resolved in exactly the same set of fixed releases, plus what an upgrade actually needs to cover across all four at once.