Cisco Secure Email Gateway: BSI warnt vor aktiv ausgenutzter Lücke – was Admins prüfen sollten

Stellen Sie sich vor, ausdrücklich ein fiktives Szenario: Ein Gerät, dessen einzige Aufgabe darin besteht, eingehende Mails auf Schadsoftware zu prüfen, wird selbst zur offenen Frage. Niemand im Team kann sagen, ob es noch tut, wofür es angeschafft wurde. Genau diese Frage stellt sich derzeit allen, die ein Cisco Secure Email Gateway betreiben.

Die Kernaussage vorweg: Das BSI hat am 15. Oktober 2026 einen Hinweis zur Sicherheitslücke CVE-2026-76519 im Cisco Secure Email Gateway veröffentlicht. Laut Cisco wird die Lücke aktiv ausgenutzt, den CVSS-Wert gibt Cisco mit 9,8 an (CVSS v3.1). Betroffen ist ein Gateway nur, wenn File Reputation aktiviert und einer Mail-Policy zugewiesen ist und zugleich Content Scanner Tools älter als 25.3.0.5525 laufen. Den Fix liefern aktualisierte Content Scanner Tools oder gefixte AsyncOS-Versionen.

Klingt nach Routine? Ist es nicht. Zwischen „Patch einspielen“ und „Patch einspielen, ohne Beweise zu vernichten“ liegt hier ein entscheidender Unterschied.

Was das BSI zur Cisco-Lücke meldet

Das BSI führt den Hinweis als IT-Sicherheitshinweis BITS-H Nr. 2026-297701-1032. Er trägt die Version 1.0, stammt vom Donnerstag, 15. Oktober 2026, und ist mit TLP:CLEAR gekennzeichnet. Das heißt laut BSI: unbegrenzte Weitergabe.

Der Titel ist deutlich: „Cisco Secure Email Gateway: Zero-Day Schwachstelle wird aktiv ausgenutzt – Für einen erfolgreichen Angriff müssen jedoch bestimmte Konfigurationen vorliegen.“ Zwei Hälften, zwei Botschaften. Die erste klingt nach Dringlichkeit, die zweite nach Differenzierung. Beide sind ernst gemeint.

Das BSI stuft die Kritikalität mit 2 ein, Farbe Gelb, auf einer Skala von 1 (Grau) bis 4 (Rot). Die Bedeutung laut BSI: „Maßnahmen müssen zeitnah ergriffen werden. Temporäre Beeinträchtigungen des Regelbetriebs möglich.“ Gelb ist keine Entwarnung. Es ist die Aufforderung, den Kalender zu öffnen und Termine zu verschieben.

Die Primärquelle ist das Cisco-Advisory cisco-sa-esa-afw-zqYJkjxp mit dem Titel „Cisco Secure Email Gateway Arbitrary File Write Vulnerability“. Es wurde am 14. Oktober 2026 veröffentlicht, liegt in Version 1.0 Final vor und trägt die Einstufung Critical. Cisco nennt einen CVSS-Basiswert von 9,8 nach CVSS v3.1 und ordnet die Lücke der Kategorie CWE-23 zu. Zu Workarounds schreibt Cisco: „No workarounds available“.

Wer hat die Sache entdeckt? Laut Cisco erfuhr das Cisco PSIRT im Oktober 2026 von aktiver Ausnutzung, und zwar bei einer internen Sicherheitsprüfung. Das BSI formuliert vorsichtig: „Nach Angaben von Cisco wurde bereits eine aktive Ausnutzung der Schwachstelle beobachtet.“ Wir geben das so wieder, wie es dort steht. Die Beobachtung stammt von Cisco, nicht vom BSI.

Auch die US-Behörde CISA führt die Lücke. Sie hat CVE-2026-76519 am 14. Oktober 2026 in den Katalog Known Exploited Vulnerabilities aufgenommen. Die dort genannte Frist, der 17. Oktober 2026, gilt verbindlich nur für US-Bundesbehörden. Für deutsche Betreibende ist sie kein Gesetz, aber ein brauchbarer Taktgeber.

