PAN-OS Sicherheitslücke CVE-2026-0300: CVSS 9,8 Zero-Day aktiv ausgenutzt

Eine Zero-Day-Lücke mit CVSS 9,8, kein Patch nötig zum Angriff, Root-Rechte auf Enterprise-Firewalls – und Exploits laufen bereits. CVE-2026-0300 in PAN-OS trifft Unternehmen genau dort, wo sie sich am sichersten fühlen: an der Netzwerk-Grenze.

Der Exploit kommt durch die Haustür – und die stand offen

Plot Twist: Die Sicherheitslücke sitzt diesmal nicht im internen System, nicht in einer schlecht gepflegten Web-App, nicht im Homeoffice-Laptop eines Mitarbeitenden. Sie sitzt in der Firewall selbst. Palo Alto Networks warnte im Mai 2026 vor CVE-2026-0300, einer kritischen Schwachstelle in PAN-OS, dem Betriebssystem der PA-Series- und VM-Series-Firewalls des Herstellers. CVSS 9,8 nach Version 3.1. Neun Komma Acht. Die Lücke ermöglicht Remote Code Execution mit Root-Rechten – unauthentifiziert, ohne jede Nutzerinteraktion, ausgelöst durch ein einziges präpariertes Netzwerkpaket.

Das Pikante daran: Betroffen ist ausgerechnet das User-ID Authentication Portal, auch Captive Portal genannt. Also genau die Komponente, die Benutzer identifizieren und kontrollieren soll. Sie wird zur Eingangstür für Angreifer. Wer hätte das gedacht – außer jedem, der schon mal Angriffsszenarien gegen Perimeter-Systeme durchgespielt hat.

Die Lücke basiert auf einem Buffer Overflow, technisch klassifiziert als Out-of-Bounds Write (CWE-787) im Authentifizierungsportal-Dienst. Angreifer schicken gezielt manipulierte Pakete, der Dienst schreibt über Speichergrenzen hinaus, die Kontrolle über das System wechselt den Besitzer. Schnell, sauber, vollständig.

CVSS 9,8 und EPSS über dem 95. Perzentil – was die Zahlen bedeuten

Zwei Kennzahlen dominieren die Risikoeinschätzung zu CVE-2026-0300. Erstens: Greenbone ordnet die PAN-OS Sicherheitslücke in seinem Threat Report Mai 2026 mit einem CVSS-v3.1-Score von 9,8 und einem EPSS-Wert im 95. Perzentil oder darüber ein. EPSS misst die Wahrscheinlichkeit aktiver Ausnutzung in den nächsten 30 Tagen – ein Wert im 95. Perzentil bedeutet: Diese Lücke gehört zu den am häufigsten und am wahrscheinlichsten angegriffenen überhaupt. Zweitens: Borncity gibt ergänzend einen CVSS-v4.0-Score von 9,3 an. Beide Versionen, beide kritisch. Wer jetzt noch abwartet, spielt russisches Roulette mit Unternehmensdaten.

Wenig überraschend: CVE-2026-0300 steht auf der CISA Known Exploited Vulnerabilities List, kurz KEV. Diese Liste führt ausschließlich Schwachstellen, die nachweislich aktiv missbraucht werden. Kein Theoriekonstrukt. Kein Proof-of-Concept im Labor. Aktive Angriffe in freier Wildbahn. Wer in einer US-Bundesbehörde arbeitet, hat durch die KEV-Aufnahme ohnehin eine Patch-Pflicht. Für alle anderen ist es ein unmissverständliches Signal.

Meiner Einschätzung nach ist die Kombination aus Pre-Auth-Angriff, Root-RCE und aktiver Ausnutzung einer der gefährlichsten Konfigurationen, die ein CVSS-Score abbilden kann. 9,8 klingt abstrakt. Was es bedeutet: Ein Angreifer mit Netzwerkzugang zum Portal übernimmt die Firewall vollständig – ohne Login, ohne Social Engineering, ohne Wartezeit.

Wer ist konkret betroffen? Versionen und Bedingungen

Nicht jede PAN-OS-Installation ist automatisch angreifbar. Zwei Bedingungen müssen zusammentreffen: Erstens muss das User-ID Authentication Portal (Captive Portal) aktiviert sein. Zweitens muss dieses Portal aus dem Internet oder anderen nicht vertrauenswürdigen Netzwerken erreichbar sein. Wer beides hat, hat ein Problem.

