Arista opisuje CVE-2026-93952 w VeloCloud Orchestrator (VCO) jako krytyczną podatność i potwierdza aktywną eksploatację. To case, w którym cztery rzeczy — severity, konfiguracja, model hostingu i dostępność poprawki — muszą być rozpatrywane osobno, zamiast zlewać się w jeden wiersz „Critical, patch available”.
patch_available to funkcja release trainu, nie globalny boolean.Attack path
Hosted vs on-prem
Hosted i Dedicated VCO mogą zostać naprawione po stronie providera, podczas gdy on-prem wymaga działania klienta. Dlatego pole patch_available nie powinno być pojedynczą wartością true/false dla całego CVE — powinno być funkcją konkretnego release trainu i modelu wdrożenia. Ten sam CVE bywa jednocześnie remediated_by_provider dla jednego assetu i action_required dla drugiego.
KEV i compromise assessment
Przy potwierdzonym exploitation workflow zmienia się z patch na patch/mitigate + forensic triage + compromise assessment. Samo zainstalowanie poprawki nie odpowiada na pytanie, czy system był wcześniej przejęty — a przy CVSS 10 i aktywnej eksploatacji to pytanie jest istotne dla każdej instancji, która była osiągalna w okresie podatności.
Verification
VE powinien ustalić model hostingu, build, certificate-based Edge auth, reachability interfejsu oraz aktualną fixed release dla właściwego trainu. Po patchu trzeba przejrzeć logi i artefakty z okresu podatności — closure oparte wyłącznie na wersji jest niewystarczające tam, gdzie istniało exposure window.
Powiązane na blogu
- WSO2: CVSS 10 wraca jako KEV — threat state zmienia priorytet
- Cisco FMC: active exploitation — patched ≠ uncompromised
Źródła
- Arista Security Advisory 0183 — arista.com
- CISA Known Exploited Vulnerabilities Catalog — cisa.gov
Nota redakcyjna: stan informacji 27 września 2026. CVE-2026-93952 (Arista VeloCloud Orchestrator) — Arista potwierdza aktywną eksploatację. Artykuł rozróżnia model hostingu (hosted/dedicated/on-prem) i traktuje dostępność poprawki jako funkcję release trainu.