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

CVE-2026-114625 is an actively exploited SQL injection in on-prem Arista VeloCloud Orchestrator (VCO) that lets any logged in user, down to Enterprise Read Only, act as the local superuser operator. It is scored CVSS 9.9. Upgrade to 5.2.3.18, 6.1.3.10 or 6.4.2.12, restrict the web portal to admin networks and hunt your logs.

Arista published Security Advisory 0199 on 22 October 2026. It says the issue "was detected by Arista and is known to be actively exploited", and it names two source IP addresses tied to the activity. Hosted and Dedicated orchestrators were also affected and Arista has already patched them, so the work in this post is for teams that run their own orchestrator.

When we checked on 23 October, the newest CISA Known Exploited Vulnerabilities (KEV) catalog we could retrieve (version 2026.10.21) did not list CVE-2026-114625, and CISA's enrichment on the CVE record marked exploitation as "none". Arista's own advisory is the stronger signal here. We cover that gap in detail below.

This is the third actively exploited VCO flaw since late July 2026. The July and September flaws needed no login at all; this one needs a login, but the weakest one the product offers. Our edge device zero day roundup covers the wider October picture, and the SiteGuard and Siemens Software Center post shows how CISA handled the last batch of exploited flaws it added. This post goes deep on VCO only.

What happened

VeloCloud Orchestrator is the management plane for VeloCloud SD-WAN. It holds the configuration for every Edge and Gateway in an estate, along with the tenant (Arista calls them enterprise) accounts that let customers, partners and managed service providers look at or change that configuration. Arista's advisory notes the product was formerly sold as VeloCloud Orchestrator by Broadcom.

On 22 October 2026 Arista released Security Advisory 0199, revision 1.0, tracked internally as BUG2043622. The advisory says a remote attacker may reach privileged internal functionality and affect the VCO host. Arista says any authenticated user can gain operator privileges and pose as a local user called the superuser operator. The functionality reached is, per Arista, intended for internal use only.

The preconditions are short. An attacker needs network access to the VCO web interface and a valid authenticated portal session. The minimum role is Enterprise Read Only, which Arista describes as the lowest built-in tenant role. Arista adds that VCO is exposed by default and that no configuration prevents the exposure. There is no setting you can flip to make this go away.

Arista classifies the weakness as CWE-89, SQL injection, and scores it 9.9 under CVSS 3.1 and 9.4 under CVSS 4.0. The advisory does not say where the injection sits or how it turns into operator access, and we do not speculate on either. What matters for defenders is the outcome Arista describes: a read only login becomes the top level of control.

The same day, Arista listed two IP addresses linked to exploitation attempts, 74.82.197.86 and 38.54.50.151, and asked customers to block them and check logs for them. It also published log review guidance and an evidence preservation step. The CVE record went live at 20:47:56 UTC on 22 October, with Arista as the CVE Numbering Authority.

The Hacker News, BleepingComputer and SecurityOnline reported the advisory on 22 October. None of them, and not Arista, has said when exploitation began, how many orchestrators were hit, who is behind it or what attackers did after gaining operator access. The Hacker News lists these as open.

Timeline

Times are given exactly as each source published them. Where a source gave no time or time zone, we say so.

Affected and fixed versions

This table is taken directly from Arista Security Advisory 0199 and matches the affected ranges in the CVE record, which Arista wrote as the CNA.

Three points about this table.

First, the 7.0 train is not listed. Arista states that a release not on the affected list is not vulnerable to this issue. That is a statement about CVE-2026-114625 only, and 7.0 has its own history with the September flaw (see below).

Second, the CVE record sets the default status to "unaffected" and lists only the three ranges above, which agrees with the advisory.

Third, the builds that fixed the July and September flaws sit inside the October affected ranges. An orchestrator that was patched promptly in September is vulnerable again today.

One table for all three exploited VCO flaws of 2026

If you run VCO on-prem, you need to clear all three advisories, not just the newest. This table combines the fixed versions from Arista Security Advisories 0144, 0183 and 0199, with the CVE records as a cross check.

