Cisco Secure Email Gateway und SD-WAN Manager: Fehlerbehebungen prüfen und Beweise für eine Kompromittierung sichern

Worum es geht

Stand: 25. Oktober 2026. Dieser Artikel stützt sich auf Ciscos E-Mail-Sicherheitshinweis in Version 1.0 vom 14. Oktober 2026 und den SD-WAN-Sicherheitshinweis in Version 1.1 vom 2. Oktober 2026. Vor Massnahmen beide Hinweise, ihre Tabellen mit bereinigten Versionen und die Wiederherstellungsanweisungen des Supports erneut prüfen.

CVE-2026-76519 betrifft die Dateiverarbeitung von Secure Email Gateway; CVE-2026-76504 ermöglicht die Umgehung der Authentifizierung in Catalyst SD-WAN Manager. CISA nahm sie am 14. Oktober beziehungsweise 30. September 2026 in ihren Katalog ausgenutzter Schwachstellen auf. E-Mail-Eintrag, SD-WAN-Eintrag.

Warum es wichtig ist

Exposition, Patch-Installation und Untersuchung einer möglichen Kompromittierung getrennt beurteilen. Ciscos SD-WAN-Wiederherstellungsverfahren verlangt ausdrücklich, vor dem Upgrade Beweise zu sammeln und anschliessend vom Support analysieren zu lassen. Sobald die Beweise gesichert sind, sollte das Upgrade nicht auf diese Scan-Ergebnisse warten. Das Wiederherstellungsverfahren für das betroffene Produkt und die jeweilige Bereitstellungsart anwenden; eine allgemeine Anweisung zur Wiederherstellung aus einem Backup reicht nicht aus.

So wird es angewendet

• E-Mail-Exposition und Fehlerbehebung: Prüfen, ob AMP File Reputation einer E-Mail-Richtlinie zugewiesen ist und die Version von Content Scanner Tools unter 25.3.0.5525 liegt. Bereinigte AsyncOS-Versionen sind 15.5.5-014 und 16.5.0-780; von 16.0 muss migriert werden. Für ältere Versionsreihen empfiehlt Cisco 16.5.0-780. Unterstützte lizenzierte Versionen können auch das korrigierte Scanner-Paket erhalten. E-Mail-Sicherheitshinweis.
• E-Mail-Prüfung: contentscannerstatus ausführen; bei Bedarf mit contentscannerupdate ein manuelles Update anfordern; danach erneut prüfen, ob 25.3.0.5525 oder neuer installiert ist. Dieses Paket-Update erfordert keinen Neustart. Auf jedem Cluster-Mitglied Folgendes prüfen:

grep "System Security" system_logs

Meldungen über eine vermutete Kompromittierung oder unvollständige Scans an den Cisco-Support eskalieren. Mit externen Netzwerkprotokollen abgleichen.

• E-Mail-Wiederherstellung: Zuerst Beweise sichern. Bei virtuellen Appliances mit Verdacht auf Kompromittierung bereinigte Ersatzinstanzen bereitstellen, die Konfiguration ohne Import alter Dateien neu erstellen sowie Zugangsdaten und kryptografisches Material erneuern. Jedes Mitglied eines betroffenen Clusters wiederherstellen. Die Wiederherstellung physischer Appliances erfordert den Cisco-Support. Die Überwachung fortsetzen.
• SD-WAN-Fehlerbehebungen: Versionen vor der jeweils zutreffenden Mindestversion sind unabhängig von der Konfiguration anfällig. Die Tabelle des Herstellers mit den ersten bereinigten Versionen verwenden:

Versionsreihe	Erste bereinigte Version
Älter als 20.9	Auf eine bereinigte Version migrieren
20.9	20.9.10.1
20.12	20.12.8.2
20.15	20.15.6.1
20.18	20.18.4.1
26.1	26.1.2.1
26.2	26.2.1

Der Live Protect-Schutz bietet vorübergehend einen Teilschutz, behebt die Schwachstelle jedoch nicht. Während der Vorbereitung des Upgrades den Verwaltungszugriff auf vertrauenswürdige Hosts beschränken. SD-WAN-Sicherheitshinweis.

• SD-WAN-Untersuchung: Vor dem Upgrade die Ausgabe von request admin-tech von allen Managern sichern, einschliesslich Cluster- und Disaster-Recovery-Knoten. Log und Tech auswählen. Alle Knoten aktualisieren, danach die Pakete zur Suche nach Indikatoren an den Cisco-Support übermitteln; bei festgestellter Kompromittierung dessen zusätzliche Wiederherstellungsanweisungen befolgen. In der aktuellen Hauptversion bleiben, sofern der Support nichts anderes anweist. Behebungsverfahren.
• SD-WAN-Protokollprüfung: Unerwartete Authentifizierungsaktivitäten in /var/log/nms/containers/service-proxy/serviceproxy-access.log und /var/log/nms/vmanage-server.log mit nicht autorisierten Adressen abgleichen. Die Anleitung zur Behebung schreibt das Container-Verzeichnis hingegen service_proxy; den lokalen Pfad bei Bedarf mit dem Support klären. Ein fehlendes Protokoll ist kein unauffälliger Befund. Reservierte Namen für Dienstkonten allein belegen keine Kompromittierung. Befunde für den Support sichern, statt Konten allein aufgrund eines übereinstimmenden Namens zu löschen.

Stolpersteine

Ein angefordertes Scanner-Update belegt nicht, dass die neue Version installiert wurde. Ebenso ist ein fehlgeschlagener Sicherheitsscan kein unauffälliger Befund. Vor Abschluss des Vorfalls für jeden Knoten die resultierende Version, den Verweis auf das Beweispaket, das Untersuchungsergebnis und ausstehende Wiederherstellungsaufgaben als Abnahmenachweis des Betreibers festhalten.