VPN-Gateways unter Beschuss: Exploit-Kampagne gegen Remote Access

Fortinet, Palo Alto, Check Point, SonicWall, Cisco – die Liste der betroffenen Hersteller liest sich wie ein Who’s-Who der Firewall-Branche. Seit Anfang 2026 laufen koordinierte Angriffe auf VPN-Gateways in Unternehmens- und Behördennetzen, und das Muster ist erschreckend simpel: ungepatcht, exponiert, kompromittiert. Ein Überblick über die aktuelle Exploit-Kampagne gegen Remote-Access-Systeme – und was jetzt zu tun ist.

Die Lage: VPN-Gateways als bevorzugtes Einfallstor

Plot Twist: Der Perimeter ist tot, lange lebe der Perimeter. Genau dort, wo Unternehmen glauben, ihre letzte Verteidigungslinie zu haben, setzen Angreifer jetzt an. VPN-Gateways sitzen direkt am Internet, gewähren privilegierten Zugriff auf interne Netze – und werden in vielen Firmen nach dem Prinzip „einmal installiert, nie wieder angefasst“ betrieben. Genau diese Kombination macht sie 2026 zum bevorzugten Ziel koordinierter Angriffswellen.

IBM X-Force warnte Mitte Juni vor breiten Exploit-Kampagnen gegen Fortinet-FortiGate-SSL-VPN und Palo-Alto-PAN-OS-GlobalProtect-Systeme, die offen im Netz erreichbar sind. In einer groß angelegten Credential-Kompromittierung wurden laut IBM zwischen 30.000 und rund 75.000 FortiGate-Firewalls und SSL-VPN-Endpunkte in 194 Ländern als exponiert oder bereits kompromittiert erfasst. Das Risiko dahinter ist keine akademische Übung: Wer einmal im Tunnel steckt, bewegt sich lateral durchs Netz, bis er findet, was er sucht – Ransomware-Payload inklusive.

Das Pikante daran: Viele dieser Lücken sind seit Wochen oder Monaten bekannt. Patches existieren. Die Kampagne nährt sich also nicht aus Zero-Days, sondern aus Trägheit im Patch-Management. Wenig überraschend, dass genau kleine und mittlere Unternehmen mit schmalem Security-Team dabei am härtesten getroffen werden.

Check Point: Wenn IKEv1 zur offenen Tür wird

Der Klassiker unter den aktuellen Schwachstellen trägt die Bezeichnung CVE-2026-50751 und betrifft die Remote-Access-VPN-Komponente von Check Point. Mit einem CVSS-Wert von 9.3 zählt sie zur Kategorie kritisch. Der Fehler liegt in der Zertifikatsvalidierung beim veralteten IKEv1-Schlüsselaustausch: Ein Logikfehler erlaubt Angreifern, eine Remote-Access-VPN-Sitzung ohne gültiges Benutzerpasswort aufzubauen. Kein Passwort nötig, kein Alarm, direkter Zugang – der Clou an dieser Lücke ist ihre Eleganz aus Angreiferperspektive.

Betroffen sind laut Sicherheitsforschern die Versionslinien R80.20.X, R80.40, R81, R81.10, R81.10.X, R81.20, R82, R82.00.X und R82.10. Check Point Research beobachtet aktive Ausnutzung bereits seit Anfang Mai, mit deutlicher Zunahme ab Juni. Die US-Behörde CISA hat die Lücke daraufhin in ihren Katalog bekannter ausgenutzter Schwachstellen aufgenommen und für Bundesbehörden eine kurze Nachfrist zur Behebung gesetzt – ein Signal dafür, wie ernst die Situation eingeschätzt wird. Details zur Schwachstelle und zum verfügbaren Patch hat The Hacker News zusammengetragen.

Die gute Nachricht, so vorhanden: Wer sein Remote-Access-VPN ausschließlich über IKEv2 betreibt, ist von dieser konkreten Lücke nicht betroffen. IKEv1 gilt herstellerseitig ohnehin als veraltet. Wer es noch aktiv nutzt, sollte sich fragen, warum eigentlich – und ob die Antwort „haben wir schon immer so gemacht“ wirklich ausreicht.

