Check Point schließt zwei VPN-Lücken der Schwere 9,8, die nicht authentifizierte Codeausführung erlauben

Check Point hat am 9. September Notfallupdates für zwei kritische Schwachstellen in der Zertifikatsverarbeitung seiner VPN-Produkte veröffentlicht, Fehler, die einem nicht authentifizierten Angreifer erlauben würden, Code auf einer Firewall oder einem Management-Server am Rand eines Unternehmensnetzes auszuführen.

Zum Weiterlesen: WordPress stopft Comment2Shell, eine Kommentar-Lücke, die zur Server-Übernahme führen kann · Oracle liefert 673 Sicherheitspatches aus, darunter sechs Schwachstellen mit Höchstschweregrad.

Beide Fehler tragen einen CVSS-Wert von 9,8, der höchsten Schwerestufe, und beide lassen sich remote ohne Anmeldedaten auslösen. Der erste, geführt als CVE-2026-85102, ist eine unsachgemäße Validierung von Zertifikatsdaten während der VPN-Aushandlung. Der zweite, CVE-2026-85103, ist ein Heap-basierter Pufferüberlauf bei der ASN.1-Dekodierung von VPN-Zertifikaten. Check Point veröffentlichte die Advisories sk1000117 und sk1000118, und das CERT-EU der Europäischen Union gab eine eigene Warnung heraus.

Betroffen sind Check Point Security Gateway, Security Management Server und Spark Firewall in den Release-Zweigen R81.20, R82 und R82.10, die für Remote-Access-VPN oder Site-to-Site-VPN konfiguriert sind. Der neuere Zweig R82.20 ist laut Check Point nicht betroffen. Da diese Appliances die Firewall-Richtlinie verwalten und VPN-Tunnel terminieren, legt eine erfolgreiche Kompromittierung nicht nur ein Gerät offen: Sie kann einem Angreifer einen Standfuß am Netzwerkrand verschaffen und einen Weg zu internen Systemen und der Management-Konsole, die jedes Gateway im Bestand steuert.

Warum die Zertifikatsverarbeitung die Schwachstelle ist

Beide Fehler sitzen in dem Teil des VPN-Handshakes, der abläuft, bevor die Identität eines Nutzers geprüft wird. Um einen Tunnel aufzubauen, muss das Gateway ein von der Gegenseite vorgelegtes Zertifikat parsen und validieren. Diese Verarbeitung erfolgt früh und auf einem erreichbaren Netzwerkport, genau die Kombination, nach der Angreifer bei einer aus dem Internet erreichbaren Appliance suchen.

Bei CVE-2026-85102 gelingt es dem Gateway nicht, die Vertrauenswürdigkeit eines vorgelegten Zertifikats ordnungsgemäß festzustellen, sodass ein nicht authentifizierter Angreifer die Aushandlung weit genug vorantreiben kann, um Code auszuführen. Bei CVE-2026-85103 beschädigt ein speziell gefertigtes Zertifikat den Heap-Speicher im ASN.1-Decoder und verschafft dem Angreifer die Kontrolle über die Ausführung sowohl auf Security Gateways als auch auf Security Management Servern. Armis, das den zweiten Fehler verfolgt, weist darauf hin, dass die anfälligen Versionen R82.10 mit Jumbo Hotfix Take 43 oder früher, R82 mit Take 125 oder früher und R81.20 mit Take 165 oder früher sind.

Der Unterschied zwischen beiden ist für Administratoren wichtig. CVE-2026-85102 betrifft Security Gateways und für VPN genutzte Spark Firewalls. CVE-2026-85103 erreicht zusätzlich die Management-Ebene, sodass ein einziges fehlerhaftes Zertifikat die Konsole kompromittieren könnte, die die Richtlinien über die Firewalls einer Organisation verteilt.

Wer exponiert ist und wie dringend

Check Point erklärte, beide Schwachstellen seien intern gefunden worden, und es gebe keine Hinweise auf eine Ausnutzung. Auch existierte zum Zeitpunkt der Offenlegung nach Angaben des Unternehmens kein öffentlicher Proof-of-Concept-Code. Das ist eine Ausgangslage, kein Dauerzustand.

