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

Published: July 28, 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: upgrade to 5.2.3.14, 6.1.3.4, 6.4.2.4 or 7.0.0.1 or later. Check your logs against the three published attacker IPs first — with active exploitation confirmed and a three-day federal deadline, 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.

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 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