Wir bei digital-magazin.de haben ein ähnliches Muster schon bei einem anderen Mail-Gateway beschrieben, das im KEV-Katalog gelandet ist. Der Eintrag dort bedeutet: Die Lücke gilt nach Einstufung der CISA als aktiv ausgenutzt, nicht mehr und nicht weniger.

Was sagt das BSI zur Technik? Laut BSI ermöglicht CVE-2026-76519 unter bestimmten Voraussetzungen das Schreiben beliebiger Dateien sowie die Ausführung von Befehlen mit Root-Rechten auf dem zugrunde liegenden Betriebssystem AsyncOS. Die Ursache sei die fehlerhafte Verarbeitung von E-Mail-Anhängen bei aktivierter File-Reputation-Funktion der Advanced Malware Protection (AMP). Ausnutzbar sei die Lücke aus der Ferne und ohne Authentifizierung. Mehr Details gibt es hier nicht, und mehr brauchen Sie für die Verteidigung auch nicht.

Das BSI bewertet die Lage so: E-Mail-Infrastrukturen sind attraktive Ziele für Angreifer, weil sie eine zentrale Rolle in der internen und externen Kommunikation spielen. Eine Kompromittierung des Gateways kann Vertraulichkeit, Integrität und Verfügbarkeit des E-Mail-Verkehrs beeinträchtigen und Ausgangspunkt für weiterführende Angriffe sein. Das ist die nüchterne Beschreibung dessen, was an einem Mail-Gateway hängt: im Grunde alles.

Brisant ist ein weiterer Satz des BSI: „Technische Details oder Proof-of-Concepts sind bislang nicht öffentlich bekannt, dies kann sich jedoch kurzfristig ändern.“ Laut BSI wird damit eine Ausnutzung durch weitere Akteure wahrscheinlich. Die Behörde empfiehlt IT-Sicherheitsverantwortlichen, schnellstmöglich die Schutzmaßnahmen zu prüfen und umzusetzen: die Aktualisierung der Content Scanner Tools beziehungsweise von AsyncOS sowie die Untersuchung auf Anzeichen einer Kompromittierung.

Wann Ihr Cisco Gateway betroffen ist

Die gute Nachricht zuerst: Nicht jedes Gateway ist automatisch ein Problemfall. Laut Cisco sind sowohl physische als auch virtuelle Secure Email Gateways mit verwundbarer AsyncOS-Version betroffen, aber nur, wenn beide Bedingungen erfüllt sind.

• Der File-Reputation-Dienst, Teil von Cisco AMP, ist aktiviert und einer Mail-Policy zugewiesen.
• Die Content Scanner Tools sind älter als Version 25.3.0.5525.

Fehlt eine der beiden Bedingungen, trifft die Beschreibung aus dem Advisory laut Cisco nicht zu. Das ist keine Einladung zum Abwarten. Es ist der Grund, warum die Prüfung als Erstes kommt.

So prüfen Sie File Reputation laut Cisco in der Web-Verwaltungsoberfläche: Öffnen Sie unter „Mail Policies“ die „Incoming Mail Policies“ und dann „Advanced Malware Protection“. Dasselbe gilt für die ausgehende Seite, also „Mail Policies“, dann „Outgoing Mail Policies“ und dann „Advanced Malware Protection“. Wählen Sie dort die jeweilige Mail-Policy aus und kontrollieren Sie, ob das Häkchen bei „Enable File Reputation“ gesetzt ist. Tun Sie das für jede Policy, nicht nur für die Standard-Policy.

Die Version der Content Scanner Tools liefert laut Cisco der CLI-Befehl contentscannerstatus. Liegt die ausgegebene Version unter 25.3.0.5525 und ist File Reputation aktiv, ist Ihr Gateway im Sinne des Advisorys betroffen. Ehrlich gesagt: Dieser Zweischritt dauert wenige Minuten. Ihn zu überspringen, spart Minuten und kostet Gewissheit.

Nicht betroffen sind laut Cisco der Secure Email and Web Manager und die Secure Web Appliance. Bei der Secure Email Cloud Gateway gilt laut Cisco: keine Aktion nötig. Dazu mehr im Abschnitt zu Cluster und Cloud.

