NCSC erwartet baldige Angriffe auf die Check-Point-VPN-Lücken

Seit dem 9. September 2026 gibt es Sicherheitsupdates für zwei kritische Schwachstellen in den VPN-Komponenten von Check Point. Vier Tage später hat das niederländische Nationaal Cyber Security Centrum (NCSC) nachgelegt und eine eigene Warnung veröffentlicht: Die Behörde bewertet sowohl die Wahrscheinlichkeit einer Ausnutzung als auch den möglichen Schaden als hoch und rechnet kurzfristig mit Angriffsversuchen. Damit wechselt die Lage von "Patch liegt bereit" zu "Zeitfenster schließt sich".

Wer ein Check Point Security Gateway oder einen Security Management Server mit aktiviertem VPN betreibt und die Fixes noch nicht eingespielt hat, sollte das heute prüfen und nicht auf das nächste reguläre Wartungsfenster verschieben. Wichtig für die Einordnung: Ein öffentlicher Proof-of-Concept-Exploit ist bislang nicht bekannt. Es liegen auch keine Berichte über tatsächlich erfolgte Angriffe vor. Die Warnung beschreibt eine erwartete, keine bereits laufende Ausnutzung.

Was ist neu an dieser Warnung?

Über die technischen Details und die Patchveröffentlichung selbst haben wir bereits berichtet, siehe Check Point schließt zwei kritische VPN-Zertifikatslücken mit CVSS 9.8. Neu ist nicht die Lücke, neu ist die behördliche Dringlichkeitsbewertung.

Das NCSC hat am 10. September 2026 einen eigenen Alert mit dem Titel "Kritieke kwetsbaarheden in Check Point VPN-producten met actief misbruik verwacht: update nu" veröffentlicht. Darin heißt es sinngemäß, dass die Behörde die Ausnutzungswahrscheinlichkeit und den potenziellen Schaden als hoch einstuft und in Kürze mit Missbrauchsversuchen in größerem Umfang rechnet. In der englischsprachigen Wiedergabe lautet die Kernaussage: "The NCSC assesses the likelihood of exploitation and the potential impact as high and expects exploitation attempts to occur soon."

Solche Alerts gibt das NCSC nicht für jede kritische Lücke heraus. Der Anlass ist typischerweise eine Kombination aus hoher CVSS-Bewertung, einem am Internetrand exponierten Dienst und einer Angreiferlandschaft, die genau solche Geräte gezielt sucht. VPN-Gateways erfüllen alle drei Kriterien. Historisch vergehen zwischen Patchveröffentlichung für eine internetseitig erreichbare Firewall- oder VPN-Lücke und den ersten Massenscans oft nur wenige Tage, weil der Patch selbst Angreifern eine Vorlage für das Reverse Engineering liefert.

Welche Lücken genau betroffen sind

Es geht um zwei getrennt geführte Schwachstellen, die Check Point in den Advisories sk1000117 und sk1000118 beschreibt. Beide tragen laut Eintrag in der NVD-Datenbank eine CVSS-3.1-Basisbewertung von 9.8 mit dem Vektor AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. Das bedeutet in der Praxis: über das Netz erreichbar, geringe Angriffskomplexität, keine Zugangsdaten und keine Nutzerinteraktion nötig.

• CVE-2026-85102: Eine unzureichende Prüfung der Zertifikatsvertrauensstellung während der VPN-Aushandlung. Ein nicht authentifizierter Angreifer aus der Ferne kann darüber eigenen Code auf einem Quantum Security Gateway ausführen.
• CVE-2026-85103: Ein Heap-basierter Pufferüberlauf im ASN.1-Decoder für VPN-Zertifikate. Diese Lücke betrifft nicht nur Security Gateways, sondern zusätzlich Quantum Security Management Systeme, also die zentrale Verwaltungsebene.

Der zweite Punkt ist der operativ unangenehmere: Wer nur die Gateways im Blick hat und den Management Server als "internes System" einstuft, unterschätzt die Reichweite. Ein kompromittierter Management Server bedeutet Kontrolle über das Regelwerk sämtlicher verwalteter Gateways.

Wer ist betroffen und wer nicht?

Betroffen sind laut Check Point und NCSC die Releases R81.20, R82, R82.10, R81.10.x und R82.00.x. Hinzu kommen die bereits aus dem Support gefallenen Versionen R80 bis R80.40 sowie R81 und R81.10. Für diese End-of-Support-Stände gibt es keinen regulären Fix, hier hilft nur ein Versionssprung oder eine sofortige Absicherung auf Netzwerkebene.