Betroffene PAN-OS-Versionen laut Borncity-Analyse: Im Branch 11.1 sind alle Versionen vor den Fixes 11.1.4-h33, 11.1.6-h32, 11.1.7-h6, 11.1.10-h25, 11.1.13-h5 sowie alle vor 11.1.15 verwundbar. Im Branch 11.2 sind Versionen unterhalb von 11.2.4-h17, 11.2.7-h13, 11.2.10-h6 und 11.2.12 betroffen. Branch 12.1 ist anfällig unterhalb von 12.1.4-h5 und 12.1.7. Erste Patches sollen laut Borncity gestaffelt zwischen dem 13. und 28. Mai 2026 erschienen sein, je nach PAN-OS-Branch.

Wichtig: Wer eine PAN-OS-Firewall betreibt, ohne das Captive Portal je aktiviert zu haben, ist über diesen spezifischen Angriffspfad nicht direkt exponiert. Das bedeutet nicht, dass keine anderen Schwachstellen existieren – dazu gleich mehr. Aber CVE-2026-0300 trifft gezielt Systeme, bei denen User-ID-Funktionen öffentlich erreichbar sind. In vielen Enterprise-Umgebungen ist genau das der Standardzustand, weil das Portal schlicht aktiviert und nie explizit eingeschränkt wurde.

Sofortmaßnahmen: Was jetzt zu tun ist

Schritt eins ist klar: Patch einspielen. Wer die gefixten Builds von Palo Alto noch nicht eingespielt hat, sollte das sofort nachholen und vorher die aktuellen Security Advisories direkt beim Hersteller prüfen – die Versionsstände ändern sich laufend. Schritt zwei gilt für alle, die nicht sofort patchen können oder wollen: Zugriff auf das Authentication Portal sofort auf interne, vertrauenswürdige IP-Bereiche beschränken. Kein Internetzugang zum Portal, kein direkter Exploit-Pfad.

Schritt drei ist radikal, aber wirksam: Das Portal komplett deaktivieren, wenn es funktional nicht zwingend gebraucht wird. In der PAN-OS-GUI findet man die Einstellungen unter Device > User Identification > Authentication Portal Settings. Wer nicht weiß, ob das Portal aktiv ist, sollte jetzt nachschauen – nicht morgen.

Der Clou, den viele übersehen: Deaktivierung oder Einschränkung des Portals ist eine Mitigation, kein Fix. Wer nur die Zugangsbeschränkung anpasst und nie patcht, riskiert, dass eine spätere Konfigurationsänderung das Portal wieder exponiert. Nur der Patch schließt die Lücke dauerhaft. SOC Prime analysiert CVE-2026-0300 ausführlich und empfiehlt ebenfalls die sofortige Kombination aus Portalhärtung und Versionswechsel.

Für Netzwerk-Sicherheitsteams, die Threat-Hunting-Regeln aufsetzen wollen: Verdächtige Verbindungsmuster zum Authentication Portal, ungewöhnliche Prozesse auf der Firewall und Root-Level-Aktivitäten auf PAN-OS-Systemen sollten sofort in Detektionsregeln einfließen. Wenn der Exploit bereits gelaufen ist, bemerkt man das oft erst, wenn die Firewall beginnt, unerwarteten Traffic weiterzuleiten oder externe Command-and-Control-Kommunikation aufbaut.

PAN-OS als Dauerbaustelle: CVE-2026-0300 ist nicht allein

Brisant: CVE-2026-0300 ist keine Einzelerscheinung. Innerhalb kurzer Zeit häufen sich kritische Befunde in PAN-OS. CVE-2026-0257 betrifft das GlobalProtect Portal und Gateway – dort ermöglicht ein Authentication Bypass unautorisierten VPN-Zugang, CVSS 7,8, ebenfalls aktiv ausgenutzt. CVE-2026-0227 ist eine DoS-Schwachstelle gegen GlobalProtect mit einem CVSS-v4.0-Score von 7,7, veröffentlicht im Januar 2026.

Diese drei CVEs betreffen jeweils unterschiedliche Komponenten: CVE-2026-0300 trifft das User-ID Authentication Portal, CVE-2026-0257 den GlobalProtect-Stack, CVE-2026-0227 ebenfalls GlobalProtect, aber als Denial-of-Service-Variante. Wer sie verwechselt oder vermischt, bekommt Patching und Mitigation falsch. Klare Trennung ist hier keine Pedanterie, sondern operative Notwendigkeit.

