Palo Alto PAN-OS Zero-Day CVE-2026-0300 von staatlichen Hackern ausgenutzt

Wer schon einmal um 3 Uhr nachts angerufen wurde, weil eine Perimeter-Firewall sich selbst neu gestartet hat, weiß, worauf diese Geschichte hinausläuft. CVE-2026-0300 ist ein CVSS-9.3-Bug für unauthentifizierte Remote Code Execution im PAN-OS Captive Portal – mit Root-Rechten –, und es gibt keinen Patch. Palo Altos eigene Unit 42 bestätigt, dass staatlich unterstützte Akteure die Schwachstelle seit dem 9. April still und leise ausnutzen.

Die Zahlen

Fangen wir mit dem Score an. CVSS 9.3 ist die Art von Wert, der bei Produktionsvorfällen sofort alle anderen Tickets aussticht. Wie The Register berichtete, steckt die Schwachstelle im User-ID Authentication Portal – ein Speicherkorrektionsfehler, der Angreifern Root-Zugriff ohne Login verschafft. Sowohl PA-Series-Appliances als auch VM-Series-Firewalls sind betroffen. Letzteres ist wichtig, weil viele Cloud-lastige Unternehmen fälschlicherweise annehmen, ihre VM-Series-Instanz hinter einem Load Balancer sei sicherer als die physische Box im Rack. Das ist sie nicht.

Die Zeitleiste ist der Teil, der Plattformverantwortliche beunruhigen sollte. Erste fehlgeschlagene Ausnutzungsversuche: 9. April. Erfolgreiche RCE auf einer Ziel-Firewall: etwa eine Woche später, also rund um den 16. April. Bereinigung von Logs und Absturzberichten: sofort. Active-Directory-Erkundung: kurz danach. Erzwungener Failover auf eine sekundäre Firewall durch einen Authentifizierungs-Traffic-Flood: 29. April. Kompromittierung dieses sekundären Geräts und Installation weiterer Remote-Access-Tools: im selben Zeitfenster. Öffentliche Bekanntmachung: 7. Mai. CISA-Eintrag im KEV-Katalog: bereits erfolgt.

Das sind etwa vier Wochen unzugeordneter Root-Zugriff auf internetfähige Sicherheitsinfrastruktur, bevor Verteidiger überhaupt eine CVE hatten, nach der sie suchen konnten. Für Teams, die PAN-OS vor Zahlungssystemen, Sportwetten-Plattformen oder Handelsumgebungen betreiben, ist ein Zeitraum von vier Wochen kein Zeitfenster. Es ist eine Ära. Er umfasst einen vollständigen Monatsabschluss, zwei Gehaltsläufe und mindestens einen Produktlaunch. Das Cluster wird als CL-STA-1132 geführt und als „wahrscheinlich staatlich gesponsert" beschrieben – Herstellersprache für „wir sind sicher genug, es laut zu sagen, aber nicht sicher genug, ein Land zu nennen."

Die technische Signatur: Shellcode, der in einen nginx-Worker-Prozess auf dem Gerät injiziert wird. Unit 42 ordnet die Kampagne zu. CISA hat sie kodifiziert. Palo Altos einzige Mitigationsempfehlung lautet, das User-ID Authentication Portal auf vertrauenswürdige Netzwerke zu beschränken oder vollständig zu deaktivieren. Zum Zeitpunkt der Veröffentlichung gibt es keinen Patch.

Was wirklich neu ist

Ehrlich gesagt nicht viel – und genau das ist der Punkt. Palo-Alto-Firewalls sind seit zwei Jahren ein regelmäßiges Angriffsziel, mit mehreren Zero-Day-Kampagnen gegen internetfähige PAN-OS-Geräte, bevor Patches bereitstanden. Angreifer haben in früheren PAN-OS-Runden Schwachstellen verkettet, um tief in Netzwerke einzudringen. Die Schlagzeile „Perimeter-Gerät wird kompromittiert" ist also keine Neuigkeit. Neu ist die operative Reife von CL-STA-1132.

Betrachten Sie die Choreografie. Fehlgeschlagene Versuche am 9. April legen nahe, dass die Angreifer ihren Exploit gegen Live-Ziele optimiert haben, nicht in einem Labor. Eine Woche später erzielen sie RCE und wischen sofort Logs und Absturzberichte weg. Das zeigt, dass sie ein forensisches Playbook parat hatten, bevor das erste Paket gesendet wurde. Dann erkunden sie Active Directory – der Standardpivot –, während sie gleichzeitig Spuren auf der Firewall verwischen. Parallele Operationen, nicht sequenzielle.

Der Schritt vom 29. April ist der Teil, den ich jedem CTO präsentieren würde, der noch denkt: „Wir haben HA, wir sind sicher." Die Angreifer lösten gezielt einen Flood von Authentifizierungs-Traffic aus, um einen Failover auf die sekundäre Firewall zu erzwingen, kompromittierten auch diese und installierten zusätzliche Remote-Access-Tools darauf. Das ist kein Opportunismus. Das ist ein Operator, der PAN-OS-HA-Semantik versteht, weiß, dass die sekundäre Box oft weniger überwacht wird, und erkannt hat, dass Redundanz für ihn ein Feature ist – nicht für Sie.

Meine Einschätzung: Das wirklich neue Signal ist, dass „hochverfügbare" Perimeter-Paare aus Angreiferperspektive nun eine einzige Fehlerdomäne sind. Wenn Ihr Incident-Response-Runbook davon ausgeht, dass die sekundäre Firewall während einer aktiven Intrusion ein sauberer Fallback ist, ist diese Annahme hinfällig. Beide Knoten sind im Scope, und ein cleverer Angreifer kann Sie auf den umleiten, den er als nächstes kompromittieren will.

