Arista VeloCloud Orchestrator Zero-Day Exploited: Third Unpatched SQL Injection Flaw in Four Months — Detection and Mitigation Guide

Arista Networks has confirmed a third actively exploited zero-day vulnerability in VeloCloud Orchestrator (VCO) within a four-month window — a pattern that should alarm every organization running VeloCloud SD-WAN infrastructure. The latest flaw is a critical-severity SQL injection vulnerability that allows an unauthenticated or low-privileged attacker to reach privileged internal functionality and ultimately obtain operator privileges on the orchestrator itself.

Let me be blunt about what that means in practice: the VeloCloud Orchestrator is the central management and control plane for your entire SD-WAN fabric. It holds the configuration, credentials, certificates, routing policies, and lifecycle management for every edge device in your deployment. An attacker with operator privileges on VCO doesn't just own a server — they own your wide-area network. They can push malicious configuration to thousands of edges, redirect traffic through attacker-controlled infrastructure, disable segmentation policies, and pivot into every site the fabric touches.

Three exploited zero-days in four months tells us two things. First, threat actors have clearly prioritized VeloCloud Orchestrator as a target class — this is no longer opportunistic scanning, it's a sustained campaign against the management plane. Second, the product's attack surface around its web/API tier is getting serious adversarial scrutiny, and defenders should assume more issues are coming.

Technical Analysis

Affected Product

• Product: Arista VeloCloud Orchestrator (VCO) — both Arista-hosted and self-hosted (on-premises) orchestrator deployments are the primary concern. Self-hosted instances carry the highest risk because patch cadence and exposure are entirely under the customer's control.
• Component: The orchestrator's web application / API tier. VCO is built on a Java/Tomcat stack, and the vulnerable code path sits in request-handling logic that fails to properly sanitize user-supplied input before it reaches backend database queries.

Arista has not yet published a public CVE identifier for this flaw at the time of writing. Defenders should track Arista's security advisory portal and the SecurityWeek reporting (linked below) for the assigned identifier once released — do not wait for the CVE to begin mitigation.

How the Vulnerability Works

From a defender's perspective, the attack chain looks like this:

1. Initial access via the VCO web/API interface. The attacker sends crafted requests to exposed orchestrator endpoints containing SQL injection payloads in parameters that are concatenated — rather than parameterized — into backend queries.
2. SQL injection execution. The injected SQL executes in the context of the orchestrator's database service account, which has broad read/write access to the VCO application database (tenant configurations, operator accounts, edge certificates, API tokens).
3. Privilege escalation via internal functionality. By manipulating query results or invoking privileged internal functions (the flaw allows attackers to "access privileged internal functionality"), the attacker escalates from an injection primitive to operator-level privileges within the VCO application.
4. Full SD-WAN control. As an operator, the attacker can enumerate all enterprises/tenants, modify edge configurations, inject routes, harvest credentials, and create rogue operator accounts for persistence.

Exploitation Status

• Confirmed active exploitation in the wild. This is not a theoretical or proof-of-concept scenario — Arista has characterized this as an exploited zero-day, which is precisely why it was disclosed ahead of a full patch in some deployment models.
• Third exploited VCO flaw in four months. The cadence strongly suggests a focused adversary (or multiple actors) systematically auditing the orchestrator's web tier. Expect scanning and exploitation attempts to intensify now that the flaw is public, including against internet-exposed self-hosted instances.
• CISA KEV status: Monitor the CISA Known Exploited Vulnerabilities catalog — given confirmed exploitation and the criticality of network management infrastructure, a KEV listing with a federal remediation deadline is a realistic near-term outcome.

The Real Risk: Your Management Plane Is a Single Point of Compromise

I've led IR engagements where the management plane — not the endpoints — was the initial blast radius. When an SD-WAN orchestrator falls, traditional EDR is blind. The edges are doing exactly what the orchestrator tells them to do; nothing looks "malicious" because the configuration is being pushed through a trusted channel. Detection has to happen at the orchestrator tier and in the network telemetry around it.