Ausdrücklich nicht betroffen ist R82.20. Wer bereits auf diesem Stand fährt, muss für diese beiden CVEs nichts unternehmen und sollte die Zeit stattdessen in die Prüfung der übrigen Umgebung stecken. Ebenfalls außen vor bleibt, wer auf den betroffenen Gateways überhaupt kein VPN-Blade aktiviert hat, denn beide Fehler sitzen in der VPN-Zertifikatsverarbeitung. Diese Konstellation ist in der Praxis allerdings selten, und im Zweifel gilt die Lücke als relevant, bis das Gegenteil belegt ist.

Fixstände im Überblick

Check Point liefert die Korrektur über mehrere Wege aus. Der schnellste Weg ist der LivePatch-Mechanismus, der reguläre Weg der Jumbo Hotfix Accumulator. Die folgende Übersicht fasst zusammen, welcher Stand als behoben gilt.

Release	Behoben ab	Hinweis
R82.20	nicht betroffen	Kein Handlungsbedarf für diese beiden CVEs
R82.10	Jumbo Hotfix Accumulator Take 44 oder neuer	Alternativ LivePatch Take 24
R82	Jumbo Hotfix Accumulator Take 126 oder neuer	Alternativ LivePatch Take 24
R81.20	Jumbo Hotfix Accumulator Take 166 oder neuer	Alternativ LivePatch Take 24
Spark R82.00.10	Build 2325 oder neuer	Appliance-Linie für kleinere Standorte
Spark R81.10.17	Build 4968 oder neuer	Appliance-Linie für kleinere Standorte
R80 bis R80.40, R81, R81.10	kein Fix	End of Support, Migration oder Netzabschottung nötig

Check Point LivePatch, kurz CPLP, verdient dabei eine gesonderte Betrachtung. Laut einem Beitrag im Check-Point-Community-Forum haben CPLP-Nutzer seit dem 9. September alle verfügbaren Schutzmaßnahmen automatisch erhalten, und diese greifen ohne Neustart des Systems. Das ist eine gute Nachricht, aber kein Freibrief: CPLP steht nur für R82.10, R82 und R81.20 zur Verfügung und deckt nicht jede Konfiguration ab. Wer sich darauf verlässt, muss aktiv nachsehen, ob der eigene Stand tatsächlich als geschützt gemeldet wird.

Was Admins in den nächsten Stunden tun sollten

Die Reihenfolge ist bewusst so gewählt, dass die Schritte mit dem größten Risikoabbau zuerst kommen. Punkt eins kostet zehn Minuten und beantwortet die Frage, ob der Rest überhaupt relevant ist.

• Inventar prüfen: Welche Gateways und Management Server laufen auf welchem Release, und auf welchem Jumbo-Hotfix-Take stehen sie? Ohne diese Liste ist jede weitere Entscheidung geraten.
• Abgleich mit der Tabelle oben. Alles unterhalb der genannten Takes gilt als verwundbar, auch wenn das Gerät "aktuell" aussieht.
• CPLP-Status kontrollieren, falls Check Point LivePatch im Einsatz ist. Prüfen, ob die Schutzmaßnahmen für beide CVEs als angewendet gemeldet werden, und das Ergebnis dokumentieren.
• Priorität auf die Systeme legen, deren VPN-Ports aus dem Internet erreichbar sind. Diese sind das eigentliche Ziel der erwarteten Scans.
• Management Server nicht vergessen. CVE-2026-85103 trifft die Verwaltungsebene mit.
• Jumbo Hotfix Accumulator einspielen, wenn LivePatch nicht verfügbar oder nicht anwendbar ist. Bei Clustern nacheinander vorgehen, um die Verfügbarkeit zu halten.
• End-of-Support-Stände R80 bis R80.40, R81 und R81.10 als Sonderfall behandeln: Migrationstermin festlegen und bis dahin eine harte Zugriffsbeschränkung setzen.
• Nach dem Patchen verifizieren, dass der Take tatsächlich aktiv ist, und nicht nur, dass der Download stattgefunden hat.

Wenn Patchen heute nicht möglich ist