The 6.1 and 7.0 rows are the uncomfortable ones. The September advisory's affected range for 6.1 ends at 6.1.3.7, so 6.1.3.10 sits above it, but Advisory 0183 never names a fixed 6.1 build and has not been revised since 23 September. The Hacker News made the same observation: neither advisory says whether 6.1.3.10 also fixes the September flaw. For 7.0, the October flaw does not apply, but the September flaw's affected range runs through 7.0.0.2 with no fix named. Ask Arista TAC for a written answer for your exact build.

Technical details

The advisory and the CVE record

Arista Security Advisory 0199 and the CVE record carry the same core content. The CVE record adds machine readable structure that is useful for automation:

• Assigner: Arista, organisation ID c8b34d1a-69ae-45c3-88fe-f3b3d44f39b7.
• Reserved: 2026-10-21T20:35:35.535Z. Published: 2026-10-22T20:47:56.427Z. Last updated: 2026-10-23T03:55:37.265Z.
• Title: "Security Advisory 0199".
• Affected product: vendor "Arista Networks", product "VeloCloud Orchestrator", platform "VeloCloud Orchestrator On-Prem", version type "custom", default status "unaffected".
• Weakness: CWE-89. Attack pattern: CAPEC-66, SQL Injection.
• Single reference: the Arista advisory URL.

The advisory's resolution section refers to "vulnerabilities" in the plural while tracking only one CVE. We read that as boilerplate, but it is worth asking TAC whether the fixed builds carry other security fixes that are not yet public.

Reading the CVSS vectors

Arista publishes two vectors: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H (9.9) and 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 (9.4). They tell you more about the risk than the headline number.

The CVSS 4.0 vector says the same thing in its own terms: no attack requirements (AT:N), low privileges, no user interaction, and high impact on both the vulnerable system (VC, VI, VA) and subsequent systems (SC, SI, SA). The subsequent system scores are the part to take seriously. An SD-WAN orchestrator's subsequent systems are your branch network.

The only reason this is 9.9 and not 10.0 is the login requirement. In practice, that requirement is weaker than it looks, because read only portal accounts are often the least protected accounts in the system.

The role model in plain terms

VCO separates operator users, who run the orchestrator itself, from enterprise (tenant) users, who manage one customer's SD-WAN. Partner users sit between them in managed service setups. Enterprise Read Only is the bottom of that ladder: it is meant for people who need to see network status, such as a help desk, an auditor or a customer's own staff watching an MSP managed network.

Arista says this flaw lets any of those users reach operator privileges and impersonate the local superuser operator. That is a jump from one tenant's read only view to control of the whole orchestrator, every tenant on it and, per Arista's wording, internal functionality on the VCO host itself.

Indicators of compromise, as Arista lists them

Arista Security Advisory 0199 lists these indicators for CVE-2026-114625. We reproduce them exactly as the advisory gives them.

Arista does not publish file hashes, file paths, user agents, domain names or specific log file locations for this CVE. If a feed or vendor blog offers hashes for CVE-2026-114625, check where they came from before you act on them.

Indicators from the earlier VCO campaigns

These belong to the earlier flaws, not to CVE-2026-114625. We list them because an orchestrator that was exposed in July or September should be checked for them anyway, and because Arista has not said whether the October activity is related.

Arista says in both earlier advisories that there is no single definitive indicator, and asks customers who find any of these to preserve the VCO state and contact TAC. Advisory 0144 also lists unexpected access to database contents or key material as something to investigate, and its post remediation guidance mentions credential rotation and validating the state of managed devices.

What the earlier advisories say about Edges

Advisory 0199 lists VeloCloud Edge and Gateway as not affected by this flaw. That is about the code in those devices. It is not a statement that an orchestrator compromise leaves them untouched. In July, Advisory 0144 warned that compromises of the VCO platform "may allow attackers access to the VeloCloud Edge devices as well". Advisory 0199 does not repeat or retract that warning, and The Hacker News flags the gap. Plan as if an orchestrator under attacker control can push configuration to the Edges it manages, because that is what an orchestrator is for.

KEV status: what we found

