Exploited at CVSS 10.0 — and the Vendor Never Checked Whether EOL Versions Are Affected

By Scott Bissett  ·  Published: July 28, 2026  ·  Updated: October 24, 2026  ·  EOL Watch — every claim verified against Arista's advisory and CISA's KEV catalog — methodology

On July 27, CISA added a maximum-severity flaw in Arista's VeloCloud Orchestrator to its Known Exploited Vulnerabilities catalog and gave federal agencies until July 30 to fix it — three days. Arista's advisory is clear and well written: it names the affected builds, names the fixed builds, publishes attacker IP addresses, and states plainly that the flaw "was discovered externally and is known to be actively exploited." If you run a supported version of VCO, you know exactly what to do.

And then there is one line, sitting quietly among the version tables, that tells a very different group of people almost nothing:

Eight words. If you are running an end-of-support VeloCloud Orchestrator, that sentence is the entire answer you are going to get about a CVSS 10.0 vulnerability that attackers are using right now.

What Arista actually disclosed

The technical facts are not in dispute, and they are serious. From the advisory:

Affected and fixed builds, per Arista:

Arista also published three IP addresses observed in attacks: 8.19.75.217, 206.72.242.124 and 206.72.242.162. That is genuinely useful disclosure — more than many vendors provide. This article is not a criticism of Arista's handling. It is about what the last row of that table means.

"Not assessed" is not "not affected"

These two statements look similar and mean opposite things:

• "Version X is not affected." Someone tested it. You are safe. Move on.
• "Version X has not been assessed." Nobody tested it. You do not know. Nobody is going to tell you.

The natural reading of an advisory is that anything not listed as vulnerable is fine. That reading is wrong here, and it is wrong in the same way across most vendor advisories. Vendors scope their security testing to supported releases, because that is what their support contracts oblige them to fix. Unsupported releases fall outside the scope of the investigation — not because they are believed safe, but because there would be no patch to ship even if they were found vulnerable.

So the practical position for someone running an end-of-support VCO is worse than it first appears. The vulnerability is confirmed exploited in the wild. The code path in question is old enough to plausibly exist in earlier builds. There is no assessment, no advisory update coming, and no fix. The exposure is not merely unpatched — it is unmeasured.

The three-day clock, and what it accidentally reveals

CISA added two vulnerabilities to the KEV catalog on July 27. Their deadlines are not the same:

Same catalog, same day, deadlines four times apart. This is BOD 26-04 working exactly as designed: since June, federal remediation deadlines scale with composite risk — public exposure, exploited status, automatability, and technical impact — rather than with a severity number. The VeloCloud flaw needs no credentials, is reachable over the network, and hands over the host. The Fortinet issue is an information disclosure that, by Fortinet's own account, cannot be exploited without having already compromised the system at filesystem level. One is a front door; the other is a cupboard inside a house you have already broken into.

Both KEV entries carry the same required action, and it is worth quoting because of how it ends: apply vendor mitigations in line with BOD 26-04, "or discontinue use of the product if mitigations are unavailable."

Read that against "end of support software versions have not been assessed." For an unsupported VCO, mitigations from the vendor are unavailable. CISA's own instruction, followed to its conclusion, says stop using it.

If you run VeloCloud Orchestrator today

On a supported branch: the July builds (5.2.3.14, 6.1.3.4, 6.4.2.4, 7.0.0.1) are no longer enough. On the 5.2, 6.1 and 6.4 trains, upgrade to 5.2.3.18, 6.1.3.10 or 6.4.2.12 or later, the minimum builds in Arista's October 22 advisory (see the October update). On the 7.0 train, Arista's September advisory lists 7.0.0.2 and below as affected and names no 7.0 fixed build, and the October advisory does not mention 7.0, so confirm your 7.0 build with Arista TAC. Check your logs against every published attacker IP first: with active exploitation confirmed and short federal deadlines, assume you may be looking at an incident rather than a maintenance window.

On an end-of-support branch: you have a different problem, and it does not resolve by waiting.

1. Restrict access to the VCO web interface now. The attack requires network reachability to that interface and no credentials. Network controls are the one mitigation that does not depend on the vendor.
2. Hunt before you assume. Check the published indicators. "Not assessed" cuts both ways — you cannot rule your version in, but you cannot rule it out either.
3. Do not wait for an advisory update. There is no assessment scheduled. The absence of your version from the affected list is not a future clearance; it is a permanent silence.
4. Plan the upgrade as an incident cost, not a project. The exit is a supported, fixed build.

