Patching Arista VeloCloud Orchestrator to 5.2.3.18, 6.1.3.10 or 6.4.2.12 closes the CVE-2026-114625 SQL injection, but it does not answer the question most operators will ask next: did anyone already use it? Arista reports active exploitation, and the advisory notes that successful abuse may reach the VCO host itself, so the review has to cover both the application and the underlying system.
Why the patch is not the end of the job
The flaw lets any authenticated user, including the lowest built-in role, escalate to a local "superuser operator". An attacker who reached that role could act on configuration the tenant was never meant to touch, and Arista warns that internal-only functionality becomes reachable. Anything an operator could have changed before the upgrade stays changed afterwards.
Signals worth collecting
Arista's guidance is concrete and short. Review VCO web access logs for unusual URL paths, encoded characters and high request rates; watch for unexpected outbound traffic from the orchestrator host; look for backdoor daemons and web shells; and check recent administrator activity for changes nobody admits to making.
Two IP addresses have been reported in connection with the attacks: 74.82.197.86 and 38.54.50.151. Search those addresses across VCO logs and perimeter devices, then widen the search to the timeframe around any hit rather than the single matching line.
The injection itself arrives through the web interface, so the useful log fields are the request path, query parameters, authenticated user, source address and response code. Encoded or double-encoded payload fragments in a parameter that normally takes an identifier are worth a review even when the response was a 403; attempted exploitation still tells you which accounts are being probed.
Sequencing that avoids destroying evidence
If compromise is suspected, preserve logs and file timestamps before patching. The upgrade may rotate services, replace files and change permissions, and a host rebuilt without a copy of its original log set cannot be compared later.
A practical order: export VCO web and system logs, snapshot the orchestrator's process list and listening sockets, record file modification times under the web root, then apply the vendor fix. Only after the evidence copy exists should the host be rebuilt or hardened.
Closing the exposure that made this reachable
Arista states that VCO is exposed by default and that no configuration removes the exposure. Removing inbound reachability, rather than trusting a product setting, is therefore the control that matters. A ZoomEye query for title="VeloCloud" returned 520 matching assets on 22 October 2026; the number measures visible product-family interfaces, not confirmed vulnerable builds. It is still a useful reminder that these consoles should not be answering from the public internet unless there is a documented reason.
References
Arista Security Advisory 0199: https://www.arista.com/en/support/advisories-notices/security-advisory/24838-security-advisory-0199
CVE.org record for CVE-2026-114625: https://cveawg.mitre.org/api/cve/CVE-2026-114625
The Hacker News report: https://thehackernews.com/2026/10/arista-warns-of-critical-velocloud-sql.html
SecurityOnline hunting guidance: https://securityonline.info/velocloud-orchestrator-cve-2026-114625-exploited/