Arista VeloCloud Sicherheitslücke CVE-2026-93952: CVSS 10.0 aktiv ausgenutzt

Eine Arista VeloCloud Sicherheitslücke mit dem höchstmöglichen Schweregrad wird bereits angegriffen. Arista hat am 22. September 2026 das Security Advisory 0183 zu CVE-2026-93952 veröffentlicht: Der VeloCloud Orchestrator (VCO) lässt sich ohne jede Anmeldung übernehmen. CVSS 3.1 vergibt dafür glatte 10.0, CVSS 4.0 kommt auf 9.5. Arista schreibt selbst, die Lücke sei extern entdeckt worden und werde aktiv ausgenutzt.

Was Arista bestätigt

Die Ursache ist eine fehlerhafte Eingabeprüfung (CWE-20). Handlungsbedarf besteht bei VCO On-Prem in diesen Versionen:

• 5.2.3.15 und älter
• 6.1.3.7 und älter
• 6.4.2.7 und älter
• 7.0.0.2 und älter

Die von Arista gehosteten und die dedizierten VCO-Instanzen waren laut Advisory ebenfalls betroffen, sind aber bereits gepatcht. VeloCloud Gateway und Edge sind nicht betroffen, EOS- und CloudVision-Plattformen ebenfalls nicht.

Für einen Angriff braucht es erstaunlich wenig: Netzwerkzugriff auf das VCO-Webinterface und den öffentlichen Teil eines Edge-Authentifizierungszertifikats. Voraussetzung ist lediglich, dass die zertifikatsbasierte Authentifizierung zwischen Edge und Orchestrator konfiguriert ist. Tenant- oder Operator-Zugangsdaten sind nicht nötig. Danach steht privilegierte interne Funktionalität offen – bis hin zum Host.

AD-Checkliste

Dein AD härten: 12 Sofortmaßnahmen

Das PDF mit Bordmitteln, PowerShell-Prüfbefehlen und 30-Tage-Reihenfolge – per Mail, sobald du deine Anmeldung zum Tech-&-Tacheles-Newsletter bestätigst.

E-Mail-Adresse *

Mit der Anmeldung erhältst du die AD-Checkliste als PDF und danach den Tech-&-Tacheles-Newsletter mit Einordnungen zu Security, KI und Crypto sowie gelegentlichen Hinweisen auf meine Bücher und Produktempfehlungen (auch Affiliate-Links) – eingetragen bist du erst nach Klick auf den Bestätigungslink in der E-Mail (Double-Opt-in). Abmeldung jederzeit über den Link in jeder E-Mail, Details in der Datenschutzerklärung.

Zwei Release-Trains warten noch auf den Patch

Fertig sind bislang VCO 5.2.3.16 und 6.4.2.8. Für die Trains 6.1.x und 7.0.x gibt es zum Zeitpunkt dieses Beitrags keinen Fix – Arista kündigt Nachlieferungen für unterstützte Trains an, ohne Datum; bei abgekündigten Versionen verweist der Hersteller auf den TAC. Wer dort hängt, arbeitet also vorläufig mit Mitigation statt mit Patch.

Die CISA hat CVE-2026-93952 am 22. September in den KEV-Katalog aufgenommen. Die Frist für US-Bundesbehörden ist der 25. September 2026, drei Tage nach Aufnahme. Bemerkenswerter als die Frist ist ein Detail des Eintrags: Er ist als forensik-relevant markiert. Behörden müssen also Beweise sichern, nicht nur patchen. Die Lücke gehört zu einem Vierer-Paket vom selben Tag, zusammen mit der hier kürzlich besprochenen F5 BIG-IP APM Lücke CVE-2026-94127 und zwei Check-Point-Einträgen.

Woran du eine Kompromittierung erkennst

Arista nennt ausdrücklich keinen eindeutigen Einzelindikator, liefert aber brauchbare Anhaltspunkte. Erster Schritt sind die Web-Access-Logs des VCO: auffällig sind URL-artige Pfadbestandteile, kodierte Zeichen, Verweise auf lokale oder interne Dienste und ungewöhnlich hohe Request-Raten. Auf dem Host selbst geht es um die Dateien /usr/local/sbin/.vcnode.js, /usr/local/sbin/vc-sysmond und /etc/systemd/system/vc-sysmon.service. Für vc-sysmond nennt Arista den MD5-Hash dc78e206eaeadec59fc5801fe4556bd0 – der einzige harte Indikator der Liste. In nginx-Logs fällt zusätzlich der Header x-vc-opt auf, als Angreifer-Adressen listet das Advisory 142.93.149.77 und 104.248.126.159. Weiche Signale: unerwarteter ausgehender HTTP(S)-Verkehr vom Orchestrator, Konfigurationsänderungen ohne zugehörige Admin-Aktivität, plötzliche Datenbank-Exporte.