Palo Alto GlobalProtect: Ein Cookie zu viel

Nicht weniger brisant ist CVE-2026-0257, eine kritische Authentifizierungs-Bypass-Lücke in PAN-OS und Prisma Access von Palo Alto Networks. Betroffen sind GlobalProtect-Portale und -Gateways. Die Ursache liegt in der Kombination aus aktivierten Authentication-Override-Cookies und einer bestimmten Zertifikatskonfiguration. Wo diese Konstellation vorliegt, können Angreifer VPN-Verbindungen aufbauen, ohne jemals gültige Zugangsdaten zu besitzen.

Sicherheitsforscher von Rapid7 dokumentieren zwei Ausnutzungswellen – eine im Mai, eine kurz darauf – bei denen einzelne Angriffe bis zum vollständigen Netzwerkzugriff führten. Das ist kein reines Informationsleck, das ist der Vorhof zur kompletten Übernahme. Palo Alto empfiehlt als Sofortmaßnahme, Authentication-Override zu deaktivieren oder auf ein dediziertes Zertifikat umzustellen, bis der reguläre Patch eingespielt ist. Die Empfehlung ist konfigurationsabhängig zu verstehen: Nicht jede PAN-OS-Installation ist betroffen, sondern nur jene mit der spezifischen Cookie-Zertifikat-Kombination. Wer diese Konfiguration nicht kennt, sollte sie schleunigst nachschauen, statt sich in falscher Sicherheit zu wiegen.

FortiGate, FortiBleed und die Masche der Massenscans

Bei Fortinet läuft parallel eine andere Baustelle. Seit Mitte Januar beobachten Sicherheitsteams automatisierte Angriffe, die den SSO-Authentifizierungspfad von FortiGate-Geräten missbrauchen, um Konfigurationsänderungen ohne ordnungsgemäße Authentifizierung vorzunehmen. Parallel dazu läuft unter dem Namen „FortiBleed“ eine weltweit koordinierte Kampagne gegen schlecht gepatchte und schwach abgesicherte FortiGate-Firewalls und SSL-VPN-Gateways – keine einzelne CVE, sondern ein ganzes Bündel bekannter, teils bereits gepatchter Schwachstellen, die dort besonders effektiv wirken, wo Updates ausgeblieben sind.

Auch SonicWall steht im Fadenkreuz: Sicherheitsforscher registrierten einen Massenangriff, bei dem rund 4.300 IP-Adressen gezielt nach verwundbaren SonicWall-VPN-Gateways scannen. Das Muster ist immer dasselbe – erst der breite Scan, dann der gezielte Zugriff auf das, was offen steht. Eine Einordnung der Kampagne liefert All About Security.

Bei Cisco und Palo Alto wiederum setzen Angreifer laut GreyNoise-Analysten zusätzlich auf simples Credential-Stuffing gegen Enterprise-VPN-Authentifizierungssysteme – keine ausgeklügelte Lücke, sondern schlicht durchprobierte Passwörter, konzentriert in einer intensiven Angriffsphase über wenige Tage. Der Clou daran: Es braucht gar keine CVE, wenn das Passwort ohnehin „Firma2024!“ lautet.

Wie ein solcher Angriff typischerweise abläuft

Um die Dringlichkeit greifbarer zu machen, lohnt ein Blick auf den typischen Ablauf einer solchen Kampagne – bewusst allgemein formuliert, denn die genaue Vorgehensweise variiert je nach Ziel und Werkzeug. In der ersten Phase scannen automatisierte Bots ganze IP-Bereiche nach offen erreichbaren VPN-Portalen ab und gleichen die dabei sichtbaren Versionsnummern und Bannerdaten mit bekannten Schwachstellen ab. Diese Phase braucht kaum menschliches Eingreifen, sie läuft im Hintergrund, rund um die Uhr, gegen Tausende Ziele gleichzeitig.

