VeloCloud Orchestrator: Kritische Lücke CVE-2026-93952 mit CVSS 10.0 wird aktiv ausgenutzt

Arista hat am 22. September 2026 eine Schwachstelle im on-premises VeloCloud Orchestrator (VCO) veröffentlicht, die mit dem höchstmöglichen CVSS-3.1-Wert von 10.0 bewertet ist. Der VCO ist der zentrale Managementserver einer VeloCloud-SD-WAN-Umgebung. Wer eine solche Installation selbst im eigenen Rechenzentrum betreibt, sollte heute prüfen, welcher Release-Train läuft und in welchem Modus sich die Edges authentifizieren. Laut Arista wurde die Lücke extern entdeckt und wird bereits aktiv ausgenutzt.

Entscheidend ist eine Einschränkung, die viele Meldungen unterschlägt: Betroffen sind ausschließlich Orchestratoren, bei denen sich die Edges per Zertifikat anmelden. Wer den Modus Certificate Deactivated fährt, bei dem die Edge einen Pre-Shared Key nutzt, ist nach Herstellerangabe nicht angreifbar. Und Kunden der Hosted- und Dedicated-Varianten müssen nichts tun, die hat Arista bereits gepatcht. Für zwei Release-Trains gibt es allerdings Stand 22. September 2026 noch gar kein Update, dort helfen nur die Workarounds.

Was ist passiert?

Die Schwachstelle trägt die Kennung CVE-2026-93952 und steckt in der Verarbeitung von Anfragen an die Weboberfläche des VeloCloud Orchestrators. Ein Angreifer ohne gültige Anmeldedaten kann über diesen Weg interne Funktionen des Orchestrators ansprechen, die eigentlich nicht von außen erreichbar sein sollten, und sich damit Privilegien verschaffen. Am Ende dieser Kette steht laut Arista die Kompromittierung des VCO-Hosts selbst, also des Systems, das sämtliche Edges einer SD-WAN-Landschaft konfiguriert.

Arista formuliert in der eigenen Mitteilung ungewöhnlich deutlich, dass die Lücke extern gefunden wurde und bekanntermaßen aktiv ausgenutzt wird. Damit ist die übliche Schonfrist zwischen Veröffentlichung und erstem Exploit hinfällig. Der Hersteller nennt dabei allerdings weder einen Zeitpunkt, ab dem die Angriffe laufen, noch eine Angabe dazu, wie verbreitet sie sind. Beides bleibt bis auf Weiteres unbestätigt, und Meldungen, die konkrete Opferzahlen oder Kampagnennamen nennen, sollten entsprechend vorsichtig gelesen werden.

Ein Angreifer braucht zwei Dinge, die den Angriff nicht unmöglich, aber auch nicht trivial machen: Netzwerkzugang zur VCO-Weboberfläche und den öffentlichen Teil eines Edge-Authentifizierungszertifikats. Der öffentliche Teil eines Zertifikats ist kein Geheimnis im kryptografischen Sinn, er lässt sich beispielsweise beim Verbindungsaufbau einer Edge mitlesen. Der Netzwerkzugang ist deshalb der Hebel, an dem Administratoren kurzfristig drehen können.

Wer ist betroffen?

Betroffen sind ausschließlich selbst betriebene VeloCloud Orchestratoren, bei denen die Edge-Authentifizierung auf Zertifikaten beruht. Arista nennt hier die beiden Modi Certificate Acquire und Certificate Required. Wer Certificate Deactivated einsetzt, bei dem die Edge stattdessen einen Pre-Shared Key verwendet, ist nach Herstellerangabe außen vor. Dieser Modus ist allerdings in neueren Umgebungen eher die Ausnahme, verlassen sollte man sich also nicht auf die Annahme, sondern nachsehen.

