Am 14. Oktober 2026 hat die US-Behörde CISA vier Schwachstellen in drei Produkten in ihren Katalog bekannter, aktiv ausgenutzter Lücken (KEV) aufgenommen: CVE-2026-0322 in Palo Alto PAN-OS, die Cisco-Lücke CVE-2026-76519 im Secure Email Gateway sowie die beiden AhsayCBS-Lücken CVE-2026-105133 und CVE-2026-105134. Für die PAN-OS-Lücke beschreibt der Eintrag eine Code-Injection, die einem authentifizierten Angreifer mit Netzwerkzugang Codeausführung mit Root-Rechten auf der Firewall erlaubt. Die beiden Ahsay-Einträge verweisen aufeinander: CISA vermerkt, dass sich CVE-2026-105133 mit CVE-2026-105134 verketten lässt.
Die Frist vom 17. Oktober gilt ausschließlich für US-Bundesbehörden. Wenn Sie anderswo Systeme betreiben, bindet Sie das formal nicht. Als Priorisierungssignal taugt der Katalog trotzdem, wie schon bei der Zimbra-Command-Injection, die CISA in denselben Katalog aufnahm: Ein KEV-Eintrag besagt, dass Ausnutzung beobachtet wurde, nicht, dass gerade Ihr System betroffen ist.
Zur Quellenlage: Die PAN-OS-Angaben stammen aus dem Advisory von Palo Alto Networks, die KEV-Angaben aus dem CISA-Katalog. Die Herstellerseiten von Cisco und Ahsay liegen nicht vor. Hier stützen wir uns auf Help Net Security und sagen das jeweils dazu.
Zwei Dinge bleiben offen. Ob die Lücken in Ransomware-Kampagnen genutzt werden, führt der KEV-Katalog bei allen vier Einträgen als „Unknown“. Und wie verbreitet die Ausnutzung in Deutschland oder der EU ist, geht aus den Quellen nicht hervor. Das ist weder Entwarnung noch Alarm, sondern ein Grund, die eigene Konfiguration zu prüfen.
PAN-OS CVE-2026-0322: Wer betroffen ist und was der Hersteller sagt
Palo Alto Networks hat die Lücke CVE-2026-0322 am 14. Oktober 2026 veröffentlicht und die Advisory am 15. Oktober aktualisiert. Betroffen ist das Management-Interface von PAN-OS. Ein authentifizierter Angreifer mit Netzwerkzugang kann dort laut Herstellerangabe beliebigen Code mit Root-Rechten auf der Firewall ausführen. „Authentifiziert“ klingt nach Entwarnung, ist aber keine: Wer Zugangsdaten hat oder sie erbeuten kann, bekommt damit das ganze Gerät.
Welche Produkte betroffen sind
Palo Alto nennt PA-Series- und VM-Series-Firewalls sowie Panorama (virtuell und M-Series). Cloud NGFW und Prisma Access sind nach Herstellerangabe nicht betroffen. Eine besondere Konfiguration ist laut Advisory nicht nötig, um angreifbar zu sein. Sie müssen also nicht nach einer riskanten Einstellung suchen, sondern gleich die Version prüfen.
Wie der Hersteller das Risiko einstuft
Palo Alto vergibt einen CVSS-Wert von 8,6 (Severity „HIGH“), die Dringlichkeit „HIGHEST“ und den Exploit-Status „ATTACKED“. Das Risiko sei am höchsten, wenn das Management-Interface aus dem Internet erreichbar ist. Umgekehrt gilt laut Hersteller: Wer den Zugriff gemäß den empfohlenen Best Practices auf vertrauenswürdige interne IP-Adressen beschränkt, minimiert das Risiko. Minimiert heißt allerdings nicht beseitigt.
Zur Ausnutzung schreibt Palo Alto, es sei sehr begrenzte Ausnutzung gegen das Management-Interface beobachtet worden. Drei IP-Adressen werden mit Exploit-Versuchen in Verbindung gebracht: 66[.]42[.]72[.]14, 208[.]83[.]239[.]114 und 149[.]248[.]47[.]234. Sie taugen als Suchbegriffe für Ihre Logs. Dass sie fehlen, beweist allerdings nichts, denn die Liste stammt aus der Beobachtung des Herstellers und nicht aus Ihrem Netz.
Nicht verwechseln: CVE-2026-0300
Eine andere PAN-OS-Lücke aus dem Frühjahr dürfen Sie nicht verwechseln: CVE-2026-0300 mit CVSS 9,8 betrifft das User-ID Authentication Portal (Captive Portal) und nicht das Management-Interface. Ein erledigter Patch für CVE-2026-0300 sagt deshalb nichts über CVE-2026-0322. Prüfen Sie beide Advisories getrennt und dokumentieren Sie für jede den erreichten Stand.
PAN-OS absichern: Fixversionen, Jump Host und die Grenzen der Signaturen
Für diese Lücke nennt Palo Alto Networks keine Workarounds. Der Hersteller schreibt wörtlich: „No known workarounds exist for this issue.“ Es bleibt das Update.
Immerhin gibt es eine Möglichkeit, das Risiko zu senken. Der Hersteller beschreibt eine Zugriffsbeschränkung auf einen Jump Host: Nur dieses eine System darf das Management-Interface erreichen. Das verkleinert die Angriffsfläche erheblich, behebt aber die Lücke nicht. Die Firewall bleibt verwundbar, sie ist nur schwerer zu erreichen. Als Dauerlösung taugt das nicht, als Überbrückung bis zum Wartungsfenster durchaus.
Für das Update nennt die Advisory Mindestversionen je Zweig:
Mindestens behobene PAN-OS-Version je Zweig
Stand: Update der Advisory vom 15.10.2026. Quelle: Palo Alto Networks.
Die Tabelle nennt nur die jeweils neuesten Zielstände. Wer eine ältere Minor-Version betreibt, hat laut Hersteller oft eigene Hotfix-Stände. Ein Beispiel aus der Advisory: Wer 11.1.8 bis 11.1.10 einsetzt, kann auf 11.1.10-h35 oder auf 11.1.16-h3 und neuer gehen. Lesen Sie deshalb die Zeile Ihrer konkreten Minor-Version in der Advisory nach.
Auch die Signaturen sind kein Ersatz für das Update. Kunden mit Threat-Prevention-Abonnement erhalten mit den Threat IDs 510046 und 510047 laut Hersteller nur begrenzten Schutz. Begrenzt heißt: Bekannte Angriffsmuster werden erkannt, Varianten womöglich nicht. Dazu kommt eine Voraussetzung, die im Alltag gern untergeht: Die Signaturen brauchen SSL-Decryption für den eingehenden Verkehr zum Management-Interface. Ohne sie sehen die Signaturen nichts Verwertbares. Palo Alto empfiehlt bei Betroffenheit ausdrücklich das Upgrade.
Als Empfehlung ergibt sich eine knappe Reihenfolge. Prüfen Sie zuerst, ob das Management-Interface aus dem Internet erreichbar ist, denn dort sieht der Hersteller das höchste Risiko. Gleichen Sie dann Ihre installierte Version mit der Advisory ab. Und falls das Update nicht sofort möglich ist, ist der Jump Host die dokumentierte Zwischenlösung, mehr nicht.
Cisco Secure Email Gateway: Zwei Bedingungen, die Sie prüfen können
Beim Cisco Secure Email Gateway (SEG) lässt sich die Betroffenheit mit zwei Prüfpunkten eingrenzen. Zuerst zur Lücke selbst: CVE-2026-76519 steht im KEV-Katalog als Relative-Path-Traversal-Schwachstelle. Ein unauthentifizierter Angreifer aus der Ferne kann demnach beliebige Dateien auf das zugrunde liegende Betriebssystem schreiben. Der Auslöser ist unspektakulär: eine E-Mail mit präpariertem Anhang, die durch das Gerät läuft. Ein Angreifer braucht keinen Login, nur einen Briefkasten, den das Gateway ohnehin bedient.
Ob Ihre Appliance tatsächlich verwundbar ist, hängt laut Help Net Security, die Cisco zitiert, von zwei Bedingungen ab, die beide zutreffen müssen. Erstens: Der File-Reputation-Dienst, Teil von Cisco AMP, ist aktiviert und einer Mail-Policy zugewiesen. Zweitens: Die Version der Content Scanner Tools liegt unter 25.3.0.5525. Betroffen sind laut dieser Darstellung physische wie virtuelle Geräte unter AsyncOS. Entscheidend ist Ihre tatsächliche Konfiguration, nicht die Lizenz.
Zur Abhilfe: Cisco nennt demnach keine Workarounds. Der Fix kommt über die Content Scanner Tools ab Version 25.3.0.5525 und verlangt weder ein Software-Upgrade noch einen Neustart. Kunden mit AsyncOS älter als 16.5 sollen auf 16.5.0-780 migrieren.
Ein Vorbehalt gehört dazu: Die Cisco-Advisory selbst liegt uns nicht vor. Die Angaben zu Bedingungen und Fix stammen aus der Sekundärquelle. Gleichen Sie deshalb die Versionsnummern vor dem Einspielen mit dem Originalhinweis von Cisco ab.
Spuren suchen, wo der Angreifer sie nicht löschen kann
Ein Update schließt die Lücke, beantwortet aber nicht die Frage, ob schon jemand durch die Tür gegangen ist. Laut Help Net Security warnt Cisco, dass Angreifer mit Root-Zugriff Spuren der Ausnutzung entfernen oder verbergen können. Das Gerät, das Auskunft geben soll, ist nach einer Übernahme also kein verlässlicher Zeuge mehr.
Die naheliegende Konsequenz: Suchen Sie dort, wo der Angreifer nicht ohne Weiteres hinkommt. Cisco rät laut Help Net Security, Netzwerk- und Firewall-Logs außerhalb des Geräts auf verdächtige Aktivität zu prüfen, etwa auf unerwartete Uploads zu externen IP-Adressen. Praktisch heißt das, den ausgehenden Verkehr des Gateways aus Sicht der vorgelagerten Firewall oder eines zentralen Log-Systems zu betrachten. Ein Mail-Gateway, das plötzlich Daten an eine Adresse schickt, mit der es nie zu tun hatte, fällt dort auf, selbst wenn das Gerät selbst schweigt.
Als eigene Einschätzung, nicht als Herstellervorgabe: Diese Logik lässt sich auf Firewall und Backup-Server übertragen, sofern deren Logs extern vorliegen. Belegt ist die Empfehlung in den vorliegenden Angaben nur für Cisco. Wer keine externe Protokollierung hat, sollte das als eigene Erkenntnis verbuchen.
AhsayCBS: Wenn der erste Patch nicht reicht
Die beiden AhsayCBS-Lücken funktionieren als Paar. CVE-2026-105133 ist laut KEV-Eintrag eine Authentifizierungsumgehung über die Manipulation des Parameters „random“ in der Funktion checkSysPwd der API-Komponente. CVE-2026-105134 ist eine Befehlsausführung über den Endpunkt /rps/api/json/UpdateReceivers.do der Replication-Receiver-Komponente. Beide lassen sich verketten: erst die Authentifizierung umgehen, dann Betriebssystembefehle ausführen. Praktisch bedeutet das einen Backup-Server, der Fremden erst die Tür öffnet und ihnen dann die Werkzeugkiste reicht.
Nach Angaben von Help Net Security und Huntress legten Angreifer auf diesem Weg Webshells und Cryptominer auf internetexponierten Servern ab. Wer AhsayCBS aus dem Internet erreichbar betreibt, gehört damit zum ersten Prüfkreis.
Heikel ist die Patch-Historie. Laut Help Net Security bestätigte Ahsay am 12. Oktober, dass die früheren Stände v9.15.2.59 und v10.3.4.0 beide Lücken nicht vollständig behoben. Ein bereits eingespielter Patch ist also kein Freibrief. Als Gegenmaßnahme nennt Help Net Security für v10 den Hotfix 10.3.4.45, für v7, v8 und v9 die Version 9.15.2.70. Beide Pakete kommen über das Partnerportal, anschließend ist ein Server-Neustart nötig.
Zwei Einschränkungen gehören dazu: Die Ahsay-Advisory selbst konnte nicht abgerufen werden, die Details stammen aus der Sekundärquelle. Und eine herstellerseitige Bestätigung, dass der Hotfix den Einstiegspunkt schließt, liegt nicht vor; Help Net Security verweist auf Tests von Huntress. Ob Sie nach dem Patch zusätzlich nach Webshells und ungewöhnlicher Rechenlast suchen sollten, ist eine naheliegende eigene Vorsichtsmaßnahme, keine belegte Herstellervorgabe.

