CVE-2026-114625 · Arista VeloCloud Orchestrator on-prem authenticated SQL injection to…

01 · The Real Story

Someone handed every janitor in your building a master key — and the lock company says it's already been used

CVE-2026-114625 is an SQL injection flaw (CWE-89) in Arista VeloCloud Orchestrator (VCO) on-premises deployments. Any authenticated user — including those holding the lowest-privilege *Enterprise Read Only* tenant role — can inject SQL to escalate to the internal superuser operator account, unlocking functions intended only for Arista engineering. Affected version trains are VCO 5.2.x before 5.2.3.18, 6.1.x before 6.1.3.10, and 6.4.x before 6.4.2.12. VCO is the centralized management plane for VeloCloud SD-WAN: it pushes routing policies, manages certificates, and controls configurations across every branch Edge device. Compromise of the orchestrator is, by definition, compromise of the entire SD-WAN fabric it manages — potentially hundreds or thousands of branch sites.

Arista self-assigned CVSS 9.9 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H), and that score is honest. The PR:L (low privilege required) is the only friction separating this from a perfect 10.0, and in practice that friction is thin: VCO on-prem instances are internet-facing by design (Edge devices must phone home for zero-touch provisioning), the minimum credential required is the lowest tenant role, and the product has already been hit by two prior unauthenticated zero-days in 2026 (CVE-2026-16812 in July, CVE-2026-93952 in September) — meaning previously compromised orchestrators may already harbor attacker-planted accounts. Arista confirms this CVE is actively exploited and has published attacker IOCs. This is the third critical VCO zero-day in under four months. If you run on-prem VCO, treat this as a hair-on-fire emergency.

"Actively exploited SQLi in VeloCloud Orchestrator gives any read-only tenant superuser control of your SD-WAN fabric"

02 · The Attack Path

5 steps from start to impact.

STEP 01

Acquire low-privilege VCO credentials

The attacker needs any valid VCO account. The advisory explicitly states that the *Enterprise Read Only* role — the lowest possible tenant permission — is sufficient. Credentials can be obtained via phishing a tenant user, credential stuffing against the VCO portal, purchasing them on initial-access broker markets, or — critically — by leveraging a prior VCO compromise via CVE-2026-16812 or CVE-2026-93952 to plant a persistent backdoor account.

Conditions required:

Valid VCO user account (any role, including Enterprise Read Only)

Where this breaks in practice:

Requires at least one valid credential — but VCO is a multi-tenant platform with many tenant users, expanding the target surface
Prior unauth VCO zero-days (CVE-2026-16812, CVE-2026-93952) may have already provided persistent access

Detection/coverage: Monitor VCO login logs for logins from IOC IPs (74.82.197.86, 38.54.50.151) or unusual geolocations

STEP 02

Authenticate to VCO web portal

The attacker logs into the VCO web interface over HTTPS. VCO on-prem must be internet-reachable for SD-WAN Edge zero-touch provisioning, so the web portal is exposed by design. No VPN, no bastion — just a standard HTTPS login page accessible from anywhere on the internet.

Conditions required:

Network access to VCO web interface (internet-facing by default)

Where this breaks in practice:

If the defender has restricted the VCO admin portal to a trusted network segment (separate from the Edge provisioning channel), this step requires internal network position — but this is a non-default hardening measure

STEP 03

Inject SQL to escalate to superuser operator

From the authenticated low-privilege session, the attacker crafts an SQL injection payload targeting a vulnerable VCO API endpoint. The injection allows the attacker to masquerade as the internal superuser operator user, bypassing all role-based access controls. Attack complexity is Low per the CVSS vector — no race conditions, no special payload encoding, no chained prerequisites beyond the authenticated session.

Conditions required:

Authenticated session from Step 2
Knowledge of the vulnerable API endpoint (Arista reports active exploitation, suggesting this is well-understood by threat actors)

Where this breaks in practice:

No public PoC exists yet on GitHub or pocindex.io, so opportunistic script kiddies are currently gated — but active exploitation confirms sophisticated actors already have working exploits