Ein praktischer Gedanke am Rande: Die Prüfung setzt voraus, dass Sie überhaupt wissen, welche Geräte im Haus stehen. Wir bei digital-magazin.de haben das Thema in unserem Beitrag zum Inventar als Grundlage der Verteidigung aufgegriffen: Ohne Überblick über den eigenen Bestand lässt sich nicht beurteilen, ob ein Gerät betroffen ist. Das Gateway im Rechenzentrum der Tochtergesellschaft zählt dazu.

Erst prüfen, dann patchen

Jetzt der Kern. Der Reflex vieler Administrierender lautet: Patch verfügbar, Patch einspielen, Ticket schließen. Beim Cisco Gateway kann genau dieser Reflex Beweise vernichten.

Das BSI schreibt: „Vor dem Upgrade, insbesondere einer virtuellen Appliance, sollte eine Kompromittierung ausgeschlossen werden, um bei Verdacht keine forensischen Daten und Logs durch das Einspielen zu zerstören.“ Cisco formuliert es knapper: „Upgrading a compromised instance will destroy forensic data and logs.“

Also zuerst die Prüfung. Cisco nennt dafür einen CLI-Befehl: grep „System Security“ system_logs. Bei Clustern sind die Logs jedes einzelnen Cluster-Geräts zu prüfen. Nicht eines. Jedes.

Der Befehl liefert laut Cisco eine von drei Meldungen. Jede hat eine eigene Konsequenz:

• „Suspected compromise indicator was found“: Cisco wertet das als erkannte Kompromittierung. Kontaktieren Sie das Cisco TAC und folgen Sie den Empfehlungen im Advisory.
• „Security scan did not complete“: Auch hier rät Cisco, das TAC zu kontaktieren. Der Scan hat kein Ergebnis geliefert, also gibt es auch keine Entwarnung.
• „No compromise indicator was found“: Laut Cisco wurde keine Kompromittierung erkannt. Trotzdem sollten Sie auf eine gefixte Version aktualisieren.

Plot Twist: Die dritte Meldung ist beruhigend, aber kein Freibrief. Laut Cisco können Angreifende mit Root-Rechten Spuren entfernen oder verbergen. Cisco empfiehlt deshalb dringend, Netzwerk- und Firewall-Logs außerhalb des betroffenen Geräts gegenzuprüfen.

Das BSI sieht es ebenso. Da Angreifer mit Root-Rechten Spuren löschen oder verändern können, sollten zusätzlich Logs aus anderen Quellen untersucht werden, etwa aus einem SIEM oder von einem Logserver. Als Anhaltspunkte nennt das BSI unerwartete Uploads vom Gateway auf externe Server sowie verdächtige Downloads auf die Instanz.

Meiner Einschätzung nach ist das einer der zentralen Sätze im Hinweis, obwohl er unscheinbar daherkommt. Ein Gerät, das sich selbst auf Kompromittierung prüft, kann nur das finden, was es noch weiß. Ein externer Logserver erinnert sich auch dann, wenn das Gateway es nicht mehr tut.

Wenn der Verdacht besteht: virtuelle Appliance

Für virtuelle Appliances nennt Cisco eine Reihenfolge, die wir hier gekürzt wiedergeben:

1. Sichern Sie zuerst Forensik-Informationen nach Ihrer eigenen Incident-Handling-Policy, bevor weitere Schritte erfolgen.
2. Setzen Sie eine neue VM mit gefixter Version auf.
3. Bauen Sie die Konfiguration neu auf, ohne alte Konfigurationsdateien zu importieren.
4. Erneuern Sie Zugangsdaten und kryptografisches Material.
5. Überwachen Sie das Gerät weiter auf Auffälligkeiten.

Punkt drei dürfte weh tun. Die alte Konfiguration nicht zu übernehmen heißt Handarbeit, und zwar viel. Aber genau darin liegt die Logik: Was von einem möglicherweise kompromittierten System stammt, bekommt kein Vertrauensvorschuss.

Wenn der Verdacht besteht: physische Appliance

Bei einer physischen Appliance lautet Ciscos Empfehlung schlicht: das Cisco TAC kontaktieren. Das wirkt knapp, ist aber folgerichtig. Hier gibt es keine neue VM, die Sie nebenher aufsetzen könnten.