Findet sich ein verwundbares System, folgt Phase zwei: die eigentliche Ausnutzung der Lücke, sei es über einen Authentifizierungs-Bypass wie bei Check Point und Palo Alto oder über kompromittierte Zugangsdaten. Sobald der Zugang steht, verschaffen sich Angreifer in Phase drei zunächst einen Überblick über das interne Netz, legen häufig zusätzliche Zugänge oder Hintertüren an, um auch nach einem Passwortwechsel wieder hineinzukommen, und bewegen sich lateral zu Systemen mit höherem Wert – Domänencontroller, Backup-Server, Datenbanken. Erst am Ende dieser Kette steht häufig das, was in den Schlagzeilen landet: Datenabfluss, Verschlüsselung durch Ransomware oder beides.

Der entscheidende Punkt für Verteidiger: Je früher eine dieser Phasen unterbrochen wird, desto geringer der Schaden. Ein gepatchtes Gateway verhindert bereits Phase zwei. Eine aktivierte Mehr-Faktor-Authentifizierung erschwert selbst dann noch den Zugang, wenn Zugangsdaten längst im Umlauf sind. Und ein aufmerksames Monitoring kann zumindest die laterale Bewegung in Phase drei entdecken, bevor der eigentliche Schaden entsteht.

Warum ausgerechnet KMU und Behörden so verwundbar sind

Große Konzerne haben Security Operations Center, Patch-Zyklen und notfalls ein Incident-Response-Team im Schlepptau. Kleine und mittlere Unternehmen haben oft einen IT-Verantwortlichen, der nebenbei auch noch den Drucker reparieren muss. Genau diese Lücke zwischen Anspruch und Ressourcen macht Remote-Access-Systeme in KMU zum Lieblingsziel automatisierter Scans.

Meine persönliche Einschätzung: Die Debatte um „Zero Trust“ und moderne Zugriffsarchitekturen wird seit Jahren geführt, während die Realität in vielen Betrieben noch bei „VPN rein, Passwort merken, fertig“ steht. Das ist bequem – bis es das nicht mehr ist. Wer glaubt, eine einmal eingerichtete Firewall brauche keine Pflege mehr, betreibt digitale Vogel-Strauß-Politik.

Behörden trifft es aus einem ähnlichen Grund besonders hart: begrenzte Budgets, lange Beschaffungszyklen, oft historisch gewachsene Netzwerkstrukturen mit Systemen, die niemand mehr vollständig überblickt. Wenn dann noch ein zentrales VPN-Gateway kompromittiert wird, öffnet sich der Zugang zu Bürgerdaten, internen Verwaltungssystemen und mitunter kritischer Infrastruktur in einem Schritt.

Ein illustratives, bewusst verallgemeinertes Szenario macht das Problem greifbar: Ein mittelständischer Zulieferbetrieb betreibt seit Jahren dieselbe Firewall-Appliance, die einmal von einem externen Dienstleister eingerichtet wurde. Firmware-Updates laufen nicht automatisch, niemand im Betrieb fühlt sich dafür zuständig, und ein Wartungsvertrag wurde nie verlängert. Genau solche Konstellationen – nicht die spektakulären Zero-Day-Lücken – sind es, die automatisierte Scans in der Praxis am zuverlässigsten finden. Es braucht keinen gezielten Angriff auf ein bestimmtes Unternehmen, es reicht, zur falschen Zeit am falschen, offenen Port zu stehen.

Regulatorischer Druck: NIS2 und die Meldepflicht

Die aktuelle Kampagne trifft auf ein regulatorisches Umfeld, das sich gerade deutlich verschärft. Mit der NIS2-Richtlinie rückt die EU-Cybersicherheitsgesetzgebung erstmals auch viele mittelständische Unternehmen und Betreiber wichtiger Dienste in den Anwendungsbereich, die zuvor kaum von expliziten Sicherheitspflichten betroffen waren. Wer unter diese Regelungen fällt, muss sich künftig stärker mit Risikomanagement, Meldepflichten bei Sicherheitsvorfällen und einem nachvollziehbaren Umgang mit Schwachstellen auseinandersetzen, als das in vielen Betrieben bisher der Fall war.