We checked CISA's KEV JSON feed on 23 October 2026. The newest catalog version available was 2026.10.21, released at 14:04:39 UTC on 21 October with 1,754 entries. It does not contain CVE-2026-114625. The most recent additions in it are dated 20 October and include CVE-2026-106931 and CVE-2026-110936 (the SiteGuard and Siemens Software Center flaws covered in our earlier post). There were no additions dated 21, 22 or 23 October.

The only Arista VeloCloud entry we could see in the newest part of the catalog is CVE-2026-93952, added 22 September with a 25 September due date and ransomware use "Unknown". The CVE record for CVE-2026-16812 shows a KEV date added of 27 July.

The CVE record for CVE-2026-114625 now carries a CISA ADP container with SSVC Exploitation "none", Automatable "no" and Technical Impact "total". SSVC values are often set before CISA has reviewed a vendor's exploitation claim, and they change when KEV changes. For both earlier VCO flaws, CISA added the CVE to KEV the same day Arista published. That has not happened this time, at least as of the catalog version we could read.

Treat it as exploited regardless. A vendor saying its own detection found active exploitation is primary evidence. KEV is a federal prioritisation list, not a test of whether something is real.

How the flaw works, in plain language

An orchestrator portal stores almost everything in a database: users, roles, tenants, Edge configurations, certificates and logs. Every page and API call a user makes turns into database queries. SQL injection happens when text from a user ends up inside one of those queries in a way that changes what the query does, instead of being treated as plain data.

When that happens in a query that decides who you are or what you are allowed to do, the result is privilege escalation. That is the outcome Arista describes: a session that should be read only is treated as the superuser operator.

Arista has not published the vulnerable endpoint, the parameter or the query, and neither has anyone else we could find. We will not guess. The defensive points do not depend on those details:

• Every account that can log in is a possible starting point, so the account list is part of your attack surface.
• Network restriction on the portal is the only control that blocks an attacker who already holds a password.
• Log entries from the attack will look like a normal user session making unusual requests, which is why Arista points at path components, encoded characters and request rates rather than login failures.

Why the orchestrator is the prize

SD-WAN orchestrators, firewall managers, remote management tools and hypervisor consoles share one property: they hold the keys to many other systems. An attacker with operator access to VCO can, in principle, read every tenant's network design, change routing and security policy on Edges, and harvest whatever credentials and certificate material the orchestrator stores. Advisory 0144 lists unexpected access to "key material" among the signs to investigate, which tells you Arista considers it in reach.

Managed service providers carry extra exposure. One partner hosted orchestrator may serve dozens of customer enterprises, each with its own read only users. Under this flaw, any one of those users is a route to all of them. If you buy SD-WAN as a managed service on an on-prem orchestrator run by your provider, ask your provider directly which build it runs.

Three exploited VCO flaws in three months

Sources: Arista SA 0144, 0183, 0199; CVE records; CISA KEV feed.

BleepingComputer also lists CVE-2026-7473 from May 2026 among Arista zero days this year, affecting EOS and on-prem VCO. We could not confirm the details of that flaw from a primary source, so we leave it out of the table.

The pattern is the point. All three advisories use nearly the same impact wording: privileged internal functionality, impact to the VCO host. The September advisory said fixes for other trains "will be added over time". Teams that patch to the minimum fixed build each time are back in the affected range within weeks. The practical answer is to run the newest build on your train, keep the portal off the internet and treat every new VCO advisory as an emergency change.

Exploited or not? Sorting out the claims

• Arista says exploited. Advisory 0199: "detected by Arista and is known to be actively exploited." This is the primary source.
• CISA has not added it to KEV yet. Catalog version 2026.10.21 does not include it, and the CISA ADP SSVC on the CVE record says Exploitation "none" as of 23 October 03:55 UTC. That reflects timing, not a finding that the vendor is wrong.
• Third party feeds may disagree. Many CVE feeds copy the SSVC or KEV fields, so some will show this CVE as not known exploited. Follow Arista.
• Nobody has published scale. No source gives a count of compromised orchestrators. The Hacker News notes the advisory does not say when attacks started or what attackers did next.
• Exposure counts are rough. One independent write-up reports 520 assets for a ZoomEye title query on 22 October, and notes that this counts visible login pages, not vulnerable builds.

What changed since first reports

