Es gibt eine ganz bestimmte Art von schlechtem Tag in der Sicherheit: den, an dem der Fix längst existierte, die Angreifer das wussten und zwischen ihnen und deinem Netzwerk nur ein Wartungsfenster stand, das niemand eingeplant hatte.
Genau dort sitzen Check-Point-Kunden gerade. Am 22. September veröffentlichte Check Point Research eine dringende Warnung und bestätigte die aktive Ausnutzung von CVE-2026-85102, einer Pre-Authentication-Remote-Code-Execution-Lücke in der VPN-Zertifikatsverarbeitung von Security Gateway und Spark Firewall. Der Patch dafür erschien am 9. September. Die Ausnutzungsversuche begannen am 12. September. Zwischen "Fix verfügbar" und "Angriffe laufen" lagen drei Tage.
Was genau kaputt ist
CVE-2026-85102 ist ein Fehler bei der Zertifikatsvalidierung im VPN-Aushandlungspfad, bewertet mit CVSS 9.8. Das Gateway prüft die wichtigsten Zertifikatsdaten, die eine Gegenstelle während der Aushandlung vorlegt, nicht korrekt. Weil der Fehler vor Abschluss der Authentifizierung greift, braucht der Angreifer weder Benutzername noch Passwort noch Session. Er schickt ein manipuliertes Zertifikat, treibt die Aushandlung weit genug und erhält Codeausführung auf dem Appliance selbst. Betroffen sind Versionen von R81.10.x bis R82.10, sowohl bei Security Gateway als auch bei zentral und lokal verwalteten Spark-Firewall-Deployments.
Die zweite Lücke, CVE-2026-93616, ist ein Pre-Auth-Path-Traversal im Webdienst von Check Point Management. Sie erlaubt es einem Angreifer, ein Skript aus einem beliebigen Pfad auszuführen und eine beliebige Java-Klasse zu laden. Check Point beobachtete am 23. Juli eine Handvoll gezielter Angriffe darauf, und der Fix kam mit dieser Warnung. Beachte das schmerzhafte Detail: LivePatch Take 28/29 behebt sie nicht.
Der Teil, der dich beunruhigen sollte
Das ist keine theoretische "Forscher haben es demonstriert"-Geschichte. Check Point veröffentlichte die Zertifikats-Subjects, die die eigene Telemetrie in freier Wildbahn erfasst hat:
CN=vpn,OU=users,O=globalCN=vpn-user,OU=users,O=globalCN=vpnuser,OU=users,O=global
Diese Versuche kamen aus Anonymisierungsinfrastruktur: VPN-Dienste und Proxys, die übliche Waschschicht. Das Folgeverhalten ist das eigentliche Signal. Nach einem verdächtigen Mobile-Access-Login ist die beobachtete zweite Phase internes Port- und Service-Scanning. Jemand kommt über den Perimeter hinein und beginnt zu kartieren, was sonst noch erreichbar ist.
Und der Perimeter ist genau der Ort, an dem eine Pre-Auth-RCE am teuersten ist. Dein VPN-Gateway ist keine App hinter einem WAF. Es ist ein spezialisiertes Appliance auf der Vertrauensgrenze, meist mit deinem Identity Provider, deinem internen Managementnetz und manchmal deinem Verzeichnisdienst verbunden. Codeausführung dort ist kein Schritt zur Privilegienerweiterung. Sie ist meist schon hinter der Mauer.
Drei Tage sind das neue Für-immer
Die Zeitachse verdient einen nüchternen Blick, denn sie ist die eigentliche Lektion:
-
- September: Check Point veröffentlicht CVE-2026-85102 und stellt Fixes bereit. Keine Ausnutzung beobachtet.
-
- September: Eine Welle von Ausnutzungsversuchen gegen Spark-Kunden weltweit beginnt.
-
- September: Eine dringende Warnung bestätigt Angriffe in freier Wildbahn.
Das sind zwei Wochen von der Offenlegung bis zur bestätigten Ausnutzung und nur drei Tage vom Patch bis zum Angriff. Wer einen Wartungszyklus fährt, der länger dauert, verwaltet eine Exposition, keinen Zeitplan. Die öffentliche Proof-of-Concept-Ökonomie und automatisiertes Scanning sind heute schlicht zu schnell, als dass vierteljährliches Patchen eine Strategie wäre.
Was diese Woche zu tun ist
Wenn du Check Point Security Gateway oder Security Management betreibst, behandle das als Änderung der Incident-Response-Haltung, nicht als Patch-Ticket:
- Installiere die Fixes jetzt. CVE-2026-85102 ist durch das Release vom 9. September abgedeckt; CVE-2026-93616 erfordert die in der Warnung genannten Jumbo-Hotfix-Takes (R82.10 Take 45+, R82 Take 127+, R81.20 Take 167+, R81.10 Take 191+) oder den neueren Build aus sk1000171. Für die Management-Lücke LivePatch Take 28/29 überspringen.
- Durchsuche deine Mobile-Access-Logs. Suche nach anomalen zertifikatsbasierten Logins und beschränke die Suche nicht auf die drei genannten Subjects. Die Liste ist ausdrücklich nicht vollständig.
- Verfolge die zweite Phase. Suche für jeden verdächtigen eingeloggten Nutzer nach internen Port- und Service-Scans aus dieser Session. Dieses Muster unterscheidet eine blockierte Sonde von einem Standfuß.
- Inventarisiere den EOS-Rest. R81 und R81.10 sind End-of-Support und stehen weiterhin auf der Liste. Wer solche Systeme betreibt, patcht etwas, wofür niemand standardmäßig Fixes liefert. Plane den Ersatz, nicht nur den Hotfix.
- Gehe davon aus, dass Aushandlungsfehler rekursiv sind. Jedes VPN- und TLS-Appliance, das du betreibst, validiert irgendwo Zertifikate. Stelle deinen Herstellern die unangenehme Frage: Was passiert, wenn diese Validierung offen scheitert?
Das Fazit
Die Angreifer brauchten für das Hauptereignis keine Zero-Day-Magie. Sie nutzten eine Lücke mit Fix, Warnung und zwei Wochen Vorsprung. Die Organisationen, die hier Schaden nehmen, sind nicht die mit dem schwächsten Werkzeug. Es sind die, deren Change-Management eine 9.8-Perimeter-RCE als Routineposten behandelt.
Jetzt patchen. Dann die Logs lesen. Die Scans sind der Teil der Geschichte, den du noch erwischen kannst.