Für die Praxis bedeutet das: Ein ungepatchtes VPN-Gateway ist längst nicht mehr nur ein technisches Risiko, sondern zunehmend auch ein Compliance-Thema. Wer im Ernstfall nachweisen muss, welche Schritte zur Absicherung der Remote-Access-Infrastruktur unternommen wurden, sollte diesen Nachweis nicht erst dann vorbereiten, wenn die Aufsichtsbehörde nachfragt. Ein dokumentiertes Patch-Management, klar zugewiesene Verantwortlichkeiten und nachvollziehbare Reaktionszeiten auf bekannt gewordene Schwachstellen werden damit vom Nice-to-have zur Grundvoraussetzung.

Sofortmaßnahmen: Was jetzt konkret zu tun ist

Erste Priorität: Inventur. Wer nicht weiß, welche VPN-Gateways, Firewalls und Remote-Access-Systeme im eigenen Netz überhaupt exponiert sind, kann sie auch nicht absichern. Das klingt banal, ist aber laut den aktuellen Berichten genau der Punkt, an dem viele Organisationen scheitern.

• Patches umgehend einspielen – speziell für Check Point Remote Access VPN, Palo Alto PAN-OS/GlobalProtect und Fortinet FortiGate SSL-VPN.
• Bei Check Point-Systemen prüfen, ob IKEv1 noch aktiv ist, und wenn möglich auf IKEv2-only umstellen.
• Bei Palo Alto-Installationen Authentication-Override-Cookies deaktivieren oder auf ein dediziertes Zertifikat umstellen, bis der Patch sitzt.
• Multi-Faktor-Authentifizierung für sämtliche Remote-Access-Zugänge erzwingen, um Credential-Stuffing wirkungslos zu machen.
• Logs auf ungewöhnliche Sessions, neu angelegte Accounts und untypische Konfigurationsänderungen prüfen.
• Externe Erreichbarkeit der Management-Oberflächen von Gateways grundsätzlich prüfen und, wo nicht zwingend nötig, deaktivieren.
• Verantwortlichkeiten für Patch-Management schriftlich festlegen, statt sie stillschweigend „irgendjemandem in der IT“ zuzuschreiben.

Die IBM X-Force Advisory beschreibt das Risikoprofil dieser Front-Door-Assets sehr anschaulich: Wer FortiGate SSL-VPN oder PAN-OS GlobalProtect internetseitig exponiert betreibt, sollte die Warnung als direkt relevant behandeln, nicht als generische Sicherheitshinweis-Floskel. Wer mehr über die technischen Details der aktuellen Kompromittierungswelle nachlesen möchte, findet sie im Advisory von IBM X-Force.

Gegenargumente: Ist sofortiges Patchen wirklich immer die richtige Antwort?

So klar die Handlungsempfehlung „patcht sofort“ auf dem Papier klingt, so kompliziert ist sie in der betrieblichen Realität oft umzusetzen. VPN-Gateways sind selten isolierte Systeme – sie sind mit Routing-Regeln, Zertifikatsketten, Monitoring-Werkzeugen und mitunter auch mit Compliance-Vorgaben verzahnt. Ein unbedacht eingespieltes Update kann im schlechtesten Fall selbst zu Ausfällen führen, etwa wenn ältere Client-Software plötzlich nicht mehr mit einer neuen Firmware-Version kompatibel ist. Gerade in Betrieben mit Schichtbetrieb oder kritischen Produktionsprozessen ist ein ungeplantes Wartungsfenster keine triviale Entscheidung.

Diese Einwände sind berechtigt – sie dürfen aber nicht zur Ausrede werden, ein Update grundsätzlich auf die lange Bank zu schieben. Der übliche Mittelweg ist ein gestuftes Vorgehen: kritische, aktiv ausgenutzte Lücken wie die hier beschriebenen erhalten Vorrang vor regulären Update-Zyklen, notfalls mit einem kurzen, angekündigten Wartungsfenster außerhalb der Kernarbeitszeit. Wo ein sofortiges Patchen tatsächlich nicht möglich ist, sollten zumindest die von den Herstellern genannten Übergangsmaßnahmen – etwa das Deaktivieren einzelner Funktionen oder die Einschränkung der Erreichbarkeit auf bestimmte IP-Bereiche – als Zwischenlösung dienen, bis der reguläre Patch eingespielt werden kann. Ein VPN-Gateway drei Monate lang unverändert offen zu lassen, weil „gerade keine Zeit“ war, ist dagegen keine Risikoabwägung, sondern schlicht ein unkalkuliertes Risiko.