Was Security-Teams bereits einkalkuliert haben

Für alle, die PAN-OS betreiben, ist das Auftreten einer weiteren unauthentifizierten RCE in einem Portal-Feature deprimierenderweise bereits eingepreist. Teams, mit denen ich bei iGaming-Betreibern in Malta und bei Fintechs mit Echtgeld-Infrastruktur zusammengearbeitet habe, haben die letzten 18 Monate damit verbracht, Muskelgedächtnis rund um PAN-OS-Notfallmitigationen aufzubauen. Die Reaktionsform: Management-Plane sperren, Portal einschränken, Egress von der Firewall selbst prüfen, nach nginx-Anomalien suchen. Nichts davon ist neu.

Was nicht eingepreist sein sollte – es aber wahrscheinlich ist –, ist das Fehlen eines Patches am Tag der Bekanntmachung. CISAs KEV-Eintrag ohne Herstellerfix bringt CISOs in eine unangenehme Lage. Bundesbehörden haben verbindliche Fristen zur Behebung von KEV-Einträgen, aber die einzige derzeit verfügbare Maßnahme ist das Deaktivieren einer Produktionsfunktion. Das ist ein realer Betriebsaufwand. Wenn Ihr Captive Portal die Authentifizierungsmethode für Auftragnehmer, Gast-WLAN oder BYOD-Nutzer ist, bedeutet „vollständig deaktivieren" ab Montag einen Ansturm auf den Helpdesk.

Die Überraschung für mich ist das AD-Erkundungsdetail. Ordnet man die Angreiferaktionen MITRE ATT&CK zu, erhält man Initial Access via Exploit Public-Facing Application, Defense Evasion via Indicator Removal und Discovery gegen Active Directory – alles von einem Foothold auf der Firewall selbst. Die meisten SOCs kalibrieren ihre AD-Anomalieerkennung so, dass die Quelle ein Endpunkt oder ein Server ist. Sie suchen nicht nach LDAP-Abfragen, die von der Netzwerkposition einer Perimeter-Appliance ausgehen. Dieser blinde Fleck macht Firewall-Kompromittierungen für staatlich unterstützte Gruppen so wertvoll.

Gegenmeinung

Die konsensuelle Reaktion wird lauten: „PAN-OS ist kaputt, reiß es raus und ersetz es." Ich halte das für falsch, teuer und nicht geeignet, das eigentliche Problem zu lösen. Jeder große Firewall-Hersteller hat in den letzten zwei Jahren unauthentifizierte RCEs in Management- oder auth-nahen Features ausgeliefert. Ein Hersteller-Wechsel bringt Ihnen ein anderes CVE-Feed, kein anderes Bedrohungsmodell.

Die unbequeme Wahrheit: Das eigentliche Versagen ist nicht Palo Altos Codequalität, sondern die branchenweite Gewohnheit, reichhaltige Authentifizierungsportale auf internetfähigen Sicherheits-Appliances zu exponieren. Captive Portale, SSL-VPN-Landingpages, Management-Interfaces, die „eigentlich" gesperrt sein sollten, es aber nie ganz sind. Jedes davon ist ein Parser, der in C-nahem Code geschrieben ist, auf der unsicheren Seite des Netzwerks sitzt und nicht vertrauenswürdige Eingaben verarbeitet. Die Angriffsfläche ist die Architektur, nicht der Hersteller.

Wenn Sie versucht sind, in diesem Quartal eine Migration von PAN-OS zu genehmigen, stellen Sie zuerst die schwierigere Frage: Warum ist überhaupt ein Authentifizierungsportal vom öffentlichen Internet aus erreichbar? Cloudflare-ähnliche Identity-Aware-Proxies, ZTNA-Gateways und segmentierte Admin-Planes existieren genau deshalb, um eine Schicht zwischen dem offenen Internet und diesen fragilen Parsern zu platzieren. Das ist die strukturelle Lösung.

Wichtige Erkenntnisse

• Sofort mitigieren, nicht auf den Patch warten: Schränken Sie das User-ID Authentication Portal auf vertrauenswürdige Netzwerke ein oder deaktivieren Sie es. CVE-2026-0300 wird aktiv ausgenutzt und ist im CISA-KEV-Katalog gelistet.
• Beide HA-Knoten sind kompromittiertes Terrain: CL-STA-1132 hat per Auth-Flooding einen Failover erzwungen und auch die sekundäre Firewall kompromittiert. Behandeln Sie Ihr HA-Paar während der IR als eine einzige Vertrauensgrenze.
• Den nginx-Worker untersuchen: Das dokumentierte TTP ist Shellcode-Injektion in nginx auf dem Gerät. Wenn Sie Telemetrie von der Firewall-Ebene haben, suchen Sie nach anomalen Child-Prozessen, ausgehenden Verbindungen und fehlenden Absturzberichten.
• AD-Abfragen von Firewall-Netzwerkpositionen überwachen: Angreifer haben nach dem Foothold Active Directory erkundet. Kalibrieren Sie Erkennungen so, dass LDAP- und Kerberos-Traffic von Perimeter-Appliances keinen Freifahrtschein erhält.
• Am Tag der Bekanntmachung vier Wochen Verweildauer annehmen: Erste Ausnutzungsversuche begannen am 9. April. Wenn Ihre PAN-OS-Box internetfähig ist, umfasst Ihr IR-Scope „seit Anfang April" – nicht „seit dem 7. Mai."