Update, September 23, 2026: it happened again, at CVSS 10.0

On September 22, 2026 CISA added a second VeloCloud Orchestrator flaw to its Known Exploited Vulnerabilities catalog, CVE-2026-93952, a CVSS 10.0 improper input validation vulnerability in on-prem VCO that Arista says is being actively exploited, with a federal remediation due date of September 25, 2026. Arista's Security Advisory 0183 lists the affected releases (5.2.3.15 and below, 6.1.3.7 and below, 6.4.2.7 and below, 7.0.0.2 and below), names fixed builds for the 5.2.3 and 6.4.2 trains, and then repeats the shape of the July advisory almost word for word: fixes are coming out for affected release trains under support, and customers not on a supported release train can contact TAC to discuss possible upgrade options. The hosted and dedicated VCO services were patched before the advisory went out.

The same afternoon, Check Point and F5 published advisories for three more exploited flaws with the same carve-out. All four entries and all three advisories are in Three Vendors Shipped Emergency Fixes. All Stopped at End of Support. The argument below, written in July about one vendor, now describes three.

Update, October 24, 2026: a third exploited flaw, and new minimum builds

On October 22, 2026 Arista published Security Advisory 0199 for CVE-2026-114625, the third actively exploited flaw in on-prem VeloCloud Orchestrator since July. This one is an SQL injection (CWE-89) scored CVSS 9.9 on v3.1 and 9.4 on v4.0. Unlike the July flaw it needs a login, but a very small one: Arista says any authenticated user can gain operator privileges and masquerade as a local superuser operator, and the minimum role required is Enterprise Read Only, the lowest built-in tenant role. Arista detected it itself and says it is known to be actively exploited; hosted and dedicated VCO were already patched. On October 23, 2026 CISA added it to the Known Exploited Vulnerabilities catalog with a federal due date of October 26, 2026, and the entry requires forensic triage under BOD 26-04.

Every build in that table is later than the July fix for its train and above the highest build the September advisory lists as affected, so on 5.2, 6.1 and 6.4 the October minimum is the build to aim for. The advisory does not list the 7.0 train. Arista published two new attacker addresses for this flaw, 74.82.197.86 and 38.54.50.151, and says VCO is exposed by default with no configuration that prevents it. For an orchestrator off a supported release train, the advice is the same as in July and September: contact TAC to discuss upgrade options.

And the sentence this article was written about is back, word for word: "End of support software versions have not been assessed." Three exploited flaws in three months, and for anyone running an unsupported VCO, three times the same silence.

The pattern this exposes

This is not really a story about one networking vendor. It is a clean illustration of something we track constantly: end-of-life software fails quietly, and it fails first at the level of information.

The usual description of end-of-life is that patches stop. That is true and it understates the problem. What actually stops, in order:

1. Patches stop. The well-understood part.
2. Assessment stops. New vulnerabilities are no longer checked against your version, so your risk becomes unmeasurable rather than merely unaddressed.
3. Advisories go quiet. Your version stops appearing in affected-product lists — which reads like safety and means absence.
4. Scanners lose the thread. Tooling keyed to vendor advisories inherits the vendor's scope. No advisory entry, no finding.

That fourth step is the one that catches organisations out. A vulnerability scanner reporting nothing for an end-of-life system is not evidence of safety — it may simply be repeating the vendor's silence back to you. We wrote about this failure mode in detail in The CVE Blind Spot, and the VeloCloud advisory is the cleanest single-sentence example of it we have seen this year.

The defence is not a better scanner. It is knowing the lifecycle status of what you run before an advisory lands, so that when one does, you already know whether you are inside the vendor's field of view or outside it. That is a question about your inventory, not about any particular CVE.

Frequently Asked Questions

Sources

• Arista Security Advisory 0199 — CVE-2026-114625 (October 22, 2026)
• NVD — CVE-2026-114625
• Arista Security Advisory 0144 — CVE-2026-16812
• CISA Known Exploited Vulnerabilities Catalog (catalog version 2026.07.27)
• CISA — Two Known Exploited Vulnerabilities Added, July 27, 2026
• CISA BOD 26-04 — Prioritizing Security Updates Based on Risk
• BleepingComputer — Arista patches VeloCloud Orchestrator zero-day exploited in attacks