Detection & Response

Immediate Triage Questions for Your SOC

• Do we run self-hosted VeloCloud Orchestrator? What version/build?
• Is the VCO management interface reachable from the internet, or is it restricted to management VPNs/jump hosts?
• Are VCO application and web access logs being forwarded to our SIEM? (For many organizations, the honest answer is no — fix that today.)
• Do we have an inventory of legitimate operator accounts and API tokens to diff against?

Sigma Rules

The following rules target the most reliable observable behaviors for this attack class: SQL injection patterns against the orchestrator's web tier, and post-exploitation persistence via rogue account or token creation. Tune the log source to your web/proxy log pipeline (VCO access logs ingested via Syslog/CEF, or upstream reverse-proxy logs).

---
title: SQL Injection Attempt Against VeloCloud Orchestrator Web Interface
id: 8f2c1a94-3d7b-4e5a-9c61-2b4d8e6f0a12
status: experimental
description: Detects common SQL injection patterns in HTTP requests directed at VeloCloud Orchestrator web and API endpoints. Critical given confirmed in-the-wild exploitation of a VCO SQL injection zero-day.
references:
  - https://www.securityweek.com/attackers-exploit-third-velocloud-orchestrator-zero-day-in-four-months/
  - https://attack.mitre.org/techniques/T1190/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.initial_access
  - attack.t1190
logsource:
  category: webserver
detection:
  selection_uri:
    cs-uri|contains:
      - '/portal/'
      - '/api/'
      - '/rest/'
  selection_payload:
    cs-uri-query|contains:
      - '%27%20OR%20'
      - '%27%20AND%20'
      - 'UNION%20SELECT'
      - 'union+select'
      - 'information_schema'
      - 'SLEEP%28'
      - 'BENCHMARK%28'
      - 'UPDATEXML'
      - 'EXTRACTVALUE'
      - '%3B--'
      - 'concat%28'
  condition: selection_uri and selection_payload
falsepositives:
  - Vulnerability scanners and authorized penetration tests (whitelist scanner source IPs)
level: high
---
title: Rogue Operator Account or API Token Creation on VeloCloud Orchestrator
id: 3b7e5d21-9a4f-4c8e-b2d6-7f1a3c5e9d04
status: experimental
description: Detects audit events indicating creation or modification of operator/superuser accounts or API tokens on VeloCloud Orchestrator, a primary persistence mechanism after SQL injection exploitation.
references:
  - https://www.securityweek.com/attackers-exploit-third-velocloud-orchestrator-zero-day-in-four-months/
  - https://attack.mitre.org/techniques/T1136/
author: Security Arsenal
date: 2026/04/06
tags:
  - attack.persistence
  - attack.privilege_escalation
  - attack.t1136
  - attack.t1078
logsource:
  product: linux
  service: syslog
detection:
  selection:
    Message|contains:
      - 'operator created'
      - 'createOperator'
      - 'insertOperator'
      - 'API token created'
      - 'createApiToken'
      - 'superuser'
      - 'role changed to'
      - 'privilege escalation'
  filter_known_admins:
    SourceIp:
      - '10.0.0.0/8'
      - '192.168.0.0/16'
  condition: selection and not filter_known_admins
falsepositives:
  - Legitimate administrative provisioning from corporate management networks (tune filter to your jump-host subnet)
level: critical

KQL Hunt — Microsoft Sentinel