• Train 5.2: verwundbar bis einschließlich 5.2.3.15, behoben in 5.2.3.16 und neuer.
• Train 6.4: verwundbar bis einschließlich 6.4.2.7, behoben in 6.4.2.8 und neuer.
• Train 6.1: verwundbar bis einschließlich 6.1.3.7, Stand 22. September 2026 kein Fix verfügbar.
• Train 7.0: verwundbar bis einschließlich 7.0.0.2, Stand 22. September 2026 kein Fix verfügbar.
• Hosted- und Dedicated-Varianten: von Arista bereits gepatcht, kein Handlungsbedarf für Kunden.

Wer auf 6.1 oder 7.0 sitzt, steht damit vor der unangenehmen Situation, eine aktiv ausgenutzte Lücke mit CVSS 10.0 nicht schließen zu können. Hier bleiben nur die unten beschriebenen Eindämmungsmaßnahmen, bis Arista nachliefert, oder ein vorgezogener Wechsel auf einen der gefixten Trains, was im Fall von 7.0 einen Rückschritt bedeuten würde und in der Praxis selten eine realistische Option ist.

Wie kritisch ist das?

Ein CVSS-Wert von 10.0 wird vergeben, wenn ein Angriff ohne Anmeldung, ohne Benutzerinteraktion, über das Netzwerk und mit vollständiger Auswirkung auf Vertraulichkeit, Integrität und Verfügbarkeit möglich ist, und zusätzlich Wirkung über die verwundbare Komponente hinaus entfaltet. Genau das trifft hier zu: Der Orchestrator ist nicht irgendein Server, sondern die Steuerzentrale des gesamten SD-WAN. Wer ihn kontrolliert, kontrolliert die Konfiguration aller angebundenen Standorte.

Verschärfend kommt hinzu, dass dies nicht der erste Vorfall dieser Art in diesem Jahr ist. Bereits im Juli wurde die VCO-Schwachstelle CVE-2026-16812 als aktiv ausgenutzt gemeldet. Ein Teil der jetzt als verwundbar gelisteten Releases enthält deren Korrektur bereits, die Systeme wurden also zwischenzeitlich aktualisiert und sind trotzdem erneut angreifbar. Für die Risikobewertung heißt das: Ein VCO, der aus dem Internet oder aus einem breiten Unternehmensnetz erreichbar ist, muss als exponierte Kernkomponente behandelt werden und nicht als reines Management-Werkzeug im Hintergrund.

Ein Hinweis zur Einordnung, weil er in Diskussionen schnell entsteht: Über eine Aufnahme in den KEV-Katalog der US-Behörde CISA liegt hier nichts vor. Die Aussage zur aktiven Ausnutzung stammt vom Hersteller selbst, das genügt als Handlungsgrundlage vollauf, ist aber etwas anderes als eine behördliche Listung mit verbindlicher Frist.

Was sollten Admins jetzt tun?

