Aktive Angriffe zielen auf VeloCloud-Orchestrator-Server mit aktivierter Zertifikatsauthentifizierung

Arista gab am 22. September 2026 bekannt, dass Angreifer eine kritische Sicherheitslücke in On-Premises-Bereitstellungen von VeloCloud Orchestrator ausnutzen. Die Managementplattform steuert VeloCloud-SD-WAN-Edge-Geräte. Ein kompromittierter Orchestrator kann daher als Einstiegspunkt in das gesamte verwaltete Netzwerk dienen.

Die als CVE-2026-93952 geführte Sicherheitslücke hat einen CVSS-3.1-Score von 10,0. Sie ermöglicht es einem entfernten, nicht authentifizierten Angreifer, auf privilegierte interne Funktionen zuzugreifen und den VCO-Host möglicherweise zu kompromittieren.

Die Sicherheitslücke lässt sich nicht in allen VCO-Konfigurationen ausnutzen. Der beschriebene Angriffsweg setzt eine zertifikatsbasierte Authentifizierung zwischen Edge-Geräten und dem Orchestrator, Netzwerkzugriff auf die VCO-Weboberfläche sowie den öffentlichen Teil eines Edge-Authentifizierungszertifikats voraus.

Das Risiko hängt von der Edge-Authentifizierungskonfiguration ab

VeloCloud-Edge-Geräte können sich über drei Modi bei VCO authentifizieren:

• Certificate Deactivated, bei dem ein Pre-Shared Key verwendet wird.
• Certificate Acquire, bei dem ein vom Orchestrator ausgestelltes Zertifikat verwendet wird.
• Certificate Required, bei dem ebenfalls ein vom Orchestrator ausgestelltes Zertifikat verwendet wird.

Arista identifizierte die zertifikatsbasierte Edge-Authentifizierung als Voraussetzung für eine Gefährdung. Es wurde nicht bekannt gegeben, ob CVE-2026-93952 den Modus Certificate Acquire, Certificate Required oder beide Modi betrifft.

Ein Angreifer muss außerdem die VCO-Weboberfläche erreichen können und über den öffentlichen Teil eines Edge-Authentifizierungszertifikats verfügen. Sobald diese Voraussetzungen erfüllt sind, ist keine Authentifizierung des Angreifers erforderlich.

Der CVSS-Vektor der Sicherheitslücke lautet CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Er beschreibt eine über das Netzwerk erreichbare Schwachstelle mit geringer Angriffskomplexität, für deren Ausnutzung weder Berechtigungen noch Benutzerinteraktion erforderlich sind und die potenziell schwerwiegende Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit hat.

Die konkrete Softwarefehler, die den Angriff ermöglicht, wurde bislang nicht öffentlich beschrieben. Eine CWE-Klassifizierung liegt nicht vor. Arista machte auch keine Angaben zu den beteiligten Anfragen, der internen Komponente oder dem aufgetretenen Verarbeitungsfehler. Das Unternehmen erklärte, die Sicherheitslücke sei extern entdeckt worden und werde bereits ausgenutzt, nannte jedoch weder den Beginn der Angriffe noch die Zahl der möglicherweise kompromittierten Systeme oder Organisationen.

Hosted- und Dedicated-VCO-Instanzen wurden vor der öffentlichen Bekanntgabe aktualisiert. Das verbleibende Risiko betrifft daher vor allem kundenseitig verwaltete On-Premises-Installationen.

Fehlerbehebungen sind nur für zwei Release-Zweige verfügbar

Die am 22. September gemeldeten betroffenen und korrigierten Versionen sind:

Release-Zweig	Betroffene Versionen	Fehlerbereinigte Version
5.2	5.2.3.15 und früher	5.2.3.16 und später
6.1	6.1.3.7 und früher	Keine Fehlerbehebung verfügbar
6.4	6.4.2.7 und früher	6.4.2.8 und später
7.0	7.0.0.2 und früher	Keine Fehlerbehebung verfügbar