Das niederländische Nationale Cyber-Sicherheitszentrum stufte die Wahrscheinlichkeit einer Ausnutzung und die möglichen Auswirkungen als hoch ein und erklärte am 10. September, es rechne bald mit Ausnutzungsversuchen. Die Begründung ist für diese Fehlerklasse Standard: Eine nicht authentifizierte, remote erreichbare Remote-Code-Ausführung in einer Perimeter-Appliance ist für Ransomware-Gruppen und staatsnahe Akteure attraktiv, und die Geschichte legt nahe, dass das Fenster zwischen Offenlegung und Ausnutzung kurz ist. Die GitLab-Path-Traversal-Lücke, die einen Tag nach dem Check-Point-Update gepatcht wurde, wurde bereits innerhalb von Stunden sondiert, eine Erinnerung daran, wie schnell der Scan-Zyklus läuft.

Check Point entdeckte beide Probleme selbst. Das ist ein gutes Zeichen für die internen Tests des Unternehmens, bedeutet aber auch, dass die Öffentlichkeit keine Gelegenheit hatte, unabhängig einzuschätzen, wie schwer die Fehler auszulösen sind, und dass kein Proof-of-Concept kursiert, mit dem Verteidiger ihre eigene Exposition testen könnten.

Behobene Versionen und Workarounds

Für unterstützte Zweige sind die behobenen Stände R82.10 Jumbo Hotfix Take 44 oder später, R82 Take 126 oder später und R81.20 Take 166 oder später. Die Spark-Firewall-Fixes sind in R82.00.10 Build 2325 oder später und R81.10.17 Build 4968 oder später enthalten. Kunden mit aktiviertem Check Point LivePatch sollten die Fixes automatisch erhalten; das Unternehmen begann den LivePatch-Rollout am 9. September. Administratoren, die nicht überprüft haben, ob der Patch tatsächlich installiert wurde, sollten nicht davon ausgehen, dass der automatische Weg funktioniert hat, und den installierten Hotfix- oder LivePatch-Stand mit dem Advisory abgleichen.

Wo ein sofortiges Patchen nicht möglich ist, empfiehlt Check Point eine vorübergehende Verringerung der Exposition für Site-to-Site-VPN: die impliziten Regeln für VPN deaktivieren und den VPN-Zugriff auf UDP-Port 500 und UDP-Port 4500 manuell definieren, beschränkt auf bestimmte Peer-IP-Adressen. Das Unternehmen warnt, dass diese Maßnahme nicht für Remote-Access-VPN gilt und dass es für lokal verwaltete Spark-Firewall-Instanzen keinen Workaround gibt, die so schnell wie möglich gepatcht werden sollten.

Diese Einschränkungen sind ein Provisorium, keine Behebung. Jede Peer-Adresse, die den VPN-Port weiterhin erreichen darf, kann das fehlerhafte Zertifikat nach wie vor liefern, sodass eine engere Allowlist die Angriffsfläche verringert, ohne die Schwachstelle zu schließen.

Das größere Muster

Die Offenlegung von Check Point fällt in einen dicht gedrängten Monat für die Sicherheit von Netzwerk-Perimetern. Cisco Talos berichtete, dass drei getrennte Bedrohungscluster zwei Fehler im Secure Firewall Management Center ausgenutzt hätten, darunter eine Umgehung der Authentifizierung mit Höchstwertung, wobei ein Cluster mit Qilin-Ransomware-Affiliates und ein weiteres mit einer Gruppe verbunden ist, deren Tooling sich mit der Sandworm-APT überschneidet. CISA nahm fünf weitere aktiv ausgenutzte Fehler in seinen Katalog bekannter ausgenutzter Schwachstellen auf, darunter JFrog Artifactory, ConnectWise ScreenConnect und MikroTik RouterOS. Und GitLabs Path-Traversal-Lücke mit CVSS 10,0 wurde innerhalb eines Tages nach ihrem Patch sondiert.

Zusammengenommen ist das Muster vertraut: Die Appliances, auf die Organisationen setzen, um Vertrauen am Netzwerkrand durchzusetzen, werden selbst zum Ziel, weil die Kompromittierung einer einzigen Zugang zu allem dahinter verschafft. VPN-Konzentratoren sind besonders wertvoll, weil sie konstruktionsbedingt im offenen Internet stehen und ihre Nutzer erwarten, dass sie erreichbar sind.

Wie Angreifer exponierte Gateways finden

