Originally published at endoflife.ai.
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:
"End of support software versions have not been assessed."
Eight words. If you're running an end-of-support VeloCloud Orchestrator, that sentence is the entire answer you're going to get about a CVSS 10.0 vulnerability that attackers are using right now.
What Arista actually disclosed
| Field | Value |
|---|---|
| CVE | CVE-2026-16812 |
| CVSS v3.1 / v4.0 | 10.0 / 10.0 |
| Type | OS command injection, VeloCloud Orchestrator (VCO) on-prem |
| Exploitation | Discovered externally; known to be actively exploited |
| Added to CISA KEV | July 27, 2026 |
| Federal remediation due | July 30, 2026 |
Affected and fixed builds:
| Branch | Vulnerable | Fixed in |
|---|---|---|
| VCO 5.2.x | before 5.2.3.14 | 5.2.3.14 |
| VCO 6.1.x | before 6.1.3.4 | 6.1.3.4 |
| VCO 6.4.x | before 6.4.2.4 | 6.4.2.4 |
| VCO 7.0.x | before 7.0.0.1 | 7.0.0.1 |
| End-of-support versions | Not assessed | — |
Arista also published three IPs observed in attacks: 8.19.75.217, 206.72.242.124, 206.72.242.162. That's genuinely useful disclosure — more than many vendors provide. This isn't a criticism of Arista's handling. It's 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're safe. Move on.
- "Version X has not been assessed." Nobody tested it. You don't 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's wrong the same way across most vendor advisories. Vendors scope security testing to supported releases, because that's what support contracts oblige them to fix. Unsupported releases fall outside the investigation — not because they're believed safe, but because there'd be no patch to ship even if they were found vulnerable.
So the position for someone on an end-of-support VCO is worse than it first appears. The vulnerability is confirmed exploited in the wild. The code path is old enough to plausibly exist in earlier builds. There's no assessment, no advisory update coming, and no fix. The exposure isn't merely unpatched — it's 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:
| CVE | Product | Due | Window |
|---|---|---|---|
| CVE-2026-16812 | Arista VeloCloud Orchestrator | July 30 | 3 days |
| CVE-2025-68686 | Fortinet FortiOS | August 10 | 14 days |
Same catalog, same day, deadlines four times apart. This is BOD 26-04 working as designed: federal remediation deadlines now scale with composite risk — exposure, exploited status, automatability, impact — not a severity number. The VeloCloud flaw needs no credentials, is network-reachable, and hands over the host. The Fortinet issue requires prior filesystem-level compromise. One is a front door; the other is a cupboard inside a house you've already broken into.
Both KEV entries carry the same required action, and it's worth quoting how it ends: apply vendor mitigations, "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, vendor mitigations 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 / 7.0.0.1+. Check logs against the three published attacker IPs first — with active exploitation confirmed, assume you may be looking at an incident, not a maintenance window.
On an end-of-support branch:
- Restrict access to the VCO web interface now. The attack needs network reachability and no credentials. Network controls are the one mitigation that doesn't depend on the vendor.
- Hunt before you assume. "Not assessed" cuts both ways — you can't rule your version in, but you can't rule it out either.
- Don't wait for an advisory update. There's no assessment scheduled. Your version's absence from the affected list is not future clearance; it's permanent silence.
- Plan the upgrade as an incident cost, not a project.
The pattern this exposes
This isn't really a story about one networking vendor. The usual description of end-of-life is that patches stop. True — and it understates the problem. What actually stops, in order:
- Patches stop. The well-understood part.
- Assessment stops. New vulnerabilities are no longer checked against your version — your risk becomes unmeasurable, not just unaddressed.
- Advisories go quiet. Your version stops appearing in affected-product lists — which reads like safety and means absence.
- 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 teams out. A scanner reporting nothing for an EOL system is not evidence of safety — it may just be repeating the vendor's silence back to you.
The defence isn't a better scanner. It's knowing the lifecycle status of everything you run before an advisory lands — so when one does, you already know whether you're inside the vendor's field of view or outside it.
We track end-of-life dates and CVE risk for 490+ products at endoflife.ai — free checker, API, and risk scores. Sources: Arista Advisory 0144, CISA KEV catalog (v2026.07.27).
Top comments (0)