CVE-2026-114625: Actively Exploited VeloCloud Orchestrator SQL Injection

THREAT INTELLIGENCE / NETWORK SECURITY

CISA has added CVE-2026-114625, a SQL-injection vulnerability in on-premises Arista VeloCloud Orchestrator (VCO), to its Known Exploited Vulnerabilities catalog. Arista says the issue is being actively exploited and can let an authenticated tenant user obtain operator privileges, reach internal-only functionality, and masquerade as a local superuser operator. Defenders should treat this as an incident-response task, not merely a routine patch ticket.

What happened and what is confirmed

Arista published Security Advisory 0199 on October 22, 2026. CISA added the CVE to the KEV catalog on October 23. The vendor assigns a CVSS v3.1 base score of 9.9 and a CVSS v4.0 base score of 9.4. Those scores come from Arista; they are not estimates created for this article.

The distinction between “authenticated” and “low risk” matters here. Arista says the lowest built-in tenant role is sufficient. An attacker could therefore combine a stolen or abused low-privilege account with this flaw to cross a critical authorization boundary. Because the orchestrator is a management-plane system, a compromise can affect both the VCO host and data managed by the platform.

Which deployments are affected?

Arista identifies these on-premises release ranges as affected:

• VCO 5.2.x releases earlier than 5.2.3.18
• VCO 6.1.x releases earlier than 6.1.3.10
• VCO 6.4.x releases earlier than 6.4.2.12

Arista says hosted VCO services, including Dedicated deployments, were affected but have already been patched. End-of-support versions were not assessed. An unlisted or legacy release must therefore be treated as a manual-review case, not automatically labeled safe. The advisory also states that the web interface is exposed by default and that no product configuration prevents the vulnerable condition.

Defender response playbook

1. Inventory and scope exposure

Start with the control plane, not the edge inventory. Record each VCO’s ownership, deployment model, release, management-interface addresses, internet exposure, identity provider, and the networks allowed to reach its portal. Hosted tenants should still confirm the provider-maintained release state and review their own audit history, even though Arista says hosted instances have been patched.

Do not probe a production orchestrator with SQL-injection payloads. Version evidence, vendor support records, configuration management data, and authenticated administrative inspection are safer ways to establish exposure.

2. Preserve evidence before disruptive changes

If the system is exposed or matches an affected release, preserve evidence before upgrading when operationally feasible. Arista specifically recommends retaining VCO web access logs, backend application logs, system logs, database logs, and relevant file-system timestamps. Capture them in a write-protected evidence location, document collection times in UTC, and calculate hashes so later analysis can distinguish source evidence from working copies.

Also export identity-provider sign-in events, reverse-proxy or WAF logs, DNS telemetry, and outbound firewall records that cover the same period. Management-plane incidents are easier to reconstruct when application, authentication, and network timelines can be correlated.

3. Contain access without destroying evidence

• Restrict the VCO web interface to trusted administrative networks or a controlled jump host.
• Review active sessions and recent changes before invalidating sessions or rotating credentials.
• Monitor and, where appropriate, restrict unexpected outbound connections from the VCO host.
• Coordinate containment with network operations; an abrupt shutdown of the orchestrator may create a larger availability incident.

4. Upgrade to a fixed release

Upgrade within the supported train to 5.2.3.18, 6.1.3.10, 6.4.2.12, or a later release in that train. Organizations on a different or end-of-support train should contact Arista TAC rather than extrapolating a safe version. After the change, verify the displayed build, capture the upgrade record, retest administrative access, and keep heightened monitoring in place. Patching closes the vulnerability; it does not remove persistence an attacker may already have established.

Detection and threat hunting

Arista advises investigating VCO web requests with unusual URL-like path components, encoded characters, references to local or internal services, or abnormal request rates. The vendor also reports two source IP addresses observed in attacks: 74.82.197.86 and 38.54.50.151. Treat these as high-value pivots, not a complete blocklist. Infrastructure can be reused, spoofed in some log contexts, or replaced.

The following shell example performs a literal search across exported text logs. It is intentionally a local evidence-review command, not an exploit test.

grep -RInE '74\.82\.197\.86|38\.54\.50\.151' ./vco-evidence/

# Look for dense encoded input or references to local services.
# Review matches manually; these patterns can produce false positives.
grep -RInE '%[0-9A-Fa-f]{2}.*%[0-9A-Fa-f]{2}|localhost|127\.0\.0\.1|169\.254\.169\.254' ./vco-evidence/

In a SIEM, correlate suspicious web requests with successful authentication, low-privilege tenant accounts, new operator-level actions, unexpected administrator changes, and outbound connections from the VCO. Useful questions include:

1. Did an Enterprise Read Only or similarly limited account perform actions inconsistent with its role?
2. Did a session change privilege, identity, or tenant context without a normal administrative workflow?
3. Did the VCO contact a new external destination shortly after suspicious web activity?
4. Were services, scheduled tasks, startup items, web-accessible files, or local accounts created or changed?

Arista also recommends checking for backdoor daemons and web shells. Validate any suspected artifact against the platform’s expected file inventory and vendor guidance; a filename or process name alone is not sufficient proof of compromise. Teams using Suricata can review our Suricata rule and EVE telemetry validation guide before deploying new network detections. For a comparable management-interface response pattern, see the PAN-OS management-interface patch response.

Hands-on lab: classify VCO versions safely

This lab uses a synthetic CSV inventory and Python’s standard library. It makes no network connections and sends no traffic to a VCO. Run it on an isolated analyst workstation or disposable virtual machine. The comparison logic implements only the three release trains named in Arista Security Advisory 0199; every other train is deliberately marked for manual review.

Prerequisites

• Python 3.8 or later
• A working directory containing no sensitive production exports
• Version values confirmed through approved administrative or configuration-management channels

Create the synthetic inventory

mkdir -p vco-version-lab && cd vco-version-lab
cat > inventory.csv <<'CSV'
asset,version
vco-lab-a,5.2.3.17
vco-lab-b,6.1.3.10
vco-lab-c,6.4.2.11
vco-legacy,4.5.2.7
CSV

Save the classifier

#!/usr/bin/env python3
import csv
import sys

FIXED = {
    (5, 2): (5, 2, 3, 18),
    (6, 1): (6, 1, 3, 10),
    (6, 4): (6, 4, 2, 12),
}

def version_tuple(value):
    parts = value.strip().split(".")
    if len(parts) != 4 or not all(part.isdigit() for part in parts):
        raise ValueError("expected four numeric components")
    return tuple(int(part) for part in parts)

def classify(value):
    parsed = version_tuple(value)
    train = parsed[:2]
    if train not in FIXED:
        return "MANUAL_REVIEW", "release train not assessed by this script"
    fixed = FIXED[train]
    floor = ".".join(map(str, fixed))
    if parsed < fixed:
        return "AFFECTED", f"upgrade to {floor} or later in this train"
    return "FIXED", f"meets the published floor {floor}"

with open(sys.argv[1], newline="", encoding="utf-8") as handle:
    for row in csv.DictReader(handle):
        try:
            state, note = classify(row["version"])
        except ValueError as exc:
            state, note = "ERROR", str(exc)
        print(f'{row["asset"]},{row["version"]},{state},{note}')

Run it and verify the expected output

python3 vco_version_audit.py inventory.csv

# Expected:
vco-lab-a,5.2.3.17,AFFECTED,upgrade to 5.2.3.18 or later in this train
vco-lab-b,6.1.3.10,FIXED,meets the published floor 6.1.3.10
vco-lab-c,6.4.2.11,AFFECTED,upgrade to 6.4.2.12 or later in this train
vco-legacy,4.5.2.7,MANUAL_REVIEW,release train not assessed by this script

If Python reports a missing file, confirm that both files are in the same directory and pass the correct CSV path. If a version returns ERROR, preserve the original inventory value and verify it manually; do not “fix” ambiguous data by guessing. If a train returns MANUAL_REVIEW, consult the advisory and TAC.

Cleanup is simple because the lab has no external dependencies or background processes:

cd ..
rm -rf -- vco-version-lab

The example was locally exercised against the synthetic inventory shown above. It has not been tested against a production VCO export, so adapt field names only after reviewing your approved inventory format.

Post-remediation validation

1. Confirm the installed VCO version meets the fixed floor for its supported train.
2. Confirm the management interface is reachable only through the intended administrative path.
3. Review accounts, sessions, role assignments, API credentials, and recent configuration changes.
4. Check for unexplained outbound connections, persistence, web shells, or new services.
5. Keep the preserved evidence and document the decision that closes each investigative lead.

A clean version check is necessary but not sufficient. If logs show suspicious access or privilege behavior, follow the organization’s incident-response process and engage Arista TAC. Rebuilding or restoring should be based on evidence and a trusted recovery point, not assumed to be unnecessary because the patch installed successfully.

Conclusion

CVE-2026-114625 is a management-plane vulnerability with confirmed active exploitation and a low privilege threshold. The fastest responsible response is to inventory on-prem VCOs, preserve evidence, constrain portal access, hunt for suspicious activity, and upgrade to the vendor-fixed release. Organizations should continue monitoring after remediation because a patch does not retroactively remove attacker access or persistence.

Primary references

• Arista Security Advisory 0199, published October 22, 2026
• CISA KEV addition notice, published October 23, 2026
• CISA Known Exploited Vulnerabilities Catalog
• NVD record for CVE-2026-114625