Wenn ein Hersteller am 6. Mai eine Notfall-Mitteilung mit dem Status "Critical, Actively Exploited" veröffentlicht und im selben Atemzug einräumt, dass der erste Patch erst eine Woche später kommt, dann ist das keine Schwachstelle mehr, sondern ein Brandherd. Genau in dieser Lage befinden sich seit Dienstagabend Tausende Unternehmen, deren Perimeter über eine Palo-Alto-Firewall der PA- oder VM-Serie geschützt ist – inklusive vieler Mittelständler in Deutschland. Der Auslöser ist CVE-2026-0300, ein Buffer Overflow im User-ID Authentication Portal, der einen unauthentifizierten Angreifer mit einem einzigen, sorgfältig präparierten Paket auf Port 6081 oder 6082 zu Root macht.

Was die Schwachstelle technisch macht

Das Problem sitzt im Captive-Portal-Daemon, der die User-ID-Authentifizierung gegen Active Directory, LDAP oder einen lokalen Userstore abwickelt. Beim Verarbeiten eingehender HTTP-Requests schreibt das Modul aus einer falsch dimensionierten Pufferberechnung über die Grenze hinaus – CWE-787, klassischer Out-of-bounds Write. Da der Daemon als root läuft und das Captive Portal in vielen Deployments bewusst gegen das Internet oder zumindest gegen unvertraute Zonen exponiert ist (etwa um Gastnutzer authentifizieren zu können), genügen wenige Pakete, um Code im höchsten Privilegienkontext der Box auszuführen.

Palo Alto stuft die Lücke mit einem CVSS-Score von 9.3 ein, sobald das Portal aus dem Internet erreichbar ist – und vermerkt im selben Bulletin den Hinweis, der Sicherheitsverantwortlichen die letzte Tasse Kaffee ungenießbar macht: "Exploitation … is automatable". Das heißt, es braucht keine Handarbeit mehr, der Angriff lässt sich in jede Botnet-Pipeline einbauen. Forschende von Wiz, watchTowr, Rapid7 und SocRadar haben die Lücke bereits in der freien Wildbahn beobachtet, mit ersten Aktivitäten bereits ab dem 4. Mai.

Der unangenehme Patch-Fahrplan

Während die Telemetrie der Sicherheitsforscher anzieht, läuft Palo Alto dem eigenen Release-Zyklus hinterher. Der Hersteller plant zwei Patch-Wellen:

  • 13. Mai 2026 – erste Hotfix-Bündel für die meistgenutzten Trains: PAN-OS 12.1.4-h5, 11.2.7-h2, 11.1.10-h1, 10.2.13-h3.
  • 28. Mai 2026 – konsolidierte Versionen mit neuen Minor-Releases (etwa 12.1.7, 11.2.8, 11.1.11).

Bis dahin gibt es nur Mitigationsmaßnahmen. Wer Threat Prevention mit aktuellem Content nutzt, bekommt seit dem 5. Mai eine Signatur, die typische Angriffsmuster auf Port 6081/6082 erkennt – das ist eine Notbremse, kein Reparaturset. Wer im Internet exponierte Captive Portals betreibt, ohne diese Signatur scharfgeschaltet zu haben, sollte den heutigen Tag nicht beenden, ohne mindestens den Zugang zu beschränken.

Was Sie heute, nicht morgen tun sollten

Die offizielle Empfehlung des Herstellers lautet, das User-ID Authentication Portal entweder auf vertraute Zonen einzuschränken oder, falls fachlich vertretbar, vollständig zu deaktivieren. Konkret:

  1. Prüfen Sie, ob das Portal aus dem Internet erreichbar ist. In der Web-UI: Network → Network Profiles → Interface Mgmt. Auf der Konsole hilft show running ipsec-policy bzw. show config running | match captive-portal. Externe Erreichbarkeit ist der wichtigste Risiko-Multiplikator.
  2. Schalten Sie Threat Prevention scharf. Die Signatur-IDs für CVE-2026-0300 sind in PAN-OS 11.1+ verfügbar; ältere Stränge sollten auf einen Notfall-Wartungspfad gesetzt werden.
  3. Reduzieren Sie die Angriffsfläche. Wer das Portal nur für interne LDAP-Authentifizierung braucht, beschränkt es auf interne Zonen. Wer es für Gast-WLAN nutzt, prüft Captive-Portal-Alternativen wie 802.1X über Aruba ClearPass oder einen separaten Authentifizierungs-Proxy.
  4. Überwachen Sie aktiv. Die Webserver-Logs und der "system log" zeigen ungewöhnliche User-Agents oder fehlgeschlagene Auth-Versuche auf Captive-Portal-URIs. Wer SIEM-seitig mitliest, sollte zumindest für die nächste Woche Anomalien an Port 6081/6082 als Hochpriorität markieren.
  5. Bereiten Sie das Wartungsfenster vor. Ein PAN-OS-Upgrade auf 12.1.4-h5 oder 11.2.7-h2 dauert bei einer HA-Box realistisch 30–60 Minuten – inklusive Commit-Cycle und Sanity-Checks. Der 13. Mai ist ein Mittwoch; ein Wartungsfenster nach 18 Uhr ist meist die ruhigste Wahl, sollte aber bereits jetzt mit dem Change Advisory Board abgestimmt sein.

