Why this matters now
Arista's October 22 advisory (0199) discloses CVE-2026-114625, a SQL injection flaw in on-prem VeloCloud Orchestrator rated CVSS 9.9, and confirms it is being actively exploited. The bar for exploitation is strikingly low: an attacker needs only network access to the orchestrator's web interface and a valid login, and the lowest built-in customer role, Enterprise Read Only, is enough. From there the flaw escalates to operator privileges and impersonation of a local superuser account, with potential impact on the orchestrator host and the data it manages. This is the third VeloCloud Orchestrator flaw reported as exploited in about four months, and the first of the three that requires a login rather than none at all.
That last point is what makes this a hunt, not just a patch ticket. Patching alone does not evict an attacker who already escalated. If a read-only account was abused before the upgrade, the compromise survives the patch, so operators should verify post-patch for lingering compromise, not just a version number. Arista published two IP addresses seen in attacks, 74.82.197.86 and 38.54.50.151, and advises blocking them, hunting web, application, system and database logs, and restricting the web interface to trusted admin networks until patched. Fixed on-prem builds are 5.2.3.18, 6.1.3.10 and 6.4.2.12; hosted and dedicated deployments are already patched, and edge and gateway devices are not affected.
How the attack works
VeloCloud Orchestrator is the central management plane for SD-WAN deployments: it holds site and device configuration, operator accounts, and the data that describes the whole WAN. CVE-2026-114625 is a SQL injection in that management plane. An attacker who can reach the orchestrator's web interface and sign in, even with the Enterprise Read Only role, can inject crafted input that the backend database executes, climbing from read-only visibility to operator privileges and then to impersonation of a local superuser account. At that point the attacker effectively owns the management plane, and from the management plane they can reach into the network it manages.
The technique maps to MITRE ATT&CK T1190 (Exploit Public-Facing Application) for the injection itself, T1078 (Valid Accounts) for the abuse of a legitimate low-privilege login, and T1098 (Account Manipulation) for the privilege escalation and superuser impersonation. Note what this attack does not need: no phishing, no malware drop, no zero-day browser exploit. A stolen or phished read-only credential, or a shared service account with read-only access, is a sufficient starting point, which is why the hunt below starts with identity and access to the management interface rather than endpoint malware.
The KQL hunts
The orchestrator itself is a network appliance, not a Windows endpoint, so its web, application and database logs are the primary evidence. The Defender hunts below cover the telemetry you do have on surrounding hosts: network connections from admin workstations and servers that talk to the orchestrator, and the attacker infrastructure Arista published. Run them over at least 30 days, and treat any hit as a confirmed-compromise investigation, not a low-priority alert.
Hunt 1 — Connections to the published attacker IPs
Start with the two addresses Arista observed in attacks. Any connection from your estate to either address, in either direction, is the strongest single signal in this playbook.
DeviceNetworkEvents
| where TimeGenerated > ago(30d)
| where RemoteIP in ("74.82.197.86", "38.54.50.151")
| project TimeGenerated, DeviceName, InitiatingProcessAccountName, InitiatingProcessFileName, RemoteIP, RemotePort, RemoteUrl
| order by TimeGenerated desc
Hunt 2 — SQL injection strings in web request telemetry
Injection payloads leave fingerprints in request URLs and parameters. Cast this wide across web telemetry, then filter the hits to hosts that manage or reach your orchestrator.
DeviceNetworkEvents
| where TimeGenerated > ago(30d)
| where RemoteUrl has_any ("UNION SELECT", "OR 1=1", "INFORMATION_SCHEMA", "WAITFOR DELAY", "SLEEP(", "xp_cmdshell", "LOAD_FILE")
| project TimeGenerated, DeviceName, InitiatingProcessAccountName, RemoteIP, RemotePort, RemoteUrl
| order by TimeGenerated desc
Hunt 3 — Blast radius: what else did a hit host touch
If Hunt 1 or Hunt 2 fires, map the host's other network activity in the same window. An attacker who owned the management plane will pivot from it, so look for new internal management connections, especially to other network infrastructure.
let SuspectHosts = DeviceNetworkEvents
| where TimeGenerated > ago(30d)
| where RemoteIP in ("74.82.197.86", "38.54.50.151")
| distinct DeviceName;
DeviceNetworkEvents
| where TimeGenerated > ago(30d)
| where DeviceName in (SuspectHosts)
| summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), ConnectionCount = count(), Destinations = make_set(RemoteIP) by DeviceName, InitiatingProcessAccountName
| order by ConnectionCount desc
Hunt 4 — New or unusual access to the orchestrator's management interface
Replace the placeholder with your orchestrator's IP, then look for management-interface connections from devices or accounts that have never touched it before. A read-only account connecting at an odd hour, or from a new admin workstation, deserves the same scrutiny as a failed login spike.
let OrchestratorIP = "203.0.113.10"; DeviceNetworkEvents | where TimeGenerated > ago(30d) | where RemoteIP == OrchestratorIP | summarize FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated), ConnectionCount = count() by DeviceName, InitiatingProcessAccountName, RemotePort | order by FirstSeen asc
Splunk equivalents
SPL 1 — Connections to the published attacker IPs
index=network dest_ip IN ("74.82.197.86", "38.54.50.151")
| table _time, src, dest_ip, dest_port, user, url
| sort _time desc
SPL 2 — SQL injection strings in web requests
index=web (url="*UNION SELECT*" OR url="*INFORMATION_SCHEMA*" OR url="*WAITFOR DELAY*" OR url="*xp_cmdshell*") | table _time, src, dest, user, url, status | sort _time desc
SPL 3 — New talkers to the orchestrator
index=network dest_ip="203.0.113.10" | stats earliest(_time) AS first_seen, latest(_time) AS last_seen, count AS connections by src, user, dest_port | sort first_seen
Triage: what to do when a hunt hits
First, confirm the hit in the orchestrator's own logs. Pull the web, application, system and database logs for the matching window and look for the injected requests, the account that made them, and any role change or superuser session that followed. A Hunt 1 hit on an admin workstation plus a matching superuser session in the orchestrator logs is a confirmed compromise, not a false positive to tune away.
Second, freeze the blast radius. Block the two published IPs at the perimeter, restrict the orchestrator's web interface to trusted admin networks, and disable any read-only or operator account that shows anomalous activity until its owner confirms it. Check whether the orchestrator's configuration, device inventory or managed edge devices changed in the same window, since a superuser can push changes downstream.
Third, do not trust the version number alone. Even after upgrading to a fixed build, review all operator and superuser sessions, role assignments and API activity from before the patch. If any session or account cannot be explained, rotate it and treat the orchestrator as compromised until the review is clean.
Remediation and hardening
Patch on-prem VeloCloud Orchestrator to 5.2.3.18, 6.1.3.10 or 6.4.2.12, matching your release line, and confirm hosted or dedicated deployments are on the patched builds Arista already shipped. Restrict the orchestrator's web interface to trusted admin networks permanently, not just until the patch window closes; a management plane should never be reachable from general user networks. Audit every account with access to the orchestrator, remove stale read-only accounts, and require phishing-resistant multi-factor authentication for operator and superuser roles. Finally, keep orchestrator web, application and database logs in your SIEM with a standing alert on the two published IPs and on SQL injection patterns, so the next exploited management-plane flaw is a detection, not a disclosure.