• 22 October, advisory day: Advisory 0199 revision 1.0 published with versions, IPs and log guidance.
• 22 October evening (UTC): CVE record published, matching the advisory.
• 23 October, early UTC: CISA ADP adds SSVC with Exploitation "none". No KEV listing.
• Still unchanged on 23 October: Advisory 0199 has no revision beyond 1.0; Advisory 0183 still names no fixed 6.1 or 7.0 build for the September flaw.

Who is affected

What to do now

Work through these in order. Steps 1 to 3 can happen in the first hour.

1. Find every orchestrator. List each VCO instance you or a provider run, its train and full build number. The build is shown in the operator portal. Record it as the full four part string; "6.4" is not enough.

2. Check whether the portal is reachable from the internet. Run this from a host outside your network, replacing the hostname:

curl -skI https://vco.example.com/ | head -n 5
nmap -Pn -p 443 vco.example.com

If you get an HTTP response from the open internet, the portal is exposed.

3. Restrict the web interface to admin networks. This is Arista's first interim control. On a Linux firewall in front of the orchestrator, using nftables (this assumes an existing inet filter table with input and forward chains):

# allow only your admin network to reach the portal, drop everything else on 443
nft add rule inet filter forward ip daddr 203.0.113.10 tcp dport 443 ip saddr 198.51.100.0/24 accept
nft add rule inet filter forward ip daddr 203.0.113.10 tcp dport 443 drop

Replace 203.0.113.10 with the orchestrator address and 198.51.100.0/24 with your admin range. Remember that Edges also talk to the orchestrator; check with Arista which paths your Edges need before you cut them off.

4. Block the two IPs Arista named. At the perimeter:

nft add rule inet filter input ip saddr { 74.82.197.86, 38.54.50.151 } drop
nft add rule inet filter forward ip saddr { 74.82.197.86, 38.54.50.151 } drop
# or with iptables
iptables -I FORWARD -s 74.82.197.86 -j DROP
iptables -I FORWARD -s 38.54.50.151 -j DROP

5. Preserve evidence before you upgrade. Arista asks for VCO web access logs, backend application logs, system logs, database logs and relevant file system timestamps. The advisory gives no file paths, so ask TAC for the locations on your build. Once you have exported them:

ts=$(date -u +%Y%m%dT%H%MZ)
tar czf vco-evidence-$ts.tgz ./vco-logs
sha256sum vco-evidence-$ts.tgz > vco-evidence-$ts.tgz.sha256

Store the archive and its hash somewhere the orchestrator cannot reach.

6. Upgrade. Move to 5.2.3.18, 6.1.3.10 or 6.4.2.12 or later on your train, following Arista's upgrade documentation. If you are on an unsupported train, open a TAC case. After the upgrade, confirm the new build number in the operator portal and record it.

7. Review every account that can log in. In the operator portal and each enterprise, list users with any role, with special attention to Enterprise Read Only, partner users and accounts owned by third parties. Disable accounts nobody uses. Revoke API tokens nobody can explain. Require MFA or single sign on where your release and identity provider support it.

8. Review recent administrator activity. Look for operator level changes made from sessions that belong to low privilege users, new operator accounts, role changes and configuration pushes to Edges that nobody scheduled.

9. Check the earlier campaign indicators. Even if this flaw is your only concern, an orchestrator exposed in July or September should be checked for the SA 0144 and SA 0183 indicators listed above.

10. Rotate after you are clean, not before. If you find signs of compromise, rebuild or upgrade first, then rotate operator and enterprise credentials, API tokens and any secrets the orchestrator stores. Rotating on a compromised host hands the attacker the new values.

Hunting guide

These commands assume you have exported the VCO web access logs to an analysis host in a common combined format, with the client IP in the first field and the request path in the seventh. Adjust field numbers to your format. Run them on copies, not on the appliance.

Search for the IPs Arista named, including rotated logs:

grep -rhE '74\.82\.197\.86|38\.54\.50\.151' ./vco-logs | head -n 50
zgrep -hE '74\.82\.197\.86|38\.54\.50\.151' ./vco-logs/*.gz | wc -l

Find clients with unusually high request rates:

awk '{print $1}' ./vco-logs/access.log | sort | uniq -c | sort -rn | head -n 20
# requests per client per minute, to spot bursts
awk '{split($4,t,":"); print $1, t[1]":"t[2]":"t[3]}' ./vco-logs/access.log \
  | sort | uniq -c | sort -rn | head -n 20

Look for encoded characters in request paths:

awk '{print $7}' ./vco-logs/access.log | grep -E '%[0-9A-Fa-f]{2}' \
  | cut -c1-160 | sort | uniq -c | sort -rn | head -n 40

Look for references to local or internal services in requests:

grep -E 'localhost|127\.0\.0\.1|0\.0\.0\.0|169\.254\.169\.254|\[::1\]' ./vco-logs/access.log | head -n 50

Tie sessions to roles. For any client that appears in the results above, find the user it authenticated as and that user's role. A read only enterprise user's session followed by operator level actions is the shape Arista describes.

On the host, under TAC guidance. If you have shell access to the orchestrator through Arista's support process, these generic Linux checks help answer Arista's points about outbound traffic, backdoor daemons and webshells:

ss -tnp state established
systemctl list-units --type=service --state=running
find /usr/local/sbin /etc/systemd/system -newermt 2026-07-01 -ls
ls -la /usr/local/sbin/.vcnode.js /usr/local/sbin/vc-sysmond /etc/systemd/system/vc-sysmon.service 2>/dev/null

The last line checks for the September (SA 0183) file indicators. If any exists, run md5sum on it and compare with dc78e206eaeadec59fc5801fe4556bd0, then stop and call TAC.

Check for the September response header from outside:

curl -skI https://vco.example.com/ | grep -i 'x-vc-opt'

Any output means the SA 0183 indicator is present and the orchestrator needs a compromise review.

Outbound traffic. From your firewall or flow logs, list every destination the orchestrator connected to in the last 90 days. An orchestrator should talk to a short, predictable list: your Edges and Gateways, Arista update services, your identity provider, logging and NTP. Anything else needs an explanation.

If you find signs of compromise

1. Do not patch first. Preserve the logs and file timestamps Arista lists, plus a full VM snapshot if the orchestrator is virtual.
2. Isolate the portal from everything except your response team's network.
3. Open a TAC case and share the evidence.
4. Assume the attacker had operator access. Review configuration pushed to Edges since the earliest suspicious entry, and validate the state of managed devices, as Advisory 0144 recommends for the July flaw.
5. Rebuild or upgrade to a fixed build, then rotate operator, partner and enterprise credentials, API tokens and stored secrets.
6. Tell affected tenants. If you are an MSP, your customers' read only users may have been the entry point, and their networks may have been the target.

Open questions

• When did exploitation start, and how did Arista detect it?
• How many orchestrators were compromised, and were attackers using stolen read only credentials or accounts they created?
• What did attackers do with operator access? Did they push changes to Edges?
• Is the October activity linked to the July or September campaigns? Arista has not said.
• Does 6.1.3.10 fix CVE-2026-93952? Advisory 0183 does not say.
• What is the fixed 7.0 build for CVE-2026-93952?
• When, or whether, CISA will add CVE-2026-114625 to KEV.

What would have helped

Practices any team can use

Keep management planes off the internet. Orchestrators, firewall managers, remote management tools and hypervisor consoles belong on an admin network, reached through a VPN or a bastion with strong authentication. Arista's interim control for all three 2026 VCO flaws is the same: restrict the web interface to trusted admin networks. That control would have reduced exposure to all three.

Treat read only accounts on management consoles as privileged. They are often shared, rarely reviewed and created for people outside your company. Apply MFA, single sign on and quarterly reviews to them just as you would to admin accounts. Delete what nobody uses, including old partner and auditor logins.

Know your build, not your version. Store the full four part VCO build for every orchestrator, yours and your providers'. When an advisory says "fixed in 6.4.2.12", that should map to a yes or no answer in minutes.

Patch to the newest build on your train, not the minimum. Three advisories in three months each raised the minimum. Running the newest build gives you margin.

Watch the vendor first and KEV second. Here Arista said exploited before CISA did; alerting that waits for KEV would have been late.

Limit outbound traffic and keep logs off the box. Block outbound ports the orchestrator does not need, as Arista suggests, and ship its logs to central storage with long retention.

Write down the MSP question. If a provider runs your orchestrator, your contract should say how fast they apply vendor fixes and how they tell you about compromise. The October incident review collects these habits across this month's cases.

Where Safeguard fits

Limits first. Safeguard does not scan VeloCloud Orchestrator, read its logs, inventory SD-WAN appliances or detect SQL injection attempts against a vendor appliance. It would not have found this flaw, would not have flagged a vulnerable VCO build and would not have stopped the exploitation. For the orchestrator itself, rely on Arista's advisory, TAC, your network team and your SIEM.

Safeguard helps with the software you build and run, which is what an attacker reaches next once a management plane falls, and with the habits this incident tests.

Know what is in what you ship. Safeguard generates SBOMs and scans dependencies in repositories, container images and SBOM files with safeguard scan --dir ., safeguard scan --image <name> or safeguard scan --sbom <file>, writing JSON results under ./output. The platform shows which projects contain a given component and version, the same "which build is where" question this incident asks of orchestrators. If a vendor hands you an SBOM for an appliance, scanning it shows only the third party components that SBOM declares.

Prioritise known exploited flaws. Vulnerability matching draws on public databases including CISA KEV and vendor bulletins, and reachability analysis ranks flaws on code paths your application actually calls. Policies and gates evaluated in the platform can stop a release that carries a vulnerable version.

Fix with approval. The Safeguard CLI's assistant edits code and runs commands with your approval under the /permissions modes Ask, Accept edits, Plan, Auto (the default) and Strict. safeguard exec runs in CI. The desktop and phone apps send work to a computer running the CLI and approve each command. Autonomous remediation opens fix pull requests and ships switched off. For tracing components across products quickly, see SBOM incident response.

Zero-Day Discovery and Gold

Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in two modes, an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases. It covers seven package ecosystems.

Gold Open Source (gold.safeguard.sh) is free and needs no login: searchable CVE intelligence with CVSS, EPSS, KEV status, affected and fixed versions and a recommended safe version, plus a free read API and a CI gate GitHub Action. Gold Registry (registry.safeguard.sh, paid) provides hardened drop in components and container images held to zero exploitable critical or high CVEs, SLSA L3 or above, Sigstore signed, with evidence pages. An artifact loses its badge if it regresses.

Gold does not patch an Arista orchestrator. The habit it supports is the one this incident rewards: when a fix exists, take patched, signed components from a curated source and rebuild fast, instead of waiting for the next window.

Common mistakes

• Assuming the September patch covers October. 5.2.3.16 and 6.4.2.8 are inside the October affected range.
• Reading "requires authentication" as low risk. The weakest role is enough, and read only accounts are the least watched.
• Waiting for KEV. Arista said exploited on 22 October. KEV had not caught up when we checked.
• Forgetting 7.0 and 6.1. The October advisory skips 7.0 and names 6.1.3.10, but the September flaw's status on those trains is unclear.
• Patching before preserving logs. Upgrades can rotate or drop the evidence Arista asks for.
• Rotating credentials on a compromised host. Clean first, then rotate.
• Ignoring the Edges. The Edge code is not affected, but an orchestrator under attacker control can manage it.
• Assuming hosted means nothing to do. Arista patched the code, but your enterprise's accounts and recent admin activity are still yours to review.

FAQ

What is CVE-2026-114625?

An SQL injection (CWE-89) in on-prem Arista VeloCloud Orchestrator that lets any authenticated user, including Enterprise Read Only, gain operator privileges and impersonate the local superuser operator. Arista scores it CVSS 3.1 9.9 and CVSS 4.0 9.4 in Security Advisory 0199.

Is it being exploited?

Yes, according to Arista, which says it detected the issue and that it is known to be actively exploited. Arista has not said when exploitation began or how many orchestrators were affected.

Is CVE-2026-114625 in the CISA KEV catalog?

Not when we checked on 23 October 2026. The newest KEV catalog we could retrieve, version 2026.10.21, does not list it, and CISA's SSVC on the CVE record says Exploitation "none". Both earlier exploited VCO flaws were added to KEV on the day Arista published, so check the catalog again.

Which versions are fixed?

5.2.3.18, 6.1.3.10 and 6.4.2.12, and later builds on each train. Hosted and Dedicated orchestrators are already patched by Arista. End of support trains were not assessed; contact TAC.

Is VCO 7.0 affected?

Arista does not list 7.0 as affected by this CVE and says unlisted releases are not vulnerable. The September flaw, CVE-2026-93952, affects 7.0.0 through 7.0.0.2 with no fixed build named in Advisory 0183, so confirm your 7.0 status with TAC.

Are VeloCloud Edges and Gateways affected?

Not by this flaw, per Arista. But an orchestrator is how Edges are managed, and Arista warned in July that a VCO compromise may give attackers access to Edges. Validate Edge configuration if you find signs of compromise.

What should I look for in logs?

The IPs 74.82.197.86 and 38.54.50.151, unusual URL-like path components, encoded characters, references to local or internal services and high request rates in VCO web access logs. Then look for operator level actions from low privilege sessions.

I use a managed SD-WAN service. What should I ask my provider?

Which VCO build their orchestrator runs, whether it is internet facing, whether they have reviewed logs for the indicators in Advisory 0199, and whether any of your users' sessions show unusual activity.

Does Safeguard detect this?

No. It helps with the dependencies and container images you build, which is covered above.

Fix it without waiting for upstream

The orchestrator fix has to come from Arista, and the steps above cover it. The block below is about the other half of your exposure: the software your own teams build and ship, which is what an attacker with control of your network reaches next.

In incidents like this one, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos show this incident or a VeloCloud orchestrator. Each shows a real flow for the software you own, which is what an attacker reaches after taking over the network management plane.

The first demo is a CLI session that fixes a lodash CVE: it reads the finding and the advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, and pushes nothing. For this incident, you would run the same scan against the internal applications that sit behind your SD-WAN, such as branch portals and line of business services, and ask the assistant to move any known exploited components to fixed versions, approving each step.

Click through it at your own pace, or open it full screen.

The second demo is a desktop app session. The CLI session shows in the conversation list, you ask for work on your computer, pick the folder, then approve or deny each command and file edit until the upgrade is done and tests pass. During a management plane incident, with network, security and application teams all changing things at once, per action approval leaves a clear record of who allowed what.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session: you send work to a computer running the CLI and approve the command on the phone with Allow once, Allow for turn or Deny. Exploited appliance advisories rarely land in working hours; the same flow lets an on call engineer approve a dependency fix in a service behind the SD-WAN from wherever they are, without standing access.

Click through it at your own pace, or open it full screen.

To try it on your own repositories, download Safeguard and follow the CLI docs.

Quick check

Sources

• Arista Security Advisory 0199, VeloCloud Orchestrator On-Prem, CVE-2026-114625 (22 Oct 2026)
• Arista Security Advisory 0183, CVE-2026-93952 (22 Sep 2026)
• Arista Security Advisory 0144, CVE-2026-16812 (27 Jul 2026)
• CVE record for CVE-2026-114625 (CVE Program API, Arista as CNA, with CISA ADP)
• CVE record for CVE-2026-93952
• CVE record for CVE-2026-16812
• CISA Known Exploited Vulnerabilities catalog, JSON feed (version 2026.10.21)
• Canadian Centre for Cyber Security: Arista Networks security advisory AV26-947
• Canadian Centre for Cyber Security: Arista Networks security advisory AV26-751
• NCSC-NL: NCSC-2026-0281, Arista VeloCloud Orchestrator On-Prem
• The Hacker News: Arista warns of critical VeloCloud SQL injection zero day exploited in attacks
• BleepingComputer: Arista patches new VeloCloud Orchestrator zero day exploited in attacks
• SecurityOnline: VeloCloud Orchestrator CVE-2026-114625 exploited
• DEV Community: CVE-2026-114625, a read only login is enough to own Arista VeloCloud Orchestrator
• DEV Community: When you cannot patch VeloCloud Orchestrator today, a CVE-2026-114625 playbook

Last reviewed: 23 October 2026. This is a developing story; check the linked advisories for the latest status.