Und wer nach einem früheren Fall sucht, in dem „Patch eingespielt“ nicht gleich „erledigt“ bedeutete: Wir bei digital-magazin.de haben das bei einem anderen Produkt beschrieben, einem früheren Cisco-Fall, bei dem ein Patch allein nicht immer reicht. Beide Fälle sind technisch nicht vergleichbar, die Lehre schon.

Und ohne Verdacht? Laut Cisco gilt: Wer eine betroffene Version betreibt, soll dringend auf eine gefixte Version aktualisieren. Auch das ist eine Aussage, die man nicht dreimal lesen muss.

Patch und Content Scanner Tools

Der Fix hat laut Cisco zwei Wege. Der erste führt über die Content Scanner Tools: Version 25.3.0.5525 oder neuer behebt die Lücke für alle lizenzierten und unterstützten AsyncOS-Versionen. Der zweite führt über AsyncOS selbst.

Das BSI nennt dazu die AsyncOS-Versionen 15.5.5-014 und 16.5.0-780. Diese habe Cisco „bereits im September bereitgestellt“, und sie schließen CVE-2026-76519 und weitere Schwachstellen. Für die Content Scanner Tools nennt das BSI kein Datum, und wir stellen hier auch keines in den Raum.

Cisco gibt für die Fixed Releases diese Zuordnung an:

• AsyncOS 15.5: Update auf 15.5.5-014.
• AsyncOS 16.0: Migration auf eine gefixte Version.
• AsyncOS 16.5: Update auf 16.5.0-780.

Cisco empfiehlt allen, die Versionen vor 16.5 einsetzen, die Migration auf 16.5.0-780. Wer ohnehin einen Versionssprung plant, hat hier einen sachlichen Anlass.

Der bequemere Weg sind die Content Scanner Tools. Laut Cisco braucht deren Update weder ein Software-Upgrade noch einen Neustart. Sind automatische CST-Updates aktiviert, ist nach dem Einspielen keine Aktion nötig. Andernfalls stoßen Sie das Update manuell per CLI-Befehl contentscannerupdate an. Prüfen Sie danach mit contentscannerstatus, ob die Version 25.3.0.5525 oder neuer erreicht ist.

Ein Wort zur Reihenfolge, damit nichts durcheinandergerät: Das geringe Aufwandsniveau des CST-Updates ist kein Argument, die Kompromittierungsprüfung zu überspringen. Es ist ein Argument, sie vorher zu erledigen, weil danach kaum noch etwas im Weg steht. Wer erst aktualisiert und dann prüft, hat die Reihenfolge verwechselt.

Workarounds gibt es laut Cisco keine. Weder Konfigurationstricks noch Zwischenlösungen sind vorgesehen. Wer betroffen ist, muss aktualisieren. Wer glaubt, die Policy kurz auszuschalten genüge, sollte sich an die Formulierung „No workarounds available“ erinnern lassen.

Cluster und Cloud

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptClose-up of a server rack with an email security appliance, blinking status lights, an engineer's hand plugging in a console cable, cool blue light. Photorealistic editorial magazine photo, 16:9. Absolutely no text, no letters, no numbers, no logos, no brand marks.

Cluster verdienen einen eigenen Blick, und zwar aus einem Grund, der in der Architektur liegt. Laut Cisco authentifizieren sich Clustermitglieder untereinander per SSH-Schlüsselpaaren. Bei erfolgreicher Ausnutzung könnten private SSH-Schlüssel auf einem kompromittierten Gerät zugänglich sein und damit weitere Clustermitglieder gefährden.

Die Konsequenz, die Cisco empfiehlt: Jedes Mitglied eines Clusters, in dem mindestens ein Gerät kompromittiert ist, soll in einen sicheren Zustand zurückversetzt werden. Nicht nur das auffällige Gerät. Das gesamte Cluster.

Unsere Einordnung: Ein einzelner Treffer bei der Prüfung kann also den Arbeitsumfang vervielfachen. Deshalb prüfen Sie jedes Cluster-Gerät einzeln, auch wenn die Konfiguration identisch wirkt. Gleich aussehende Geräte haben nicht automatisch gleiche Logs.