Detection/coverage: WAF with SQL injection detection rules *may* flag anomalous query patterns, but VCO API traffic is application-specific and generic SQLi signatures may miss parameterized injections

STEP 04

Access internal-only orchestrator functions

With superuser operator privileges, the attacker can access functions reserved for Arista engineering: full database access, certificate management, Edge device configuration push, credential extraction, and orchestrator system-level operations. This is the equivalent of root on the SD-WAN control plane.

Conditions required:

Superuser operator session from Step 3

Where this breaks in practice:

None — once escalation succeeds, all internal functions are unlocked

Detection/coverage: Audit VCO admin activity logs for unexpected role changes, configuration exports, or certificate operations by non-operator accounts

STEP 05

Compromise managed SD-WAN infrastructure

From the orchestrator, the attacker pushes malicious routing configurations or firmware to all connected VeloCloud Edge appliances, exfiltrates stored credentials and certificates, or pivots into branch networks. A single VCO instance can manage hundreds to thousands of Edge devices across an enterprise's entire WAN fabric. The blast radius is fleet-scale: every branch site, every tunnel, every routing policy.

Conditions required:

Superuser operator access from Step 4
VCO managing active Edge devices (the normal operational state)

Where this breaks in practice:

None — this is the designed function of VCO

Detection/coverage: Monitor for unexpected outbound traffic from VCO, configuration drift alerts on Edge devices, and webshell indicators on the VCO host

03 · Compensating Control

CRITICAL 9.5→HIGH 7.5

SEVERITY REDUCED

ACL-restrict VCO web portal to trusted admin networks — Separate the VCO administrative web interface from the Edge provisioning channel. Place the admin portal behind a VPN or IP allowlist restricted to your NOC/SOC subnets. Edge devices can communicate on dedicated API endpoints that don't expose the full admin UI. This is the single highest-impact mitigation — it eliminates the internet-reachable attack surface for the SQLi chain. Deploy within 3 days per the noisgate mitigation SLA for CRITICAL findings. However, this requires architectural work to split admin and provisioning traffic, which not all deployments support out of the box.

CRITICAL 9.5→CRITICAL 9.0

Block known attacker IPs at perimeter firewall — Immediately add 74.82.197.86 and 38.54.50.151 to your perimeter deny list and VCO host-based firewall. This blocks the *currently observed* campaign but does not protect against new source IPs. Deploy within hours — this is a zero-cost, zero-risk immediate action.

CRITICAL 9.5→HIGH 7.0

SEVERITY REDUCED

Enforce MFA on all VCO portal logins — If your VCO deployment supports SAML/SSO integration, enforce multi-factor authentication for all VCO users. This raises the bar for credential-based attacks from simple password reuse to requiring a second factor. Deploy within 3 days. Note: this does not stop attackers who already have session tokens or who compromised VCO via prior unauth vulns.

CRITICAL 9.5→CRITICAL 8.5

Audit and minimize VCO user accounts — Review all VCO tenant and operator accounts. Remove any unused, shared, or service accounts. Reduce the Enterprise Read Only user population to the operational minimum. Every valid credential is a potential entry point for CVE-2026-114625. Deploy within 3 days.

CRITICAL 9.5→IGNORE 0.0

SEVERITY REDUCED

Patch to VCO 5.2.3.18 / 6.1.3.10 / 6.4.2.12 — Apply the vendor patch. This is the only complete remediation. Arista has already patched hosted/dedicated instances; on-prem customers must self-update. Per the noisgate remediation SLA for CRITICAL findings, complete patching within 90 days — but given active exploitation, push for immediate patching during the next maintenance window.

What doesn't work

Generic WAF SQL injection rules — VCO uses proprietary API endpoints with application-specific request formats. Generic SQLi signatures (e.g., OWASP CRS) are unlikely to catch parameterized injection payloads targeting VCO's internal API surface without custom rules tuned to VCO traffic patterns.
Disabling internet access to VCO — VCO on-prem *must* be internet-reachable for Edge zero-touch provisioning. Cutting internet access breaks SD-WAN operations entirely. The correct approach is to segment admin traffic from provisioning traffic, not to block all inbound.
Revoking all Enterprise Read Only accounts — while this would eliminate the attack surface, it removes tenant visibility into their own SD-WAN environment. Operationally impractical for most deployments.

