On October 22, 2026, Arista disclosed CVE-2026-114625, a critical SQL injection flaw in the on-premises VeloCloud Orchestrator (VCO), the management plane for its SD-WAN fleet. Arista says it is known to be actively exploited. The Hacker News reports a CVSS score of 9.9, and describes it as the third VCO flaw Arista has flagged as exploited since July.

The pattern matters more than any single bug. If the system that controls your branch connectivity has produced three exploited zero-days in about four months, this is no longer a patching event. It is a question about how you govern a high-privilege control plane that sits close to the internet.

What Happened

According to The Hacker News, the flaw lets someone with any valid VCO login, including a read-only customer account, escalate to operator privileges. The lowest role mentioned is Enterprise Read Only, and the attacker needs network access to the web interface. That is a lower bar than the two earlier flaws, which reportedly needed no login at all, but credentials are routinely stolen, reused or shared with contractors.

Arista says the affected releases are VCO 5.2.x before 5.2.3.18, 6.1.x before 6.1.3.10 and 6.4.x before 6.4.2.12. Hosted and Dedicated orchestrators have already been patched by Arista. Releases outside those trains, including 7.0, are reported as not vulnerable, and VeloCloud Gateway and Edge are not affected. Arista has not assessed end-of-support releases, so customers on those need to contact Arista support directly.

Timeline

  • July 2026: CVE-2026-16812, scored CVSS 10.0, is patched and reported as exploited. CISA added it to its Known Exploited Vulnerabilities (KEV) catalog and set a federal deadline of July 30.
  • September 2026: CVE-2026-93952, also reported as CVSS 10 and exploited, is patched. SecurityWeek reports CISA added it to KEV with a three-day federal deadline.
  • October 22, 2026: Arista publishes the advisory for CVE-2026-114625 and fixed builds.

Confirmed vs Still Unclear

Reported consistently across sources: the CVE id, the SQL injection class, the three fixed builds, that on-premises VCO is affected, that hosted instances are patched, and that Arista states exploitation is known.

Unclear or inconsistent:

  • Arista has not said when attacks began, how many orchestrators were hit, who is behind them, or what attackers did after gaining access.
  • The count is reported differently. Several outlets say third in four months. SC Media, citing BleepingComputer, calls it Arista's fourth exploited zero-day this year. I could not reconcile the two, so I use the narrower VCO count and attribute it.
  • I did not find confirmation that CISA has added CVE-2026-114625 to KEV. Check the catalog directly.
  • I could not read Arista's advisory itself, so details here come from press and analyst summaries of it. The Aviatrix page I read is a security vendor's analysis, and its risk ratings are its own opinion.

Why This Is a GRC Problem

1. Management planes are your most privileged assets

An SD-WAN orchestrator pushes configuration to every site. Compromising it can mean changing routing, policy and device settings at scale. If your asset register classifies it like any other server, your risk tiering is wrong.

2. Exposure by default is a design decision you own

Reports say the VCO web interface is exposed by default and no configuration change prevents this flaw. Arista does say restricting access to administrative networks reduces exposure. That is your control to apply, and auditors will ask whether you did.

3. Repeat vendor failures belong in the vendor risk file

Three exploited flaws in one product line within four months is evidence. Third-party risk reviews should record it, ask for the vendor's root cause and hardening plan, and set a threshold at which you review the product's place in your architecture.

4. Patch SLAs for administrative platforms

Your critical-patch SLA should name management planes explicitly. A flaw that needs only a low-privilege login still belongs in the emergency lane when it is exploited in the wild.

5. Evidence preservation

Arista guidance relayed by the press says to preserve web, application, system and database logs and file timestamps before remediating a suspected compromise. If your logging for the orchestrator is local only, you may have little to preserve.

6. Reduced detection confidence

Earlier VCO advisories reportedly had no single clear indicator of compromise. Expect the same here. Absence of an alert is weak evidence.

Also This Week: HTTP2Shell (CVE-2026-111497)