Und die Cloud? Für die Cisco Secure Email Cloud Gateway gilt laut Cisco: keine Aktion nötig. Die gefixten Content Scanner Tools seien bereits über den Standard-Updateprozess ausgerollt worden. Cisco hat zudem Cloud-Kunden direkt kontaktiert, bei deren Geräten bösartige Aktivität oder Anzeichen einer möglichen Kompromittierung festgestellt wurden.

Das BSI leitet daraus eine praktische Bitte ab: Prüfen Sie regelmäßig die bei Cisco hinterlegten Mailadressen und Telefonnummern auf eine Kontaktaufnahme. Das klingt banal. Es ist aber genau die Art Banalität, an der Informationsketten scheitern, etwa wenn die Kontaktadresse noch auf eine Person zeigt, die das Unternehmen längst verlassen hat.

Ein Haken bleibt. Cloud-Administrierende ohne CLI-Zugang können die Indikatoren laut Cisco unter Umständen nicht selbst prüfen. Wer in der Cloud sitzt, ist auf die Kommunikation des Herstellers angewiesen. Ob das beruhigt oder nervös macht, ist Temperamentsache.

Härtung: Was Cisco zusätzlich empfiehlt

Das BSI gibt in seinem Hinweis Härtungsempfehlungen wieder, die laut Cisco gelten. Sie ersetzen den Patch nicht, aber sie verringern die Angriffsfläche. Es sind Maßnahmen, die viele Betreibende kennen und die in der Praxis trotzdem gerne auf der Liste „später“ liegen.

• Zugriff aus dem Internet verhindern oder auf vertrauenswürdige Systeme beschränken.
• Das Gateway hinter einer Firewall betreiben.
• Logs an einen externen Logserver weiterleiten.
• Mail- und Management-Funktionen trennen.
• Nicht benötigte Dienste deaktivieren, insbesondere HTTP und FTP.
• HTTP für das Admin-Portal deaktivieren.
• Starke Authentifizierung einsetzen, zum Beispiel SAML oder LDAP, und die Nutzerverwaltung restriktiv führen.
• Ein starkes Admin-Passwort vergeben, mit Admin-Konten restriktiv umgehen und für Administrierende Operator-Konten verwenden.
• TLS/SSL einsetzen.

Auffällig ist der Punkt mit dem externen Logserver. Er taucht in den Härtungsempfehlungen auf und zugleich in der Forensik-Warnung. Er ist die Gelegenheit, aus einer Empfehlung ein Beweismittel zu machen. Wer ihn einrichtet, tut das nicht für die nächste Lücke allein, sondern für jede Frage, die später gestellt wird.

Gleiches gilt für die Konfiguration insgesamt. Wir bei digital-magazin.de haben in einem Beitrag zu einer Lücke in einer KI-Software gezeigt, warum die eigene Konfiguration der erste Prüfpunkt ist. Das Produkt ist ein ganz anderes, der Reflex derselbe: Erst schauen, was tatsächlich aktiv ist, dann bewerten.

Und noch ein Hinweis in eigener Sache: Eine Härtungsliste ist kein Ersatz für die Prüfung auf Kompromittierung. Wer das Admin-Portal absichert, nachdem jemand bereits drin war, schließt die Tür hinter einem Gast.

Was die Quellen nicht sagen

Ein sauberer Artikel zeigt auch seine Grenzen. Was in diesem Abschnitt steht, ist ausdrücklich unsere Einordnung und stammt nicht aus BSI-Hinweis, Cisco-Advisory oder CISA-Eintrag.

Die Quellen nennen keine Zahl betroffener Organisationen. Sie nennen keine Angreifergruppe, keine Branchen und keinen konkreten Deutschland-Bezug über den BSI-Hinweis selbst hinaus. Ob und wo in Deutschland Geräte kompromittiert wurden, lässt sich aus den vorliegenden Informationen nicht ableiten.

