Hunting CVE-2026-114625: What to Look for After the VeloCloud Orchestrator Patch

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.