Cisco Secure Email Gateway: aktive Angriffe per präparierter Mail

Cisco Secure Email Gateway wird über CVE-2026-76461 aktiv angegriffen. Cisco veröffentlichte den Sicherheitshinweis am 14. September 2026 und aktualisierte ihn am 17. September: Bereits die Verarbeitung einer präparierten E-Mail kann auf einem verwundbaren Gateway ohne Anmeldung zur Ausführung von Betriebssystembefehlen mit Root-Rechten führen.

Betroffen sind physische und virtuelle Appliances mit verwundbaren Cisco-AsyncOS-Versionen, unabhängig von ihrer Konfiguration. Ein Workaround existiert nicht. Betreiber müssen deshalb den Versionsstand prüfen und aktualisieren; gibt es Hinweise auf eine Ausnutzung, ist die Wiederherstellung als eigener Sicherheitsvorfall zu behandeln.

Der normale Mailpfad genügt als Angriffsweg

Die Schwachstelle liegt in der Parsing-Logik für E-Mails. Unzureichend geprüfte Eingaben erlauben es, schädliche SQL-Anweisungen in einer Nachricht durch das betroffene Gerät verarbeiten zu lassen. Daraus kann die Ausführung beliebiger Befehle mit den höchsten Rechten des zugrunde liegenden Betriebssystems entstehen.

Das am 15. September veröffentlichte MS-ISAC-Advisory bestätigt die aktive Ausnutzung und hält fest, dass der Angriff weder von einer besonderen Funktion noch von einem bestimmten, zum Internet geöffneten Port abhängt. Ein Benutzer muss keinen Anhang öffnen oder einen Link anklicken; entscheidend ist, dass ein verwundbares Gateway die manipulierte Nachricht verarbeitet.

Secure Email and Web Manager und Secure Web Appliance sind von dieser konkreten Schwachstelle nicht betroffen. Das darf nicht mit den weiteren, gleichzeitig veröffentlichten Sicherheitsproblemen in Cisco-Produkten verwechselt werden: Die hier relevante Root-Befehlskette über die E-Mail-Verarbeitung betrifft Secure Email Gateway.

Diese AsyncOS-Stände schließen die Lücke

Die Warnung des kanadischen Cyber Centre führt die betroffenen Versionsgrenzen auf und bestätigt zudem, dass die US-Behörde CISA CVE-2026-76461 am 14. September 2026 in ihren Katalog nachweislich ausgenutzter Schwachstellen aufgenommen hat. Für die Patchentscheidung gelten folgende erste korrigierte Versionen:

AsyncOS 15.5 und älter: 15.5.5-014
AsyncOS 16.0: 16.0.4-302
AsyncOS 16.5: 16.5.0-780

Ein System ist nicht allein deshalb geschützt, weil es zum Zweig 15.5, 16.0 oder 16.5 gehört: Der vollständige Build-Stand muss mindestens der jeweils genannten korrigierten Version entsprechen. Für Installationen vor 16.5 wird die Migration auf 16.5.0-780 empfohlen. Nach einem Upgrade startet die Appliance neu, weshalb redundante Mailpfade und das Wartungsfenster in die Einsatzplanung gehören.

Die verwalteten Geräte von Cisco Secure Email Cloud wurden bereits auf 16.5.0-780 aktualisiert. Kunden dieses Dienstes, bei deren Geräten mögliche schädliche Aktivität erkannt wurde, wurden direkt kontaktiert. On-Premises-Systeme müssen dagegen von ihren Betreibern selbst inventarisiert, geprüft und aktualisiert werden.

Bei Verdacht ist Aktualisieren keine Bereinigung

Ein Patch verhindert eine künftige Ausnutzung der bekannten Lücke, beseitigt aber nicht automatisch die Folgen eines bereits erlangten Root-Zugriffs. Angreifer mit diesen Rechten können lokale Belege entfernen oder verbergen. Ein unauffälliges Protokoll genügt daher nicht, um eine frühere Kompromittierung sicher auszuschließen.

Die technischen Hinweise von Cisco nennen als ersten Prüfpunkt die mail_logs; ein nicht abschließendes Erkennungsmuster sucht dort nach der Kombination „COPY“ und „TO PROGRAM“. Zusätzlich sollen außerhalb der Appliance gespeicherte Netzwerk- und Firewall-Protokolle auf unerwartete Uploads zu externen IP-Adressen sowie Downloads aus schädlichen Netzen geprüft werden.

Für eine virtuelle Appliance mit begründetem Ausnutzungsverdacht ergibt sich daraus eine andere Reihenfolge als beim normalen Patchen:

Forensisch relevante Informationen, vorhandene Protokolle und Konfigurationsdaten sichern, bevor die Instanz ersetzt wird.
Eine neue virtuelle Maschine mit einer korrigierten AsyncOS-Version bereitstellen und die Produktkonfiguration kontrolliert neu aufbauen.
Zugangsdaten und auf der Appliance installiertes kryptografisches Material erneuern.
Das wiederhergestellte System weiter auf ungewöhnliches Verhalten überwachen.

Bei verdächtigen physischen Appliances ist der Cisco-Support einzubeziehen. Diese Trennung ist wesentlich: Auf einem System ohne Verdachtsmerkmale ist das Update die zentrale Abhilfe; bei möglichen Spuren einer Ausnutzung kommen Beweissicherung und Wiederherstellung aus einem vertrauenswürdigen Zustand hinzu.

Ein kompromittiertes Cluster-Mitglied betrifft den ganzen Verbund

Die Aktualisierung des Hinweises vom 17. September präzisiert das Risiko für Cluster. Mitglieder authentifizieren sich untereinander mit SSH-Schlüsselpaaren. Werden private Schlüssel auf einer kompromittierten Appliance zugänglich, können damit auch weitere Geräte des Verbunds gefährdet werden.

Enthält ein Cluster mindestens ein nachweislich kompromittiertes Mitglied, muss deshalb jedes Mitglied wieder in einen sicheren Zustand versetzt werden. Auch bei der Protokollprüfung sind die mail_logs aller einzelnen Cluster-Geräte einzubeziehen; die Untersuchung nur des zuerst auffälligen Knotens reicht nicht aus.

Was über die laufenden Angriffe noch offen ist

Bestätigt sind die aktive Ausnutzung, der Angriffsweg über eine präparierte E-Mail, die mögliche Befehlsausführung als Root, die betroffenen Versionszweige und die verfügbaren Fixstände. Öffentlich benannt sind bislang weder verantwortliche Akteure noch die Zahl betroffener Organisationen oder ein einheitliches Angriffsziel.

Damit bleibt die Einsatzentscheidung zweigeteilt: Verwundbare Geräte ohne Hinweise auf einen Angriff benötigen mindestens den passenden Fixstand. Wo Indikatoren oder andere belastbare Verdachtsmomente vorliegen, beginnt dagegen eine Incident-Response-Untersuchung; das bloße Einspielen des Updates stellt das Vertrauen in die Appliance nicht wieder her.

Lesen Sie auch:

Cisco-Mail-Gateways werden aktiv angegriffen – eine präparierte Mail reicht