Das Muster dahinter ist eindeutig: Authentifizierungs- und Remote-Access-Funktionen an der Netzwerk-Perimeter werden zum bevorzugten Angriffsziel. Diese Dienste sitzen exakt an der Grenze zwischen Internet und internem Netz, sind oft öffentlich erreichbar und müssen komplex sein – eine toxische Kombination für Schwachstellen. Das gilt nicht nur für Palo Alto. Ähnliche Sicherheitslücken in Netzwerk-Sicherheitsprodukten anderer Hersteller haben in den vergangenen Jahren immer wieder für Schlagzeilen gesorgt, und auch der Bereich Webanwendungs-Infrastruktur bleibt ein dauerhafter Risikofaktor, wie etwa die kritische cPanel-Schwachstelle aus dem gleichen Zeitraum zeigt.

Was eine kompromittierte Perimeter-Firewall für das interne Netz bedeutet

Wer die tatsächliche Tragweite von CVE-2026-0300 verstehen will, muss sich vor Augen führen, welche Position eine Perimeter-Firewall im Unternehmensnetzwerk einnimmt. Sie ist nicht irgendein System am Rand. Sie ist das Herzstück der Netzwerksegmentierung, die zentrale Kontrollinstanz für eingehenden und ausgehenden Traffic und in vielen Architekturen gleichzeitig VPN-Endpunkt, DNS-Resolver und Logging-Aggregator.

Wenn ein Angreifer Root-Rechte auf dieser Firewall erlangt, verliert das schützende Perimeter-Konzept augenblicklich seine Grundlage. Ein kompromittiertes PAN-OS-System kann Traffic still umleiten, ohne dass interne Systeme etwas bemerken. Firewall-Regeln lassen sich modifizieren, um Backdoor-Verbindungen dauerhaft zu erlauben. VPN-Zertifikate und Schlüsselmaterial können extrahiert werden. Logs können manipuliert oder vollständig unterdrückt werden – was forensische Untersuchungen erheblich erschwert.

In einem typischen Enterprise-Szenario bedeutet das: Nach einer erfolgreichen Ausnutzung von CVE-2026-0300 hat ein Angreifer nicht nur Zugang zur Firewall selbst, sondern faktisch eine privilegierte Beobachterposition gegenüber dem gesamten internen Netzwerk. Lateral Movement, also das seitliche Ausbreiten im Netzwerk, wird ab diesem Punkt erheblich einfacher. Endpoint-Sicherheitslösungen auf internen Systemen schützen nicht vor einem Angreifer, der den Netzwerkfluss kontrolliert.

Für Incident-Response-Teams bedeutet das konkret: Wenn ein Verdacht auf Kompromittierung besteht, reicht es nicht, nur das Portal abzuschalten und den Patch einzuspielen. Das gesamte System muss als potenziell kompromittiert behandelt werden. Das umfasst die Überprüfung aller gespeicherten Credentials und Zertifikate, eine vollständige Audit-Auswertung rückwirkend bis zum frühestmöglichen Infektionszeitpunkt sowie im Zweifel die Neuinstallation aus einem verifizierten sauberen Image.

Warum Security-Funktionen selbst zur Angriffsfläche werden

Hier liegt das eigentliche strukturelle Problem, das mich bei diesem Fall besonders beschäftigt: Das User-ID Authentication Portal existiert, um Sicherheit zu schaffen. Es identifiziert Nutzer, kontrolliert Zugänge, schreibt Logs. Genau dieses System wird zur Einfallschneise. Cyberangriffe auf Authentifizierungssysteme folgen damit einem Muster, das in der Branche seit Jahren bekannt ist – je kritischer eine Funktion, desto attraktiver als Ziel.

Die Konsequenz, die SOC Prime und Greenbone aus solchen Szenarien ziehen, ist keine überraschende, aber sie wird noch immer zu selten umgesetzt: Minimale Exposition an der Perimeter-Firewall. Kein Feature aktivieren, das nicht zwingend gebraucht wird. Portale, Gateways und Authentifizierungsdienste nur intern oder hinter einem weiteren Kontrollpunkt betreiben. Der Ansatz „möglichst viele Security-Funktionen an der Firewall aktivieren“ erzeugt Angriffsfläche, keine Sicherheit. Automatisierte Vulnerability-Management-Prozesse helfen dabei, solche Expositionen überhaupt erst sichtbar zu machen – gerade in größeren Enterprise-Umgebungen, wo niemand mehr händisch den Überblick über alle aktivierten Dienste hat.