Organisationen im Release-Zweig 5.2 sollten auf Version 5.2.3.16 oder eine spätere Version aktualisieren. Betreiber von 6.4 sollten Version 6.4.2.8 oder höher installieren.

Für die betroffenen Release-Zweige 6.1 und 7.0 war zum Zeitpunkt der Berichterstattung noch keine korrigierte Version veröffentlicht worden. Arista erklärte, dass Updates für betroffene, weiterhin unterstützte Release-Zweige in den Sicherheitshinweis aufgenommen würden, sobald sie verfügbar sind.

Kunden mit einem nicht unterstützten Release-Zweig sollten sich an das Technical Assistance Center von Arista wenden, um einen Upgrade-Pfad zu besprechen. Betreiber von 6.1- und 7.0-Systemen sollten außerdem die Hinweise des Herstellers verfolgen und nicht davon ausgehen, dass sich das Risiko allein durch Konfigurationsänderungen beseitigen lässt.

Eine Kompromittierung des Orchestrators kann sich auf verwaltete Edge-Geräte ausweiten

VCO ist der Managementserver für die VeloCloud-SD-WAN-Edge-Infrastruktur. Eine erfolgreiche Ausnutzung kann daher weitreichendere Folgen haben als eine Kompromittierung des Orchestrator-Hosts allein.

Zu den unmittelbaren Folgen zählen der unbefugte Zugriff auf privilegierte interne Funktionen sowie eine mögliche Beeinträchtigung der Vertraulichkeit, Integrität und Verfügbarkeit von VCO und den dort verwalteten Daten. Da der Server Edge-Geräte administriert, kann ein Angreifer mit Kontrolle über VCO zudem die Möglichkeit erhalten, die verwaltete Edge-Umgebung zu verändern oder anderweitig zu manipulieren.

Mögliche Aktivitäten nach einer Kompromittierung sind unbefugte administrative Änderungen, die Bereitstellung von Webshells, die Installation persistenter Daemons und unerwartete ausgehende Verbindungen vom VCO-Server. Angreifer könnten über die kompromittierte Managementebene außerdem Edge-Konfigurationen manipulieren.

Diese Aktivitäten sind mögliche Folgen und Ansatzpunkte für die Erkennung, stellen jedoch keine Bestätigung dar, dass jedes kompromittierte System dieselben Artefakte aufweist. Arista wies darauf hin, dass kein einzelner veröffentlichter Indikator eine Ausnutzung über CVE-2026-93952 eindeutig belegt.

Verteidiger sollten nach Host-Artefakten und ungewöhnlichen Webanfragen suchen

Administratoren sollten zunächst die VCO-Webzugriffsprotokolle untersuchen. Verdächtige Muster sind ungewöhnliche URL-ähnliche Pfade, codierte Zeichen, Verweise auf interne oder lokale Dienste sowie Anfragevolumina, die deutlich vom normalen Managementverkehr abweichen.

Die veröffentlichten Indikatoren sind:

Typ	Indikator
Datei	/usr/local/sbin/.vcnode.js
Datei	/usr/local/sbin/vc-sysmond
MD5 für vc-sysmond	dc78e206eaeadec59fc5801fe4556bd0
Systemd-Unit	/etc/systemd/system/vc-sysmon.service
HTTP-Header im Nginx-Log	x-vc-opt
IP-Adresse	142.93.149[.]77
IP-Adresse	104.248.126[.]159

Die Untersuchung sollte sich nicht auf diese Liste beschränken. Sicherheitsteams sollten nach neu angelegten oder veränderten Diensten, Webshell-ähnlichen Dateien, nicht erklärbaren Administratoraktionen und ausgehendem Datenverkehr suchen, der nicht dem erwarteten Verhalten des Orchestrators entspricht.

Verbindungen zu den beiden veröffentlichten IP-Adressen sollten untersucht werden. Eine Übereinstimmung mit einer IP-Adresse allein beweist jedoch keine Ausnutzung. Gleiches gilt für ungewöhnliche Anfragen und einzelne Datei-Artefakte.

