Read-Only to Operator: CVE-2026-114625 and the Third Exploited VeloCloud Orchestrator Bug Since July
On 22 October 2026 Arista published Security Advisory 0199 for CVE-2026-114625, a SQL injection in on-premises VeloCloud Orchestrator (VCO) that it says is known to be actively exploited. It is the third exploited VCO vulnerability since late July. The first two were unauthenticated and scored CVSS 10.0. This one needs a login, but the login it needs is the weakest one the product has.
If you run an on-prem VCO, the short version is at the bottom. The rest of this post is about why the precondition matters more than the score suggests, and what the three advisories look like side by side.
What the advisory says
Arista’s description is short. A remote attacker may be able to access privileged internal functionality on the VCO, and “any authenticated user can gain operator privileges and masquerade as a local superuser operator user”. The weakness is classified as CWE-89, SQL injection. Arista does not describe the mechanism, and I’m not going to guess at one.
| Item | Detail |
|---|---|
| CVE | CVE-2026-114625 |
| Weakness | CWE-89, SQL injection |
| CVSS 3.1 | 9.9, AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H |
| CVSS 4.0 | 9.4 |
| Published | 22 October 2026, revision 1.0 |
| Status | Known to be actively exploited |
| Discovery | “Detected internally” |
The score is a hair under the two earlier bugs because of one metric: PR:L, low privileges required, where the earlier advisories had PR:N. Everything else is the same shape: network reachable, low complexity, no user interaction, scope changed, full impact on confidentiality, integrity and availability.
The precondition is a low bar
An attacker needs network access to the VCO web interface and a valid authenticated session. Arista states the minimum role is Enterprise Read Only, the lowest built-in tenant role. It also states that VCO is exposed by default and that there is no configuration that prevents the exposure.
Put those together and “authenticated” stops being much of a defence. In a multi-tenant orchestrator the operator role sits above the tenants, so a bug that turns a read-only tenant user into an operator breaks the tenant boundary itself. Arista does not say exactly what operator access exposes beyond “internal-only functionality”, so I can’t tell you what an attacker can do with it. The reasonable planning assumption is the same as for the earlier two bugs: treat it as a path to the host and the data the Orchestrator manages.
It also raises a question the CVSS score doesn’t answer. Who can currently log in to your VCO? Read-only accounts are the ones that get handed out freely: auditors, NOC staff, customer contacts, integration accounts. Every one of those is now a potential starting point, and a shared or stale read-only credential is enough.
Three advisories, three bug classes
This is the part I find most useful, because the three advisories read better together than apart.
| SA 0144 | SA 0183 | SA 0199 | |
|---|---|---|---|
| Published | 27 July 2026 | 22 September 2026 | 22 October 2026 |
| CVE | CVE-2026-16812 | CVE-2026-93952 | CVE-2026-114625 |
| Weakness | CWE-78, OS command injection | CWE-20, input validation | CWE-89, SQL injection |
| CVSS 3.1 | 10.0 | 10.0 | 9.9 |
| Credentials needed | None | None | Any tenant login |
| Other precondition | None | Certificate-based Edge authentication configured | None stated |
| Discovered | Externally | Externally | Internally |
Three different weakness classes in the same management plane inside three months. That is not a single sloppy function being patched repeatedly. It looks like a large attack surface where input handling is the recurring theme, and I’d plan for a fourth rather than assume the pattern ends here. That is a judgement on my part, not something Arista says.
One detail I can only report, not explain: the two earlier advisories say the issue was found externally, and this one says it was detected internally. Arista doesn’t elaborate, so I’d read nothing into it beyond noting the change.
Affected and fixed releases
From SA 0199:
| Train | Affected | Fixed in |
|---|---|---|
| 5.2.x | Before 5.2.3.18 | 5.2.3.18 or later |
| 6.1.x | Before 6.1.3.10 | 6.1.3.10 or later |
| 6.4.x | Before 6.4.2.12 | 6.4.2.12 or later |
| 7.0.x | Not listed | Not listed |
Arista states that if your release is not listed, it is not vulnerable. That puts 7.0 outside this advisory, but I’d word it as “not listed” and confirm with TAC if you run 7.0, because the same train was affected by both earlier bugs. End-of-support releases were not assessed. Hosted and Dedicated VCO were affected and have already been patched.
Now line the fixed builds up against the earlier advisories:
| Train | SA 0144, July | SA 0183, September | SA 0199, October |
|---|---|---|---|
| 5.2 | 5.2.3.14 | 5.2.3.16 | 5.2.3.18 |
| 6.1 | 6.1.3.4 | No fix listed | 6.1.3.10 |
| 6.4 | 6.4.2.4 | 6.4.2.8 | 6.4.2.12 |
| 7.0 | 7.0.0.1 in the affected list, no fix entry | No fix listed | Not listed |
The fixed builds climb at every disclosure, which is the same patch-treadmill pattern I wrote about for Cisco after the Catalyst SD-WAN hardening release and the UAT-8616 advisories. Someone who patched to the July builds and stopped is behind twice over.
There are two things I can’t confirm from the advisories. First, whether the October builds also carry the September fix. Build numbers that sit above the September fixed builds would normally include it, but SA 0199 doesn’t say so. Second, the 6.1 train: SA 0183 listed no 6.1 fix when I last read it, so a 6.1.3.10 deployment has a documented fix for this bug and an undocumented status for CVE-2026-93952. Check the September advisory for revisions and ask TAC if you’re on 6.1 or 7.0. I covered that bug in the September post.
Indicators of compromise
Arista lists two source addresses:
74.82.197.8638.54.50.151
There are no file names or hashes this time, unlike September’s advisory, and Arista gives no single definitive indicator. That matters: an empty result on two IPs is weak evidence. Arista also suggests reviewing VCO web access logs for unusual URL-like path components, encoded characters, references to local or internal services and high request rates, then correlating with backend application, system and database logs. The September indicators (the dropped files, the persistence unit and the other two IPs) are worth checking too, since the same hosts may have been targeted more than once.
A first pass looks something like this. I don’t have an on-prem VCO in the lab, so treat the log paths as a starting point and adjust for your build:
# Known-bad source IPs from SA 0199 in web logs, including rotated and compressed files
zgrep -E '74\.82\.197\.86|38\.54\.50\.151' /var/log/nginx/*access*
# Known-bad source IPs from SA 0183 (September) for completeness
zgrep -E '142\.93\.149\.77|104\.248\.126\.159' /var/log/nginx/*access*
# Anything the VCO host is talking to that it shouldn't be
ss -tnp state establishedYour perimeter firewall or flow logs are a better place for these IP checks than the host, particularly if the host may have been tampered with.
Preserve before you remediate. Arista asks for web, backend, system and database logs plus file-system timestamps to be kept before you upgrade, where that is operationally feasible. Upgrading over the top of a compromised host destroys evidence you’d want later.
Why a VCO compromise is the worst place to lose
I covered where the Orchestrator sits in Part 1 of the Arista/VMware SD-WAN Deep Dive: it is the management plane for the whole estate, and every Edge takes its configuration and policy from it. In Part 2 of the Edge HA series, one of the Edge bugs was scoped down because it required control of a compromised Orchestrator as a starting position. A bug like this one is a way to get that starting position with the lowest credential the product issues. Arista’s own post-remediation guidance for the earlier advisories makes the same point: a compromised VCO may expose the Edges it manages. SA 0199 does not repeat that line, but I would plan on the same assumption.
Edges and Gateways are explicitly not affected by this CVE. The risk to them is second-order, through the Orchestrator.
What to do today
Find out if you’re in scope. On-prem VCO, on 5.2, 6.1 or 6.4, below the fixed builds in the table. If you’re on Hosted or Dedicated VCO, Arista has already patched it.
Patch to 5.2.3.18, 6.1.3.10 or 6.4.2.12. If you’re on 7.0, ask TAC to confirm your status rather than assuming.
Audit who can log in. Review every account on the VCO, read-only ones included, and remove or rotate anything stale or shared. This bug lowers the bar to a single read-only credential.
Take the web interface off anything it doesn’t need to be on. Restrict it to your Edges’ source ranges and admin networks. The Edges need to reach the Orchestrator, so this is scoping, not blocking.
Block the two IPs and hunt before you patch. Check web logs, outbound connections and admin activity first, and preserve logs before upgrading.
If you find anything, assume the Edges are in play. Arista’s guidance from the earlier advisories covers credential rotation, reviewing administrator activity, validating managed device state, and restoring or replacing the Orchestrator from a trusted source.
Three exploited bugs in three different weakness classes, all on the same product, inside three months. Whatever process you stood up in July is worth keeping warm.
Source: Arista Security Advisory 0199, 22 October 2026. Earlier advisories: SA 0144 and SA 0183.