VeloCloud Orchestrator on KEV: SD-WAN control-plane SQLi and pre-patch hunt notes

On 23 Oct 2026, CISA added CVE-2026-114625 to the Known Exploited Vulnerabilities catalog: SQL injection in Arista VeloCloud Orchestrator (VCO) on-prem. Arista’s Security Advisory 0199 (22 Oct 2026) states the issue is known to be actively exploited, and CISA marks forensic triage required under BOD 26-04.

This is a control-plane problem, not “another edge CVE.” Compromising the orchestrator threatens the confidentiality, integrity, and availability of the orchestrator host and the SD-WAN data it manages.

Use Arista’s advisory for version lists and fixed builds. This post is operator sequencing under engagement constraints.

Snapshot

Arista: no configuration removes exposure of the VCO web interface by default. Network reachability to the portal plus a low-privilege tenant session is enough for the attack path they describe.

Why this matters mid-engagement

SD-WAN orchestrators sit above many sites. On an authorized assessment:

• Finding a login portal is not the finding — version, authz model, and whether you already hold a low-priv tenant session are.
• “Read only” is not safety here. The vendor path is escalation from the lowest built-in tenant role.
• Patching without log review ignores the KEV forensic-triage expectation (BOD 26-04 operator notes).

Industry noise says “Arista KEV.” Engagement state asks: is on-prem VCO in scope, reachable, and which build?

Triage questions

1. In ROE? Network management / SD-WAN / VCO explicitly authorized?
2. On-prem vs hosted? Hosted/Dedicated already patched per Arista — confirm deployment model before burning hours.
3. Version? Against 5.2.x / 6.1.x / 6.4.x affected ranges — not “Arista” as a brand.
4. Session you hold? Enterprise Read Only (or higher) already in hand, or only unauthenticated reachability?
5. What do you pause? Unfinished paths with evidence deserve a pause note — do not abandon them because a new KEV hit the wire.

Operator path

Evidence worth capturing

• Exact VCO software version and deployment model (on-prem vs hosted)
• Role of the session used (Enterprise Read Only vs higher)
• Proof of privileged / internal functionality access within authorization
• Web access log excerpts: unusual URL-like path components, encoded characters, references to local/internal services, bursty request rates (Arista IoC guidance)
• Presence of Arista-listed attack source IPs in logs (advisory lists 74.82.197.86 and 38.54.50.151 — treat as vendor-published IoCs; re-verify on the advisory page)

Pre-patch hunt (BOD-shaped, even for non-federal clients)

If the client is patching under KEV pressure:

• Preserve VCO web access logs, backend application logs, system logs, database logs, and relevant filesystem timestamps before rebuild/upgrade when feasible (Arista guidance).
• Look for unexpected outbound connections from the VCO host, backdoor daemons, webshells, and unexpected administrator changes.
• Restrict portal access to trusted admin networks until the fixed build is live.

What not to write

• Treating Gateway/Edge or EOS switches as vulnerable because the advisory logo says Arista — the advisory’s not-affected list is long for a reason.
• “Unauthenticated RCE” — vendor path requires an authenticated portal session.
• Completeness claims (“all orchestrators checked”) without enumeration evidence.
• Invented post-exploitation narratives not supported by your evidence.

Remediation (short, client-facing)

• Upgrade on-prem VCO to a fixed release in the appropriate train (5.2.3.18+, 6.1.3.10+, 6.4.2.12+).
• Until upgraded: restrict portal reachability; monitor for the published source IPs and anomalous portal traffic; watch outbound from the VCO host.
• After upgrade: keep the forensic question explicit — patch ≠ proof of non-compromise.

Primary sources: CISA KEV alert (23 Oct 2026) and Arista Security Advisory 0199. Verify versions and IoCs there before you file.