This query assumes VCO syslog/CEF ingestion into Sentinel (highly recommended — if you aren't shipping orchestrator logs to your SIEM, start now). It hunts for injection patterns against orchestrator endpoints and anomalous administrative activity from unusual sources.

// Hunt 1: SQL injection patterns in requests to VeloCloud Orchestrator
// Assumes CEF/Syslog or proxy logs ingested for VCO web tier
let injectionPatterns = dynamic(["UNION SELECT", "union+select", "information_schema", "SLEEP(", "BENCHMARK(", "UPDATEXML", "EXTRACTVALUE", "%27%20OR%20", "%27%20AND%20", "%3B--", "concat("]);
CommonSecurityLog
| where TimeGenerated > ago(14d)
| where DeviceProduct has_any ("VeloCloud", "VCO", "Orchestrator") or DestinationHostName has "orchestrator"
| extend RequestData = coalesce(RequestURL, Message, AdditionalExtensions)
| where RequestData has_any (injectionPatterns)
| summarize Requests = count(), DistinctURIs = dcount(RequestURL), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated)
  by SourceIP, DestinationHostName, bin(TimeGenerated, 1h)
| order by Requests desc;

// Hunt 2: Operator account / API token creation events from non-management sources
Syslog
| where TimeGenerated > ago(30d)
| where SyslogMessage has_any ("createOperator", "operator created", "createApiToken", "API token", "superuser", "role changed")
| where SyslogMessage has_any ("orchestrator", "velocloud", "vco") or Computer has "orchestrator"
| project TimeGenerated, Computer, SourceIP = HostIP, SyslogMessage
| order by TimeGenerated desc;

// Hunt 3: VCO management interface accessed from untrusted/public sources
CommonSecurityLog
| where TimeGenerated > ago(7d)
| where DestinationPort in (443, 8443) and (DestinationHostName has "orchestrator" or DestinationHostName has "vco")
| where not (ipv4_is_private(SourceIP))
| summarize Hits = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by SourceIP, DestinationHostName
| order by Hits desc;

Velociraptor VQL — Post-Exploitation Artifact Hunt

For self-hosted VCO instances (Linux-based, Tomcat-backed), hunt for dropped web shells and anomalous JSP files in the Tomcat webapps directory — the classic post-exploitation follow-through after achieving code execution on a Java web tier.

-- Hunt for recently created or anomalous JSP files in Tomcat webapps directories
-- on self-hosted VeloCloud Orchestrator hosts (potential web shells post-exploitation)
LET cutoff = now() - (30 * 24 * 3600)

SELECT FullPath, Size, Mtime, Ctime,
       Btime
FROM glob(globs='/opt/**/webapps/**/*.jsp')
WHERE Mtime > cutoff
   OR Btime > cutoff
ORDER BY Mtime DESC

-- Hunt for suspicious child processes spawned by the Tomcat/Java process
-- (shells, curl, wget, base64) indicating post-exploitation command execution
SELECT Pid, Ppid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE CommandLine =~ '(?i)(/bin/sh|/bin/bash|curl |wget |base64|nc |ncat |python|perl)'
   OR Name =~ '(?i)^(sh|bash|dash|curl|wget|nc|ncat)$'

Verification and Hardening Script

For self-hosted VCO instances, run this triage script to audit for indicators of compromise and verify exposure. Adjust paths to your deployment (default Tomcat paths shown).

#!/bin/bash
# VeloCloud Orchestrator Zero-Day Triage & Hardening Script
# Run on self-hosted VCO instances as root. Review output before taking action.

echo "=== [1] VCO Version / Build ==="
cat /opt/vco/VERSION 2>/dev/null || find /opt -maxdepth 3 -iname '*version*' 2>/dev/null | head -5

echo "=== [2] Recently modified JSP files (last 30 days) — web shell check ==="
find /opt -path '*webapps*' -name '*.jsp' -mtime -30 -ls 2>/dev/null

