Il existe un type très particulier de mauvaise journée en sécurité : celle où le correctif existait déjà, où les attaquants le savaient, et où la seule chose entre eux et votre réseau était une fenêtre de maintenance que personne n'avait planifiée.
C'est exactement la situation des clients Check Point aujourd'hui. Le 22 septembre, Check Point Research a publié un avis urgent confirmant l'exploitation active de CVE-2026-85102, une faille d'exécution de code à distance pré-authentification dans la gestion des certificats VPN de Security Gateway et Spark Firewall. Le correctif est sorti le 9 septembre. Les tentatives d'exploitation ont commencé le 12 septembre. Entre "correctif disponible" et "attaques en cours", il y avait trois jours.
Ce qui est réellement cassé
CVE-2026-85102 est un défaut de validation des certificats dans le chemin de négociation VPN, noté CVSS 9.8. La passerelle ne valide pas correctement les données essentielles du certificat présenté par un pair pendant la négociation. Comme la faille se déclenche avant la fin de l'authentification, l'attaquant n'a besoin ni d'identifiant, ni de mot de passe, ni de session. Il envoie un certificat falsifié, pousse la négociation assez loin et obtient l'exécution de code sur l'équipement lui-même. Les versions touchées vont de R81.10.x à R82.10, sur Security Gateway comme sur les déploiements Spark Firewall gérés de façon centralisée ou locale.
La seconde faille, CVE-2026-93616, est un path traversal pré-authentification dans le service web de Check Point Management. Elle permet à un attaquant d'exécuter un script depuis un chemin arbitraire et de charger une classe Java arbitraire. Check Point a observé une poignée d'attaques très ciblées le 23 juillet, et le correctif est arrivé avec cet avis. Notez le détail qui pique : LivePatch Take 28/29 ne la corrige pas.
La partie qui devrait vous inquiéter
Ce n'est pas une histoire théorique de "les chercheurs l'ont démontré". Check Point a publié les sujets de certificats que sa télémétrie a captés dans la nature :
CN=vpn,OU=users,O=globalCN=vpn-user,OU=users,O=globalCN=vpnuser,OU=users,O=global
Ces tentatives venaient d'une infrastructure d'anonymisation : services VPN et proxys, la couche de blanchiment habituelle. Le comportement qui suit est le vrai signal. Après une connexion Mobile Access suspecte, la seconde phase observée est une analyse interne des ports et des services. Quelqu'un entre par le périmètre, puis commence à cartographier ce qui est encore joignable.
Et le périmètre est précisément l'endroit où un RCE pré-authentification coûte le plus cher. Votre passerelle VPN n'est pas une application derrière un WAF. C'est un équipement dédié posé sur la frontière de confiance, souvent relié à votre fournisseur d'identité, à votre réseau d'administration interne et parfois à votre annuaire. L'exécution de code à cet endroit n'est pas une étape vers l'élévation de privilèges. Elle est généralement déjà derrière le mur.
Trois jours, c'est le nouveau toujours
La chronologie mérite un regard froid, car c'est la vraie leçon :
- 9 septembre : Check Point divulgue CVE-2026-85102 et publie les correctifs. Aucune exploitation observée.
- 12 septembre : une vague de tentatives d'exploitation commence contre les clients Spark dans le monde entier.
- 22 septembre : un avis urgent confirme les attaques dans la nature.
Cela fait deux semaines entre la divulgation et l'exploitation confirmée, et seulement trois jours entre le correctif et l'attaque. Toute organisation dont le cycle de maintenance est plus long gère une exposition, pas un calendrier. L'économie publique des proof-of-concepts et le scan automatisé vont trop vite aujourd'hui pour que la correction trimestrielle soit une stratégie.
Que faire cette semaine
Si vous exploitez Check Point Security Gateway ou Security Management, traitez cela comme un changement de posture de réponse à incident, pas comme un ticket de correctif :
- Installez les correctifs maintenant. CVE-2026-85102 est couvert par la version du 9 septembre ; CVE-2026-93616 exige les takes Jumbo Hotfix indiqués dans l'avis (R82.10 Take 45+, R82 Take 127+, R81.20 Take 167+, R81.10 Take 191+) ou la version plus récente de sk1000171. Ignorez LivePatch Take 28/29 pour la faille de management.
- Analysez vos journaux Mobile Access. Cherchez les connexions anormales par certificat et ne limitez pas la recherche aux trois sujets ci-dessus. La liste n'est explicitement pas exhaustive.
- Traquez la seconde phase. Pour chaque utilisateur suspect connecté, cherchez des scans internes de ports et de services issus de cette session. Ce schéma permet de distinguer une sonde bloquée d'un point d'ancrage.
- Inventoriez la queue hors support. R81 et R81.10 sont en fin de support et figurent toujours dans la liste des versions touchées. Si vous avez des équipements dans cette queue, vous corrigez un système pour lequel personne ne publie de correctifs par défaut. Planifiez le remplacement, pas seulement le hotfix.
- Partez du principe que les failles de négociation sont récursives. Chaque équipement VPN et TLS que vous exploitez valide des certificats quelque part. Posez à vos fournisseurs la question inconfortable : que se passe-t-il quand cette validation échoue en mode ouvert ?
À retenir
Les attaquants n'ont pas eu besoin de magie zero-day pour l'événement principal. Ils ont utilisé une faille qui avait un correctif, un avis et deux semaines d'avance. Les organisations qui souffrent ici ne sont pas celles qui ont les outils les plus faibles. Ce sont celles dont la gestion du changement traite un RCE de périmètre noté 9.8 comme une ligne routinière.
Corrigez maintenant. Puis allez lire les journaux. Les scans sont la partie de l'histoire que vous pouvez encore rattraper.