Logs, Monitoring und die unterschätzte Rolle von SSO

Ein Aspekt, der in der öffentlichen Debatte oft zu kurz kommt: Angreifer nutzen zunehmend nicht die klassische Buffer-Overflow-Lücke, sondern Logikfehler in Authentifizierungsabläufen. Das bedeutet, klassische Signatur-basierte Erkennung greift oft zu spät oder gar nicht. Wer nur nach bekannten Exploit-Mustern sucht, übersieht eine Session, die formal völlig legitim aussieht – weil der Angreifer sich eben nicht „eingehackt“, sondern schlicht am Authentifizierungsprozess vorbeigeschummelt hat.

Bei FortiGate zeigt sich das exemplarisch am SSO-Pfad: Wird die Single-Sign-On-Integration eines Gateways fehlkonfiguriert oder unzureichend überwacht, entsteht ein Einfallstor für Rechteausweitung direkt am Perimeter. Wer Identity-Integrationen an Gateways einrichtet, sollte diese also mit derselben Sorgfalt testen und überwachen wie jede andere kritische Zugriffskontrolle im Unternehmen – nicht als Komfortfunktion nebenbei.

Für Administratoren bedeutet das in der Praxis: Regelmäßige Prüfung der Authentifizierungs- und Konfigurationslogs ist kein Nice-to-have mehr, sondern Pflichtprogramm. Wer SSH-Zugänge, Remote-Desktop-Verbindungen oder VPN-Sitzungen betreibt, sollte Alarmierungen so einstellen, dass ungewöhnliche Login-Muster – etwa Sitzungen ohne vorherige erfolgreiche Passwortprüfung – sofort auffallen.

Architektur-Frage: Bleibt klassisches VPN noch zeitgemäß?

Ist das klassische Remote-Access-VPN also generell unsicher? Nein, so einfach ist es nicht. SSL-VPN-Lösungen sind nicht per se ein Sicherheitsrisiko, aber sie stehen historisch stark im Fokus von Angreifern – vor allem, wenn sie ungepatcht bleiben. Viele Security-Teams sehen in Zero-Trust-Network-Access-Modellen und Software-Defined-Perimeter-Architekturen langfristig die robustere Lösung, weil sie granularere Zugriffsrechte statt eines einmal geöffneten Tunnels erzwingen.

Trotzdem: Ein Umstieg auf ZTNA ersetzt nicht die Notwendigkeit, bestehende VPN-Gateways sauber zu patchen und zu konfigurieren. Wer heute noch klassisches VPN betreibt – und das sind nach wie vor die meisten Unternehmen – kommt am Patch-Management nicht vorbei, egal wie die Architektur der Zukunft aussehen mag. Die aktuelle Kampagne zeigt vor allem eines: Regulatorischer Druck über Kataloge bekannter ausgenutzter Schwachstellen wächst, und Behörden erzwingen zunehmend, dass Gateway-Sicherheit nicht länger Nebensache bleibt.

Meine zweite persönliche Einschätzung dazu: Die Diskussion „VPN vs. ZTNA“ wird oft wie eine Glaubensfrage geführt, dabei ist sie viel banaler. Beide Ansätze scheitern an derselben Stelle – mangelnder Pflege. Eine brillante Zero-Trust-Architektur mit ungepatchten Komponenten ist genauso verwundbar wie ein altes VPN-Gateway ohne Updates.

Was bleibt?

Die aktuelle Exploit-Kampagne gegen VPN-Gateways ist kein einmaliger Ausreißer, sondern Symptom eines strukturellen Problems: Systeme, die als selbstverständlich und wartungsfrei behandelt werden, obwohl sie den kompletten Zugang zum Unternehmensnetz kontrollieren. Wer sein Remote-Access-System seit Monaten nicht angefasst hat, sollte sich ehrlich fragen, wie viel Vertrauen dieses Vertrauen eigentlich noch verdient. Die Patches liegen bereit. Die Frage ist nur, wer sie zuerst einspielt – Sie oder der nächste Scan aus einem der Tausenden Angreifer-IPs.