echo "=== [3] SQL injection patterns in Tomcat access logs ==="
grep -iE "union(select|%20|+)|information_schema|sleep%28|benchmark%28|updatexml|extractvalue|%27%20(or|and)%20|%3b--" \
  /opt/*/logs/localhost_access_log*.txt 2>/dev/null | tail -50

echo "=== [4] Suspicious child processes of Tomcat ==="
TOMCAT_PID=$(pgrep -f 'catalina' | head -1)
if [ -n "$TOMCAT_PID" ]; then
  ps --ppid "$TOMCAT_PID" -o pid,ppid,cmd 2>/dev/null
fi

echo "=== [5] External connectivity to VCO management ports (established) ==="
ss -tnp state established '( sport = :443 or sport = :8443 )' 2>/dev/null | head -30

echo "=== [6] Recently created local accounts ==="
awk -F: '($3 >= 1000) {print $1, $3}' /etc/passwd

echo "=== [7] Firewall check — is 443/8443 internet-facing? ==="
iptables -L INPUT -n 2>/dev/null | grep -E 'dpt:(443|8443)' || echo "No explicit INPUT rules found for 443/8443 — verify upstream ACLs"

echo ""
echo "=== NEXT STEPS ==="
echo "1. Compare JSP findings against your known-good deployment baseline."
echo "2. Forward ALL VCO logs (Tomcat access, application, audit) to your SIEM immediately."
echo "3. Restrict management-plane access to jump hosts / management VPN only."
echo "4. Contact Arista TAC for the emergency patch/hotfix for your build."

Remediation

Given confirmed active exploitation, treat this with patch-now urgency:

1. Engage Arista TAC immediately. For exploited zero-days, Arista typically distributes hotfixes through TAC before general availability publishes. Open a severity-1 case referencing the VeloCloud Orchestrator SQL injection advisory and request the fixed build for your version train. Do not wait for the public CVE or GA release notes.
2. Arista-hosted (SaaS) orchestrator customers: Confirm with Arista that your hosted instance has been remediated. Get it in writing. Your residual risk is then primarily around whether your tenant was compromised before patching — request any available exploitation telemetry.
3. Remove internet exposure of the VCO management interface. This is the single highest-value compensating control. The orchestrator UI and API should be reachable only from dedicated management networks, jump hosts, or admin VPNs. If your self-hosted VCO answers HTTPS from the public internet, that misconfiguration is now a critical finding in its own right.
4. Deploy WAF/reverse-proxy filtering in front of VCO as an interim control: block requests containing SQL metacharacter sequences (UNION, SELECT, information_schema, quote-encoding patterns) to orchestrator API paths. This is a speed bump, not a fix — but it raises the cost of exploitation while you patch.
5. Rotate credentials and tokens. If there is any possibility your orchestrator was exposed and unpatched during the exploitation window: rotate all operator account passwords, API tokens, RADIUS/TACACS+ shared secrets, and — critically — review edge device certificates and BGP/session credentials the orchestrator manages.
6. Audit operator accounts and configuration. Enumerate all operator/superuser accounts and diff against your known-good inventory. Review the orchestrator audit log for configuration changes to edges (new routes, new firewall rules, new VPN endpoints, DNS changes) you cannot attribute to change tickets.
7. Ship logs to your SIEM. Tomcat access logs, VCO application logs, and audit events must be centrally collected. Without this, you cannot answer the only question that matters after a zero-day disclosure: were we hit?
8. Monitor CISA KEV. Given confirmed exploitation of network management infrastructure, watch for a KEV listing — if your organization is bound by BOD 22-01 or follows KEV-driven SLAs, that will set a hard remediation clock.

References

• SecurityWeek: https://www.securityweek.com/attackers-exploit-third-velocloud-orchestrator-zero-day-in-four-months/
• Arista Security Advisories: https://www.arista.com/en/support/advisories-notices
• CISA Known Exploited Vulnerabilities Catalog: https://www.cisa.gov/known-exploited-vulnerabilities-catalog

The Bigger Lesson

Four months, three exploited zero-days, one management plane. This is the modern reality of infrastructure software: your SD-WAN orchestrator, your firewall manager, your VPN concentrator — these are now the front door. If your vulnerability management program treats network management appliances as "set and forget" infrastructure rather than tier-zero attack surface requiring rapid patch SLAs, internet-exposure controls, and dedicated detection content, this campaign is your wake-up call. Assume the fourth zero-day is already being tested against your perimeter.

Related Resources

Security Arsenal Penetration Testing Services AlertMonitor Platform Book a SOC Assessment vulnerability-management Intel Hub