A second item deserves a place on the same patch list. CVE-2026-111497 is an out-of-bounds write in the Brotli decompression library. It surfaced as "Node2Shell" after Node.js shipped fixes on October 21 and is now being called "HTTP2Shell" because so many HTTP clients, servers and proxies bundle Brotli. Brandefense and Phoenix Security both stress that the name is a nickname, not an HTTP/2 protocol flaw and not a second bug.

What is reported:

  • Fixed Node.js builds are 22.23.4, 24.22.1 and 26.12.1. Node.js 20 and earlier are end of life and reportedly get no fix. Upstream Brotli fixes are 1.2.1, 1.1.1 and 1.0.10.
  • Python packages need Brotli 1.2.1 or brotlicffi 1.2.1.0, and Bun needs 1.4.4, with compiled executables rebuilt.

What is disputed:

  • Severity differs by publisher. Phoenix and Aikido cite a CVSS 4.0 score of 9.2. The Hacker News says Node.js rates it High, and Phoenix notes Red Hat scores it 8.1 on CVSS 3.1.
  • No in-the-wild exploitation was reported as of October 22 to 24, and Brandefense says it was not in CISA KEV as of October 23. Public proof-of-concept code exists. Whether it yields code execution on a normal build is contested. The Hacker News says only a weakened test build reached code execution, while Phoenix and Aikido say Imperva reported it on an unmodified Node.js 24.22.0 build. Plan for code execution without assuming it.

The GRC lesson is different from the Arista one. This is a dependency you probably cannot list. Brotli lives inside runtimes, container images, language packages and vendored source, so a manifest scan can miss it, and distribution backports can make version checks misleading. Unpatched exposure also reaches servers that decode Brotli request bodies and clients that fetch from servers you do not control.

Control Mapping

FrameworkRelevant control area
NIST CSF 2.0ID.AM (asset inventory), ID.RA (risk assessment), GV.SC (supply chain risk), PR.PS (platform security), DE.CM (monitoring)
ISO/IEC 27001:2022A.8.8 Management of technical vulnerabilities, A.8.20 Networks security, A.5.19 to A.5.22 Supplier relationships
SOC 2CC6.1 (logical access), CC7.1 (vulnerability detection), CC9.2 (vendor risk)

Action Plan

Next 24 hours

  • Identify every on-premises VCO instance, its release train and version. Confirm whether any run an unsupported release.
  • Upgrade to 5.2.3.18, 6.1.3.10, 6.4.2.12 or later, or move to a fixed release train per Arista guidance.
  • Restrict the web interface to trusted administrative networks now, and review who holds any VCO account, read-only ones included.
  • Take the current indicators and blocking guidance from Arista's advisory, not from secondary sites.
  • Preserve logs before any rebuild or cleanup.
  • For HTTP2Shell, upgrade Node.js, Bun, Python Brotli packages and any Envoy or Istio that decodes Brotli, then restart the processes. Where your application allows, stop auto-decoding Brotli from untrusted sources, as Red Hat advises.

Next 7 days

  • Review administrator activity, new accounts, privilege changes and unexpected outbound connections from the VCO host.
  • Rotate credentials for VCO users and any secrets the orchestrator holds, starting with accounts held by third parties.
  • Ask your reseller or managed service provider in writing for their patch status.
  • Check KEV for both CVEs and record your remediation date against any deadline.
  • Find bundled Brotli in container images, SBOMs, compiled binaries and vendored source, not just package manifests. Recheck distribution advisories, since their status was changing daily.

Next 90 days

  • Add management planes as a named asset class with a shorter patch SLA and stricter access rules.
  • Ship orchestrator logs to a central system you control.
  • Document a vendor risk decision on Arista VeloCloud: continue with compensating controls, or plan alternatives.
  • Retire or formally risk-accept end-of-life Node.js lines, and make SBOM coverage of bundled libraries a tracked metric.

Final Thoughts

For Arista, the fix is a version bump. The harder work is deciding that the box which configures your network deserves tighter exposure, faster patching and better logging than the boxes it configures. Teams that already did that will treat this as routine.

Details on scope, attribution, severity and KEV status may change, so confirm everything against Arista's advisory and official government guidance before acting on any single article, including this one.

Sources