Für Umgebungen mit strengen Änderungsprozessen oder für nicht mehr supportete Stände nennt das NCSC eine konkrete Übergangsmaßnahme, die sich auf die Site-to-Site-VPN-Komponente bezieht. Sie ersetzt den Patch nicht, verkleinert aber die Angriffsfläche deutlich.

• VPN-Regeln so anpassen, dass der Zugriff auf definierte, vertrauenswürdige IP-Adressen beschränkt wird. Ein VPN-Endpunkt, der nur mit bekannten Gegenstellen spricht, ist für breit angelegte Scans erheblich schwerer zu erreichen.
• Das NCSC empfiehlt in diesem Zusammenhang zusätzlich, die sogenannten Implied Rules zu deaktivieren, also die impliziten Regeln, die Check Point standardmäßig vor dem eigentlichen Regelwerk auswertet.
• Protokollierung an den VPN-Endpunkten hochdrehen und ungewöhnliche Aushandlungsversuche, abgebrochene Handshakes oder Zertifikatsfehler gezielt beobachten.
• Ein Wiederherstellungspunkt oder eine gesicherte Konfiguration des Management Servers sollte vorliegen, bevor größere Änderungen am Regelwerk erfolgen.

Wichtig bei der Kommunikation nach innen: Diese Maßnahmen sind eine Übergangslösung mit Ablaufdatum, kein dauerhafter Ersatz. Sobald ein Wartungsfenster verfügbar ist, gehört der reguläre Fix eingespielt.

Einordnung für kleinere Unternehmen

Für kleinere Betriebe ist der eigentliche Stolperstein selten der Patch, sondern die Frage, wer ihn verantwortet. Viele Check-Point-Installationen in dieser Größenordnung, insbesondere die Spark-Appliances an Außenstandorten, werden von einem Dienstleister betreut. Das NCSC weist ausdrücklich darauf hin, bei Unsicherheit über die eingesetzte Version den IT-Dienstleister zu kontaktieren. Genau das ist hier die richtige erste Handlung: eine kurze, schriftliche Anfrage mit der Bitte um Bestätigung des Patchstands je Standort.

Schriftlich deshalb, weil es zwei Dinge leistet. Erstens zwingt es zu einer eindeutigen Antwort statt eines "läuft alles". Zweitens entsteht ein Nachweis, der bei einem späteren Vorfall die Frage beantwortet, wann welche Information vorlag. Für Unternehmen, die unter regulatorische Meldepflichten fallen, ist dieser Nachweis Teil der Sorgfaltspflicht.

Der zweite Punkt betrifft die Erwartungshaltung: Eine erwartete Ausnutzung ist kein Grund für Aktionismus, aber ein guter Anlass, den Patchprozess für internetseitig erreichbare Systeme grundsätzlich zu überdenken. Wer für ein VPN-Gateway sechs Wochen Vorlauf braucht, hat unabhängig von diesen beiden CVEs ein strukturelles Problem.

Passende Anleitungen auf S-EDV

• Site-to-Site-VPN mit WireGuard und IPsec über OPNsense: zeigt, wie sich Standortkopplungen mit klar eingegrenzten Gegenstellen aufbauen lassen, was hier genau der empfohlenen IP-Beschränkung entspricht.
• Zero-Trust-Netzwerksegmentierung mit VLANs und Firewall-Regeln: hilft dabei, die Folgen einer kompromittierten Gateway- oder Management-Ebene einzugrenzen, statt sich allein auf den Perimeter zu verlassen.
• CISA-KEV-Katalog als Werkzeug zur Patch-Priorisierung: erklärt, wie sich Behördenwarnungen dieser Art in eine belastbare Reihenfolge für das eigene Patchmanagement übersetzen lassen.

Quellen

• NCSC Niederlande: Kritieke kwetsbaarheden in Check Point VPN-producten met actief misbruik verwacht (Alert vom 10. September 2026)
• BleepingComputer: Dutch NCSC: Critical Check Point VPN flaws exploitation is imminent (Bill Toulas, 12. September 2026)
• Check Point sk1000117: CVE-2026-85102, Authentication Bypass and Remote Code Execution in Remote Access and Site-to-Site VPN
• Check Point sk1000118: CVE-2026-85103, ASN.1 decoding heap overflow leading to a remote code execution
• NVD-Eintrag zu CVE-2026-85102 mit CVSS-3.1-Bewertung 9.8
• NVD-Eintrag zu CVE-2026-85103 mit CVSS-3.1-Bewertung 9.8