Freie Firewall-Alternativen wie IPFire oder OPNsense sind zwar für viele Enterprise-Umgebungen kein direkter Ersatz, aber ihr Minimalismus in Sachen aktivierter Dienste ist architektonisch lehrreich: Was nicht läuft, kann nicht exploitet werden.

Was CISA-KEV-Listung für Unternehmen bedeutet

Die Aufnahme in die CISA Known Exploited Vulnerabilities List ist mehr als eine behördliche Fußnote. Für US-Bundesbehörden ist sie eine bindende Patch-Pflicht mit Frist. Für private Unternehmen und europäische Organisationen ist sie ein belastbares Indiz für aktive Angriffe – eines, das in Risikobewertungen und gegenüber der Geschäftsleitung unmittelbar verwertbar ist.

In Europa gibt NIS2 den regulatorischen Rahmen: Betreiber kritischer Infrastrukturen und wichtiger Einrichtungen sind verpflichtet, erhebliche Sicherheitsvorfälle zu melden und angemessene technische Maßnahmen zu ergreifen. Eine bekannte, aktiv ausgenutzte Zero-Day-Lücke mit CVSS 9,8 auf einer exponierten Firewall dürfte in den meisten Sicherheitsbewertungen als angemessener Patchanlass gelten – juristisch formuliert.

Borncity dokumentiert die Patch-Timeline und betroffene PAN-OS-Versionsstände zu CVE-2026-0300 detailliert und ist eine der ersten deutschsprachigen Quellen, die konkrete Build-Nummern benennt. Wer seinen Patch-Status prüfen will, findet dort eine verlässliche Orientierung – aber das letzte Wort haben immer die offiziellen Security Advisories von Palo Alto Networks selbst, da weitere Maintenance-Releases jederzeit folgen können.

Checkliste: Bin ich betroffen?

• Firewall-Typ prüfen: Läuft eine PA-Series oder VM-Series Firewall mit PAN-OS 11.1, 11.2 oder 12.1?
• Captive Portal prüfen: Ist das User-ID Authentication Portal unter Device > User Identification > Authentication Portal Settings aktiviert?
• Erreichbarkeit prüfen: Ist das Portal aus dem Internet oder nicht vertrauenswürdigen Netzwerken erreichbar?
• Versionsstatus prüfen: Liegt die installierte PAN-OS-Version unterhalb der gepatchten Builds (z. B. 11.1.15, 11.2.12, 12.1.7 oder spezifischer Hotfix-Builds)?
• Sofortmaßnahme: Portal auf interne IPs beschränken oder deaktivieren, sofern kein zwingender Bedarf besteht.
• Patch einspielen: Gefixten Build einspielen und aktuelle Advisories bei Palo Alto Networks vor dem Update gegenprüfen.
• Logs prüfen: Verdächtige Aktivitäten rund um das Authentication Portal und Root-Level-Prozesse auf PAN-OS-Systemen untersuchen.
• Kompromittierungsprüfung: Bei konkretem Verdacht auf erfolgreichen Exploit das System als kompromittiert behandeln, Credentials und Zertifikate rotieren, Neuinstallation aus sauberem Image erwägen.

Was bleibt, wenn die Lücke gepatcht ist?

Der Patch kommt – und dann? PAN-OS Sicherheitslücken wie CVE-2026-0300 zeigen, dass selbst Enterprise-Grade-Netzwerk-Sicherheitsprodukte keine inhärente Immunität besitzen. Der Zero-Day von heute ist das Advisory von morgen. Netzwerk-Sicherheit als statischer Zustand existiert nicht. Was bleibt, ist die Frage, ob Unternehmen bereit sind, ihre Patch-Prozesse so aufzustellen, dass ein CVSS-9,8-Zero-Day nicht wochenlang unbemerkt in produktiven Firewalls schlummert – oder ob die nächste Warnung wieder zu spät kommt.

Langfristig erfordert das einen Kulturwandel im Umgang mit Netzwerk-Infrastruktur. Firewalls und andere Perimeter-Systeme dürfen nicht als „set and forget“-Komponenten behandelt werden. Regelmäßige Überprüfung aktivierter Dienste, kontinuierliches Vulnerability-Scanning auch der eigenen Sicherheitsinfrastruktur und klar definierte Eskalationspfade für kritische CVEs sind keine optionalen Best Practices, sondern operative Grundvoraussetzungen. CVE-2026-0300 ist eine Erinnerung daran – eine, die für manche Unternehmen leider erst nach einem erfolgreichen Angriff ankommen wird.