• Zuerst Inventar und Version prüfen: Läuft ein on-premises VCO, welcher Release-Train und welche exakte Build-Nummer, und in welchem Modus authentifizieren sich die Edges? Nur die Kombination aus verwundbarer Version und Certificate Acquire beziehungsweise Certificate Required ist angreifbar.
• Auf Train 5.2 oder 6.4 sofort auf 5.2.3.16 beziehungsweise 6.4.2.8 oder neuer aktualisieren. Das ist die einzige echte Behebung.
• Den Zugriff auf die VCO-Weboberfläche auf vertrauenswürdige Administrationsnetze beschränken. Das ist der wirksamste Hebel, weil der Angriff Netzwerkzugang zur Oberfläche voraussetzt.
• Den VCO auf Zugriffe bekannter bösartiger IP-Adressen überwachen und auf unerwarteten ausgehenden Verkehr vom VCO-Host achten.
• Nicht benötigte ausgehende Ports am VCO blockieren, damit ein erfolgreicher Angriff nicht ohne Weiteres nachladen oder Daten abfließen lassen kann.
• Das System auf Backdoor-Daemons und Webshells prüfen und die Administrationsaktivität auf unerwartete Änderungen durchsehen.
• Die Weblogs des VCO auf Anfragen mit ungewöhnlichen URL-artigen Pfaden, kodierten Zeichen, Verweisen auf lokale oder interne Dienste sowie auf auffällig hohe Anfrageraten durchsuchen.
• Auf die von Arista genannten Kompromittierungsindikatoren prüfen: die Datei /usr/local/sbin/.vcnode.js, die Datei /usr/local/sbin/vc-sysmond mit der MD5-Summe dc78e206eaeadec59fc5801fe4556bd0, die Datei /etc/systemd/system/vc-sysmon.service, den HTTP-Header x-vc-opt in den nginx-Logs sowie die Adressen 142.93.149.77 und 104.248.126.159.
• Wichtig dabei: Arista weist ausdrücklich darauf hin, dass kein einzelner dieser Indikatoren für sich genommen eine Kompromittierung beweist. Sie sind Anlass für eine genauere Untersuchung, nicht das Urteil.
• Bei einem Fund den Zustand sichern und Arista TAC einschalten. Logs und Dateisystem-Zeitstempel unbedingt vor jeder Reparatur sichern, sonst gehen die Spuren verloren.
• Nach dem Update eine Incident Response fahren: Zugangsdaten rotieren, die verwalteten Edges prüfen und im Zweifel den Orchestrator neu aufbauen.

Einordnung für Unternehmen

SD-WAN-Orchestratoren sind über die vergangenen Jahre still zu einer der heikelsten Komponenten im Unternehmensnetz geworden. Sie verwalten Tunnel, Routing und Richtlinien über alle Standorte hinweg, und sie brauchen dafür weitreichende Rechte. Gleichzeitig laufen sie oft in einer Ecke des Netzes, die beim Patch-Management nicht dieselbe Aufmerksamkeit bekommt wie Domänencontroller oder Mailserver. Genau diese Kombination macht sie für Angreifer attraktiv.

Für kleinere und mittlere Unternehmen mit mehreren Standorten ergeben sich daraus zwei praktische Konsequenzen. Erstens gehört jede Managementoberfläche, die Netzwerkkomponenten steuert, in ein eigenes, eng gefiltertes Administrationsnetz und niemals ins allgemein erreichbare Unternehmens-LAN oder gar ins Internet. Zweitens braucht es eine gepflegte Liste dieser Systeme samt Versionsstand, weil sonst im Ernstfall Stunden allein damit vergehen, überhaupt festzustellen, ob man betroffen ist.

Wer die Möglichkeit hat, sollte die Gelegenheit außerdem nutzen, um die Annahme zu hinterfragen, ein Managementsystem im eigenen Rechenzentrum sei per se sicherer als eine gehostete Variante. Im vorliegenden Fall war es genau umgekehrt: Die Hosted- und Dedicated-Installationen hatte der Hersteller bereits gepatcht, während die Selbstbetreiber noch handeln müssen und ein Teil von ihnen mangels Update noch nicht einmal kann.

Passende Anleitungen auf S-EDV

• Zero-Trust-Netzwerksegmentierung mit VLANs und Firewall-Regeln zeigt, wie ein separates Administrationsnetz aufgebaut wird, in das eine Oberfläche wie der VCO gehört.
• Site-to-Site-VPN mit WireGuard und IPsec auf OPNsense beschreibt eine Standortvernetzung ohne zentralen Orchestrator als Alternative für kleinere Umgebungen.
• TP-Link Omada: 15 Schwachstellen erlauben Netzwerkübernahme ordnet ein, warum zentrale Netzwerk-Controller generell ein lohnendes Ziel sind.

Quellen

• The Hacker News: New CVSS 10.0 VeloCloud Orchestrator Flaw Actively Exploited, 22. September 2026
• NVD: CVE-2026-93952, National Vulnerability Database des NIST
• Rapid7 Vulnerability Database: CVE-2026-93952, Arista Networks VeloCloud Orchestrator