Was das für dich bedeutet

Aus CISO-Sicht ist an dieser Lücke nicht der CVSS-Wert das Interessante, sondern die Position im Netz. Ein Orchestrator ist kein Edge-Gerät, das man notfalls neu aufsetzt. Er ist die Steuerungsebene für alle angebundenen Standorte. Wer ihn übernimmt, hat nicht ein Gerät, sondern potenziell die Verwaltungshoheit über die gesamte SD-WAN-Flotte. Arista sagt das im Advisory auch klar: Ein kompromittierter VCO kann Zugang zu den verwalteten Edge-Devices eröffnen.

Der zweite Punkt betrifft die angebliche Hürde. „Zugriff auf den öffentlichen Teil eines Edge-Zertifikats“ klingt nach einer Schutzschicht, ist aber praktisch keine. Der öffentliche Teil ist per Definition kein Geheimnis: Er liegt auf jedem Edge-Gerät, in Konfigurations-Backups, in Monitoring-Exports, oft auch in Support-Tickets. Wer schon irgendwo im Netz des Betreibers ist – oder ein altes Backup in die Hände bekommt – hat diese Voraussetzung erfüllt. Ich würde die Bedingung deshalb nicht als Risikominderung in die Bewertung schreiben.

Dazu kommt ein Muster, das ich nach 25 Jahren im Betrieb regelmäßig sehe: Management-Systeme sind nach meiner Erfahrung häufig breiter erreichbar als die Systeme, die sie verwalten. Sie gelten als „intern“ und rutschen dadurch durch die Segmentierung. Genau das macht „Netzwerkzugriff auf das Webinterface“ zur Formalität statt zur Hürde.

Und es ist nicht das erste Mal: Ende Juli war eine VeloCloud-Lücke unter CVE-2026-16812 aktiv ausgenutzt – anderer Fehlertyp (Command Injection), dasselbe Produkt, dieselbe Angriffsfläche. Zwei ausgenutzte Orchestrator-Lücken in zwei Monaten sind ein Muster, kein Zufall. Wer VCO betreibt, sollte das Produkt in der eigenen Risikobetrachtung hochstufen.

Was jetzt konkret zu tun ist

• Version feststellen, bevor gepatcht wird: Liegt dein VCO im 5.2- oder 6.4-Train, ist der Fix verfügbar und du bist in Stunden fertig. Liegt er im 6.1- oder 7.0-Train, brauchst du einen Mitigationsplan – und einen festen Termin, an dem du den Fix-Status erneut prüfst.
• Erst schauen, dann patchen. Das ist die wichtigste Reihenfolge in diesem Fall: Ein gepatchter, aber kompromittierter Orchestrator ist gefährlicher als ein ungepatchter, weil er sauber aussieht. Wer sofort updatet, überschreibt womöglich die Spuren, die die Frage „waren sie schon drin?“ beantworten würden. Deshalb hat die CISA den Eintrag nicht ohne Grund forensik-relevant markiert.
• Webinterface einschränken: Zugriff nur aus einem definierten Admin-Netz oder über einen Sprungpunkt. Das ist die wirksamste Sofortmaßnahme, weil sie die einzige echte Vorbedingung des Angriffs entfernt.
• Ausgehenden Verkehr des VCO begrenzen und protokollieren. Ein Orchestrator, der plötzlich selbst ins Internet telefoniert, ist verdächtig – aber nur, wenn es jemand sieht.
• Auf die genannten IOCs prüfen, statt sich auf „war ja nicht erreichbar“ zu verlassen. Web-Access-Logs, Dateisystem inklusive Hash-Vergleich, Systemd-Units, nginx-Logs.
• Bei Fund nicht aufräumen, sondern den Zustand erhalten und den Arista TAC einschalten. Danach gilt: Credentials rotieren, Edge-Zustand validieren, Orchestrator aus vertrauenswürdiger Quelle neu aufbauen.

Kurzfassung: nachsehen, dann patchen, wo es geht. Wo es nicht geht, die Erreichbarkeit wegnehmen.

Quellen

• Arista Networks: Security Advisory 0183 (22.09.2026)
• CISA: Known Exploited Vulnerabilities Catalog
• BleepingComputer: Arista patches actively exploited VeloCloud Orchestrator zero-day
• The Hacker News: New CVSS 10.0 VeloCloud Orchestrator Flaw Actively Exploited
• SecurityWeek: Arista Urges Immediate Patching of Exploited VCO Zero-Day