Detection: Was im SIEM auffallen sollte

Wer einen Splunk- oder Elastic-Stack hinter der Firewall betreibt, kann sich an drei einfachen Erkennungsmustern orientieren. Erstens: ungewöhnliche Request-Größen auf den Captive-Portal-URIs /php/login.php und /api/?type=keygen – die bekannten Exploit-Payloads liegen bei 4 KB und mehr, deutlich über typischen Login-Requests. Zweitens: ein steiler Anstieg von HTTP-500-Antworten auf Port 6081/6082, der auf Crashes des Daemons hindeutet (gescheiterte Exploit-Versuche). Drittens: auth.log-Einträge mit User-Agents, die in keiner gängigen Browser-Bibliothek vorkommen – ein klassisches Signal für Scanner-Aktivität.

# Beispiel: Splunk-Suche fur PAN-OS Captive-Portal-Anomalien
index=panw sourcetype=pan:traffic dest_port IN (6081, 6082)
| stats count by src_ip, http_user_agent, http_status
| where count > 50 OR http_status = 500
| sort -count

Warum dieser Vorfall lehrreich ist

Firewalls sind seit Jahren das attraktivste Ziel für Initial-Access-Broker. Wer eine Firewall kompromittiert, sitzt nicht nur an der Schaltstelle des Datenverkehrs, sondern oft auch an einer Maschine, die alle anderen Sicherheitskontrollen umgehen kann – TLS-Inspektion, IDS, sogar EDR auf Endgeräten verlieren ihre Aussagekraft, wenn der Verteidigungsperimeter selbst kompromittiert ist. CVE-2026-0300 reiht sich in eine Serie ein, die seit 2024 fast jeden großen Hersteller getroffen hat: Cisco, Fortinet, Sonicwall, Ivanti – und nun erneut Palo Alto. Die Lehre ist nicht "Hersteller wechseln", sondern Defense in Depth: Wer seinen Perimeter ausschließlich über die Firewall denkt, ist in dieser Woche unsicher. Wer Mikrosegmentierung, Zero-Trust-Authentifizierung und ein zweites unabhängiges IDS betreibt, hat zumindest Reaktionszeit.

Bezug zu NIS-2 und KRITIS

Wer unter NIS-2 oder das KRITIS-Dachgesetz fällt, muss den Vorfall überdies aus regulatorischer Sicht dokumentieren. Eine ausgenutzte Schwachstelle in einer der zentralen Sicherheitskomponenten ist eine "erhebliche Sicherheitsbedrohung" im Sinne des § 32 NIS2UmsuCG. Der entscheidende Unterschied zum klassischen Patch-Day: Hier muss nicht nur die Lücke geschlossen, sondern auch geprüft werden, ob bereits Kompromittierung erfolgt ist – und das Ergebnis in der Risiko-Dokumentation aktualisiert werden. Die Informationssicherheits-Verantwortlichen sollten den Vorfall in ihrem Incident-Tracker als "Beobachtung" anlegen, auch wenn die eigene Box vermeintlich sauber ist. Wer im Audit nicht zeigen kann, dass er die CISA-KEV-Liste oder die Hersteller-Bulletins systematisch verfolgt, hat ein Compliance-Problem – nicht nur ein technisches.

pleXtec-Empfehlung

Wir empfehlen unseren Kunden, bis zum 13. Mai folgende Routine täglich morgens zu fahren: erstens den Status der Threat-Prevention-Content-Updates verifizieren (mindestens Content 8950 oder neuer), zweitens die Captive-Portal-Konfiguration auf nicht mehr benötigte Internet-Sichtbarkeit prüfen, drittens die HA-Synchronisation bestätigen, sodass das Patch-Fenster am Mittwoch ohne Überraschungen verläuft. Wer Unterstützung bei der Risikoeinschätzung oder bei der Hotfix-Planung benötigt, kann sich über unser Kontaktformular direkt an unser Security-Team wenden.

Eine Schwachstelle dieser Wucht ist selten harmlos abzuschließen. Aber sie ist beherrschbar, wenn man jetzt – und nicht erst nach dem ersten Logfile-Eintrag mit ungewöhnlichem User-Agent – tätig wird.