Warum das wichtig ist? Weil Lücken in der Lage sind, Spekulationen anzuziehen. Aus „aktiv ausgenutzt“ wird in Diskussionen schnell „Massenangriff“, aus „Konfiguration nötig“ wird „betrifft alle“. Beides sagen die Quellen nicht. Laut Cisco wurde aktive Ausnutzung beobachtet, die CISA führt die Lücke im KEV-Katalog, und das BSI hält weitere Ausnutzung für wahrscheinlich. Das ist die belastbare Lage.

Meiner Einschätzung nach liegt die eigentliche Unsicherheit woanders: bei der Frage, ob ein Gateway in der Vergangenheit bereits auffällig war. Dazu geben die Quellen keine Auskunft, weil sie es nicht können. Das ist Ihre Aufgabe, anhand Ihrer Logs.

Auch zum Zeitpunkt macht das BSI nur eine knappe Aussage: Die AsyncOS-Versionen 15.5.5-014 und 16.5.0-780 stellte Cisco laut BSI bereits im September bereit. Wer daraus ableitet, wie lange die Lücke bekannt oder ausgenutzt war, überinterpretiert. Der Hinweis zu den Versionen und der Beginn einer Ausnutzung sind zwei verschiedene Fragen. Wir lassen die zweite unbeantwortet, weil die Quellen sie unbeantwortet lassen.

Häufige Fragen

Ist mein Cisco Gateway automatisch betroffen?

Nein. Laut Cisco müssen zwei Bedingungen zugleich erfüllt sein: File Reputation ist aktiviert und einer Mail-Policy zugewiesen, und die Content Scanner Tools sind älter als 25.3.0.5525. Prüfen Sie beides, die Version per contentscannerstatus, File Reputation in der Web-Verwaltungsoberfläche.

Reicht es, einfach zu aktualisieren?

Nicht in jedem Fall. Das BSI und Cisco raten, vor dem Upgrade eine Kompromittierung auszuschließen, weil das Einspielen forensische Daten und Logs zerstören kann. Erst prüfen, dann patchen, und die Prüfung mit externen Logs gegenlesen.

Muss ich als Cloud-Kunde etwas tun?

Laut Cisco ist für die Secure Email Cloud Gateway keine Aktion nötig, die gefixten Content Scanner Tools sind über den Standard-Updateprozess ausgerollt. Das BSI rät, die bei Cisco hinterlegten Mailadressen und Telefonnummern regelmäßig auf eine Kontaktaufnahme zu prüfen, da Cisco betroffene Cloud-Kunden direkt kontaktiert.

Gibt es einen Workaround, falls ich nicht sofort patchen kann?

Laut Cisco nicht: „No workarounds available“. Die Härtungsempfehlungen verringern die Angriffsfläche, ersetzen aber weder den Fix noch die Prüfung auf Kompromittierung.

Und jetzt?

Sie wissen nun, was zu tun ist. Bleibt die Reihenfolge, und die ist hier Teil der Sicherheitsmaßnahme.

1. Klären Sie zuerst, ob Ihr Gateway betroffen ist: File Reputation aktiv und einer Mail-Policy zugewiesen, Content Scanner Tools älter als 25.3.0.5525.
2. Prüfen Sie danach auf Kompromittierung, mit dem von Cisco genannten Befehl und mit Logs von außerhalb des Geräts. Sichern Sie bei Verdacht zuerst die forensischen Daten, bei physischen Appliances wenden Sie sich an das Cisco TAC.
3. Aktualisieren Sie anschließend die Content Scanner Tools auf 25.3.0.5525 oder neuer oder wechseln Sie auf eine gefixte AsyncOS-Version, und kontrollieren Sie das Ergebnis.
4. Werten Sie parallel die Logs eines SIEM oder Logservers aus, achten Sie auf unerwartete Uploads auf externe Server und verdächtige Downloads, und richten Sie die Weiterleitung ein, falls sie fehlt.
5. Behandeln Sie Cluster-Mitglieder einzeln, und rechnen Sie bei einem kompromittierten Gerät damit, dass alle Mitglieder zurückgesetzt werden müssen.

Das Gateway soll Mails auf Schadsoftware prüfen. Bis die Schritte oben abgehakt sind, ist es selbst der Prüfling.