Werden Indikatoren oder verdächtige Aktivitäten gefunden, sollten Administratoren den aktuellen Systemzustand sichern, bevor Abhilfemaßnahmen die verfügbaren Beweise verändern. Zu den wichtigen Beweismitteln gehören Webzugriffs-, Backend-Anwendungs-, System- und Datenbankprotokolle sowie Zeitstempel des Dateisystems.

Arista empfiehlt, nach der Feststellung einer möglichen Kompromittierung das TAC oder das zuständige Arista-Account-Team zu kontaktieren.

Patchen, Zugriff beschränken und verdächtige Hosts als kompromittiert behandeln

Wo eine Fehlerbehebung verfügbar ist, sollte die entsprechende Version vorrangig installiert werden. Bis dahin sollten Betreiber den Zugriff auf die VCO-Weboberfläche so beschränken, dass sie nur aus vertrauenswürdigen Administrationsnetzwerken erreichbar ist.

Weitere Schutzmaßnahmen sind:

1. Überwachung des Datenverkehrs zu und von den veröffentlichten bösartigen IP-Adressen.
2. Untersuchung unerwarteter ausgehender Verbindungen vom VCO-Host.
3. Blockieren nicht benötigter ausgehender Ports, sofern dies die betrieblichen Anforderungen zulassen.
4. Suche nach nicht autorisierten Daemons, veränderten Diensten und Webshells.
5. Überprüfung der jüngsten Administratoraktivitäten und Konfigurationsänderungen.
6. Validierung des Zustands und der Konfiguration der verwalteten Edge-Geräte.

Nach der Aktualisierung eines möglicherweise exponierten Systems sollten Organisationen Zugangsdaten rotieren, Administratoraktivitäten untersuchen und überprüfen, ob verwaltete Edge-Geräte verändert wurden. Besteht der Verdacht auf eine Kompromittierung, ist es sicherer, den Orchestrator aus vertrauenswürdigen Quellen wiederherzustellen oder zu ersetzen, als das Update als ausreichende Abhilfemaßnahme zu betrachten.

Ein Host mit entsprechenden Indikatoren, anomalen Managementaktionen oder verdächtigem Netzwerkverkehr sollte als potenziell kompromittiert behandelt werden und nicht lediglich als verwundbar.

Eine zweite kritische VCO-Sicherheitslücke folgt auf einen früheren KEV-Fall

CVE-2026-93952 folgt auf eine weitere kritische Sicherheitslücke in VeloCloud Orchestrator, CVE-2026-16812, über die im Juli berichtet wurde. Auch diese frühere Sicherheitslücke erhielt einen CVSS-Score von 10,0 und wurde als CWE-78 klassifiziert.

Ihr Expositionsmodell war jedoch ein anderes. CVE-2026-16812 war Berichten zufolge in der Standardkonfiguration ausnutzbar und ließ sich nicht durch Konfigurationseinstellungen verhindern. Die neu gemeldete Sicherheitslücke setzt dagegen zertifikatsbasierte Edge-Authentifizierung und die Erreichbarkeit der Weboberfläche voraus.

Die CISA nahm CVE-2026-16812 am 27. Juli 2026 in ihren Katalog der bekannten ausgenutzten Sicherheitslücken auf und setzte für US-Bundesbehörden eine Frist zur Behebung bis zum 30. Juli 2026. Vorgeschrieben war die Anwendung der Maßnahmen des Herstellers unter Beachtung der risikobasierten Update-Vorgaben aus BOD 26-04 sowie der forensischen Triage-Anforderungen der CISA. Wo keine Maßnahmen zur Risikominderung verfügbar waren, sahen die geltenden Vorgaben die Einstellung der Nutzung vor.

Für CVE-2026-93952 wurde bislang kein CISA-KEV-Eintrag veröffentlicht. Die bestätigte aktive Ausnutzung macht das Patchen, die Verringerung der Angriffsfläche und die Prüfung auf eine Kompromittierung für Betreiber zertifikatsbasierter On-Premises-VCO-Systeme dennoch zu unmittelbaren Prioritäten.