VeloCloud Orchestrator: Read-Only Tenant to Superuser Operator in One SQL Injection
the lowest built-in role Arista ships for VeloCloud Orchestrator is “Enterprise Read Only.” it is the account you hand the intern so they cannot break anything. CVE-2026-114625 lets that account read the operator table and masquerade as a superuser operator. the SD-WAN control plane for your entire network, unlocked by the role you gave to the person you did not trust with write access. CVSS 9.9. actively exploited. KEV the day after disclosure.
vco.lab.local), with synthetic tenants and fake data. do not point sqlmap, or anything else, at an orchestrator you do not own and have written authorization to test. this is detection engineering and authorized red team practice, not a how-to for other people’s SD-WAN.what the bug actually is
CVE-2026-114625 is a SQL injection (CWE-89) in VeloCloud Orchestrator on-prem. Arista’s Security Advisory 0199 (October 22, 2026) rates it CVSSv3.1 9.9 and CVSSv4.0 9.4. the money sentence from the advisory: “any authenticated user can gain operator privileges and masquerade as a local superuser operator user.” the minimum role required is Enterprise Read Only, the lowest built-in tenant role. VCO is exposed by default and there is no configuration that prevents the exposure. hosted and Dedicated VCO instances were affected too and Arista already patched those. on-prem is your problem.
Arista says they detected it themselves and that it is actively exploited. so this is not a “someday” advisory. this is a “two IP addresses are already doing it” advisory.
step 0: you need a login, and that is the point
this is an authenticated SQLi, which sounds reassuring until you remember how many VCO tenants hand out read-only portal accounts like candy. MSPs, downstream customers, contractors, monitoring integrations. the barrier is “a valid session on the portal,” and the role bar is the floor. in the lab we log in as ro@lab, an Enterprise Read Only user, and confirm we can hit a portal method that takes an id-like parameter.
step 1: confirm the injection in a lab
point sqlmap at the lab endpoint with the captured session cookies. the CWE here is textbook: externally influenced input concatenated into a SQL statement without neutralization. in the lab target the id parameter is injectable via boolean-based blind and a generic UNION query, back-end PostgreSQL.
sqlmap -u 'https://vco.lab.local/portal/?method=getEnterpriseProxy&id=12' \
--load-cookies=jar.txt --batch --dbms=postgres --technique=BEUST -p id
id parameter is injectable. this is the CWE-89 the advisory describes, reproduced safely.step 2: the privilege escalation is a SELECT
the scary part of this CVE is not data exfiltration, though you get that for free. it is that reading the right rows lets a tenant user act as a superuser operator. in the lab we dump the operator user table and find the super account. in a real deployment that is the keys to every tenant, every edge, every config the orchestrator manages.
step 3: now hunt it like a defender
this is the half most “red team” posts skip. the same lab that proves the bug proves your detection. Arista published two attacker IP addresses actively conducting the attacks: 74.82.197.86 and 38.54.50.151. block them and grep for them. Arista’s IOC guidance is to review VCO web access logs for unexpected activity: unusual URL-like path components, encoded characters, references to local or internal services, or high request rates.
method and id parameters. a hit means preserve logs and assume compromise.the patch matrix, because deadlines exist
- VCO 5.2.x: fixed in 5.2.3.18 and later
- VCO 6.1.x: fixed in 6.1.3.10 and later
- VCO 6.4.x: fixed in 6.4.2.12 and later
- on an unsupported train: contact TAC about upgrade options, do not improvise
Arista’s defense-in-depth until you patch: restrict the VCO web interface to trusted administrative networks, monitor for the known malicious IPs, watch for unexpected outbound activity from the VCO host, block outbound ports you do not need, and look for backdoor daemons and webshells. if you suspect compromise, preserve VCO web access logs, backend application logs, system logs, database logs, and file-system timestamps before you remediate.
what to write in the detection ticket
- alert on authenticated portal requests where
methodoridparameters contain SQL keywords (UNION,SELECT, standalone quotes) or percent-encoded equivalents. - alert on Enterprise Read Only accounts performing actions that read operator or cross-tenant tables.
- baseline normal VCO request rates per source IP. the advisory explicitly calls out high request rates as an IOC.
- network-restrict the portal. “exposed by default” plus “no configuration prevents exposure” means the network boundary is the control.
the uncomfortable pattern
this is the third flavor of the same bug this month. Collabora shelled out with a bad quote. SiteGuard and Ahsay took OS commands through parameters. VeloCloud concatenated user input into SQL. different products, identical root cause: trusting input that reached a dangerous interpreter. if your security program drills “patch the appliance” but never drills “which of our appliances concatenate user input into shells and queries,” you are patching symptoms and calling it strategy.
sloth take
the lowest-privilege role you ship is a promise: this account cannot hurt you. CVE-2026-114625 is that promise failing in PostgreSQL syntax. patch to 5.2.3.18, 6.1.3.10, or 6.4.2.12, wall the portal off from the internet, block the two IPs, and grep your logs back far enough to find out whether the intern account already got borrowed.
sources
- Arista Security Advisory 0199 (October 22, 2026): CVE-2026-114625, CVSSv3.1 9.9 / CVSSv4.0 9.4, CWE-89, affected versions, IOCs (74.82.197.86, 38.54.50.151), and mitigations
- CISA KEV addition October 23, 2026 (CVE-2026-114625), actively exploited
- CVE.org and GitHub Advisory GHSA-964w-6mm5-rm95 (affected version ranges)
- Canadian Centre for Cyber Security AV26-1080 Update 1 and CERT Sante alert (KEV confirmation)