Das praktische Risiko einer solchen Lücke hängt weniger von ihrem CVSS-Wert ab als davon, wie viele betroffene Geräte aus dem Internet erreichbar sind und wie schnell ein Exploit auftaucht. Beide Bedingungen begünstigen in der Regel den Angreifer. Internetweite Scan-Dienste erfassen VPN-Portale fortlaufend, und ein Gateway, das auf einer Anmeldeseite Hersteller und Version preisgibt, lässt sich mühelos katalogisieren. Sobald ein Patch veröffentlicht ist, erlauben dieselben Dienste einem Angreifer, nach ungepatchten Geräten zu filtern, und die Spanne zwischen Offenlegung und Waffenfähigkeit wird oft in Tagen gemessen.

Perimeter-Appliances sind aus diesem Grund zu einem bevorzugten Vektor für den Erstzugang geworden. In den vergangenen Jahren gab es anhaltende Kampagnen gegen VPN- und Edge-Geräte von Ivanti, Fortinet, Citrix, Palo Alto Networks und Cisco, wobei sowohl staatliche Gruppen als auch Ransomware-Affiliates sie als Weg in anderweitig gut verteidigte Netze nutzen. Eine erfolgreiche Kompromittierung eines Management-Servers ist noch schlimmer: Sie kann einem Angreifer die Möglichkeit geben, Richtlinien durchzusetzen, neue Zertifikate zu vertrauen und jedes Gateway zu erreichen, das der Server steuert.

Diese Geräte zu patchen ist schwieriger, als es aussieht. Sie stehen in änderungskontrollierten Umgebungen, in denen Ausfallzeiten ein Wartungsfenster erfordern, laufen oft in Hochverfügbarkeitspaaren, die nacheinander aktualisiert werden müssen, und werden vielfach von regionalen Teams ohne zentrale Bestandsliste verwaltet. Appliances erzeugen zudem weit weniger Sicherheits-Telemetrie als Endpunkte, sodass ein Einbruch nur wenige offensichtliche Spuren hinterlassen kann. Check Points eigener Rat, zu prüfen, ob der automatische LivePatch tatsächlich installiert wurde, spiegelt wider, wie oft die Angabe, gepatcht zu haben, in Wahrheit bedeutet, dass das Update lediglich eingeplant war.

Die Kombination aus hohem Wert, schneller Waffenfähigkeit und langsamer Behebung ist der Grund, warum Regulierer und Incident-Response-Firmen Edge-Schwachstellen als dringend behandeln, noch bevor eine Ausnutzung bestätigt ist. Für Angreifer ist ein ungepatchtes Gateway oft der billigste Weg zu einem Standfuß, und für Verteidiger ist es häufig das letzte Gerät, an dessen Aktualisierung jemand denkt.

Was zu tun ist

Check-Point-Kunden sollten ihre Gateways, Management-Server und Spark-Appliances inventarisieren, das genaue Release und den installierten Hotfix-Take festhalten und anhand der Hersteller-Advisories prüfen, ob jedes Gerät betroffen ist. Geräte mit einem behobenen Take sollten als saniert dokumentiert werden. Geräte mit einem betroffenen Take, bei denen LivePatch nicht bestätigt installiert ist, sollten über den unterstützten Jumbo-Hotfix-Pfad für ihren Zweig aktualisiert werden.

Langfristig stützt der Vorfall das Argument, den Handlungsspielraum einer VPN-Appliance einzuschränken. Management-Schnittstellen auf ein getrenntes Netz zu beschränken, Multi-Faktor-Authentifizierung auch dort durchzusetzen, wo Zertifikate verwendet werden, und Fehler bei der Zertifikatsverarbeitung auf Anzeichen von Sondierung zu überwachen, verringern alle den Schadenradius, wenn ein Patch zu spät kommt. Keine dieser Kontrollen ersetzt das Aktualisieren einer Appliance, die eine mit 9,8 bewertete Schwachstelle vor der Authentifizierung aufweist. Aber sie sind es, die aus einem Perimeter-Einbruch einen begrenzten Vorfall statt eines netzwerkweiten machen.

Die unmittelbare Maßnahme ist unspektakulär und zeitkritisch: patchen, die Installation des Patches überprüfen und die Fehler nicht erst dann als dringend behandeln, wenn ein Proof-of-Concept auftaucht.