04 · Intelligence Metadata

The supporting signals.

In-the-wild exploitation	Confirmed active. Arista Security Advisory 0199 (October 22, 2026) states the flaw "was detected by Arista and is known to be actively exploited." Attacker IPs published: `74.82.197.86` and `38.54.50.151`. This is the third actively exploited VCO zero-day in 2026 (after CVE-2026-16812 in July and CVE-2026-93952 in September).
Proof-of-concept availability	No public PoC found. Checked pocindex.io, GitHub CVE-2026-PoC repositories (SecureWithUmer, XZ1r0), ExploitDB, and Nuclei templates — no dedicated exploit code for CVE-2026-114625. However, active exploitation confirms working exploits exist in threat-actor toolkits.
EPSS score	Not yet scored. CVE-2026-114625 returns empty from the FIRST EPSS API as of October 22, 2026 — the CVE was disclosed today. Expect a high EPSS score once the model ingests the active-exploitation signal.
CISA KEV status	Not listed as of October 22, 2026. However, both prior VCO vulns were added to KEV (CVE-2026-16812 on July 27, CVE-2026-93952 in September). KEV addition is likely imminent given confirmed active exploitation.
CVSS vector	CVSSv3.1: 9.9 — `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H`. CVSSv4.0: 9.4 — `CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H/SC:H/SI:H/SA:H`. The `S:C` (Scope: Changed) in v3.1 reflects that compromising VCO impacts downstream Edge devices beyond the orchestrator itself. The only mitigating factor versus a 10.0 is `PR:L` (requires any valid credential).
Affected versions	VCO 5.2.x before 5.2.3.18, VCO 6.1.x before 6.1.3.10, VCO 6.4.x before 6.4.2.12. Arista hosted and dedicated VCO instances were patched by Arista prior to disclosure. Only on-premises deployments remain vulnerable.
Fixed versions	VCO 5.2.3.18, VCO 6.1.3.10, VCO 6.4.2.12. No fix mentioned for the 7.0.x train — contact Arista support if running 7.0.x.
Installed base & exposure	VeloCloud serves ~20,000+ enterprise customers (Arista acquisition data). VCO on-prem instances are internet-facing by design — Edge devices require HTTPS connectivity to the orchestrator for zero-touch provisioning. No Shodan/Censys count was found, but the architectural requirement for internet exposure means effectively all on-prem VCOs have an attack-reachable web interface.
Disclosure date	October 22, 2026 — same-day disclosure and patch release via Arista Security Advisory 0199.
Discovery	Detected internally by Arista during threat monitoring. No external researcher credited. The advisory notes the flaw was found because Arista observed active exploitation activity.

Sources.

05 · The Call

Final Verdict

= UNCHANGED to CRITICAL (9.5/10)

Why this verdict

Active exploitation confirmed: Arista discovered this CVE *because* they observed it being exploited in the wild, with published IOC IPs. This is not a theoretical risk — it is a current operation against VCO on-prem instances.
Authentication friction is paper-thin: The PR:L requirement sounds like a gate, but the minimum credential is *Enterprise Read Only* — the lowest-privilege tenant role, widely distributed across customer organizations. Moreover, two prior unauth VCO zero-days in 2026 (CVE-2026-16812, CVE-2026-93952) mean previously compromised orchestrators may already harbor attacker-planted accounts, effectively reducing this to PR:N for repeat victims.
Internet-exposed by design: VCO on-prem must be internet-reachable for SD-WAN Edge zero-touch provisioning. Unlike most enterprise apps where 'restrict to internal network' is the default, VCO's architecture *requires* external connectivity. This eliminates the most common network-level friction point.
Role multiplier — SD-WAN orchestration plane (canonical high-value role): VeloCloud Orchestrator is *definitionally* a network-edge management appliance. 100% of VCO instances occupy the high-value role — it IS the SD-WAN control plane. A compromised VCO can push malicious configurations to every connected Edge device, exfiltrate all stored certificates and credentials, and pivot into every branch network. The blast radius is fleet-scale: one orchestrator controls hundreds to thousands of branch sites. This floors the verdict at CRITICAL per the deployment-role rule.
Repeat targeting pattern: This is the third critical VCO zero-day in four months. Threat actors are systematically targeting VeloCloud Orchestrator as a high-value pivot point. The cadence suggests either a dedicated adversary with deep product knowledge or a fundamentally weak codebase yielding to sustained research.

Why not higher?

A score of 10.0 would require unauthenticated access (PR:N). CVE-2026-114625 requires at least a low-privilege credential (PR:L), which is a real — if thin — gate. Unlike CVE-2026-16812 (CVSS 10.0, no auth required), this CVE cannot be exploited by a completely anonymous internet attacker without first obtaining a valid VCO account. The 0.5-point reduction from 10.0 to 9.5 reflects this single friction point.

Why not lower?

Any downgrade below CRITICAL is blocked by the deployment-role floor. VCO is canonically a high-value-role component — it is the SD-WAN management plane for every customer that deploys it. The blast radius on successful exploitation is fleet-scale (all managed Edge devices, all branch networks, all stored credentials). Active exploitation is confirmed with published IOCs. The authentication requirement is the weakest possible (lowest tenant role), and the product is internet-facing by architectural necessity. There is no plausible reading of this CVE that lands below CRITICAL.

06 · Verification

Crowdsourced verification payload.

Run this script on the VCO on-prem appliance itself via SSH as root. Usage: bash check_cve_2026_114625.sh. No arguments needed. Requires read access to VCO version files (standard root privileges on the appliance).

noisgate-verify.sh

BASHREAD-ONLYSAFE

#!/usr/bin/env bash
# CVE-2026-114625 — Arista VeloCloud Orchestrator SQL Injection
# Checks installed VCO version against patched releases.
# Run ON the VCO appliance as root via SSH.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

set -euo pipefail
TAG="CVE-2026-114625"

# Attempt to determine VCO version from known locations
VCO_VER=""
if [ -f /opt/vc/VERSION ]; then
    VCO_VER=$(cat /opt/vc/VERSION 2>/dev/null | tr -d '[:space:]')
elif [ -f /opt/vc/lib/node_modules/velocloud-orchestrator/package.json ]; then
    VCO_VER=$(grep -oP '"version"\s*:\s*"\K[^"]+' /opt/vc/lib/node_modules/velocloud-orchestrator/package.json 2>/dev/null || true)
elif command -v vco-version &>/dev/null; then
    VCO_VER=$(vco-version 2>/dev/null | tr -d '[:space:]')
fi

if [ -z "$VCO_VER" ]; then
    echo "[$TAG] UNKNOWN — could not determine VCO version."
    echo "Verify this host is a VCO on-prem appliance."
    exit 2
fi

echo "[$TAG] Detected VCO version: $VCO_VER"

# Compare versions using sort -V
ver_lt() {
    [ "$(printf '%s\n' "$1" "$2" | sort -V | head -n1)" = "$1" ] && [ "$1" != "$2" ]
}

RESULT="UNKNOWN"
case "$VCO_VER" in
    5.2.*)
        if ver_lt "$VCO_VER" "5.2.3.18"; then RESULT="VULNERABLE"
        else RESULT="PATCHED"; fi
        ;;
    6.1.*)
        if ver_lt "$VCO_VER" "6.1.3.10"; then RESULT="VULNERABLE"
        else RESULT="PATCHED"; fi
        ;;
    6.4.*)
        if ver_lt "$VCO_VER" "6.4.2.12"; then RESULT="VULNERABLE"
        else RESULT="PATCHED"; fi
        ;;
    7.0.*)
        RESULT="VULNERABLE"
        echo "[$TAG] WARNING: No patch available for 7.0.x train. Contact Arista."
        ;;
    *)
        echo "[$TAG] UNKNOWN — unrecognized version train: $VCO_VER"
        exit 2
        ;;
esac

echo "[$TAG] $RESULT"
case "$RESULT" in
    VULNERABLE) exit 1 ;;
    PATCHED)    exit 0 ;;
    *)          exit 2 ;;
esac