Check Point confirme l’exploitation active de deux failles pré-authentification dans Gateway et Management
Le 22 septembre 2026, Check Point a publié un avis « Action Required » confirmant l’exploitation en conditions réelles de deux vulnérabilités notées CVSS 9,8 : CVE-2026-85102 dans le VPN du Security Gateway et le zero-day CVE-2026-93616 dans le serveur de Management. Appliquez les correctifs sans délai et traquez les connexions Mobile Access suspectes.
22 septembre 2026. Check Point publie un avis de sécurité intitulé « Action Required ». 9 septembre 2026. Le correctif de la première faille existait déjà, sans preuve d’exploitation à l’époque. 12 septembre 2026. Les premières tentatives d’exploitation sont détectées contre les boîtiers Spark. Pourquoi c’est important : les deux vulnérabilités, toutes deux notées CVSS 9,8, offrent une exécution de code à distance sans authentification sur les deux composants les plus sensibles d’un parc — la passerelle VPN et le serveur de Management.
Deux failles, deux portes d’entrée
L’avis rassemble deux vulnérabilités distinctes, corrigées au même moment mais découvertes selon des calendriers différents. La première, CVE-2026-85102, est une validation incorrecte des données de certificat lors de la négociation VPN du Security Gateway. La seconde, CVE-2026-93616, est un zero-day de type path traversal pré-authentification dans le service web de Management, qui autorise l’exécution d’un script depuis un chemin arbitraire et le chargement d’une classe Java arbitraire.
Le point commun est le plus préoccupant : aucune des deux ne requiert d’identifiants. Un attaquant qui atteint l’une de ces interfaces obtient du code arbitraire, souvent avec des privilèges élevés, sans franchir la moindre étape d’authentification. Dans les deux cas, le verdict CVSS est identique : 9,8, le niveau maximal en pratique pour une faille exploitable à distance.
CVE-2026-85102 : le « jour un » devenu exploitation de masse
Check Point a divulgué CVE-2026-85102 et publié son correctif le 9 septembre 2026. À cette date, l’éditeur ne disposait d’aucune preuve d’exploitation. Trois jours plus tard, le 12 septembre, une vague de tentatives visait les clients Spark à l’échelle mondiale.
Les tentatives proviennent d’infrastructures d’anonymisation — VPN et proxys — et s’appuient sur des certificats aux sujets reconnaissables :
CN=vpn,OU=users,O=global
CN=vpn-user,OU=users,O=global
CN=vpnuser,OU=users,O=globalLa liste n’est pas exhaustive : d’autres sujets de certificat circulent probablement déjà. Les versions touchées couvrent les Security Gateway et les pare-feu Spark (gérés centralement ou localement) : R81 et R81.10 (tous deux en fin de vie), R81.10.X, R81.20, R82, R82.00.X et R82.10. Le correctif est documenté dans l’article sk1000117.
CVE-2026-93616 : le zero-day du Management
La seconde faille est plus discrète et, à certains égards, plus grave. CVE-2026-93616 est un path traversal pré-authentification dans le service web de Management de Check Point. Il permet à un attaquant d’exécuter un script depuis un chemin arbitraire et de charger une classe Java arbitraire — ce qui équivaut, en pratique, à une prise de contrôle complète du serveur qui orchestre les politiques de sécurité du parc.
Check Point a observé « une poignée d’attaques ciblées » le 23 juillet 2026. Les versions affectées vont de R82.20 jusqu’aux R80.x historiques (tous en fin de vie), en passant par les Jumbo Hotfix suivants : R82.10 Take 44 ou inférieur, R82 Take 126 ou inférieur, R81.20 Take 166 ou inférieur et R81.10 Take 190 ou inférieur. L’éditeur précise un point décisif : LivePatch Take 28/29 ne corrige pas cette faille — une mise à jour complète est requise. Le correctif et les indicateurs de compromission sont détaillés dans l’article sk1000171.
Pourquoi le Management est la cible reine
Un serveur de Management compromis ne se compare pas à une passerelle compromise. C’est lui qui pousse les politiques vers chaque passerelle du parc, qui centralise les identifiants d’administration et qui agrège les journaux. Si un attaquant en prend le contrôle, il tient la politique de sécurité : il peut ouvrir n’importe quelle règle, désactiver les protections et pivoter vers toutes les passerelles gérées.
C’est précisément ce qui rend CVE-2026-93616 si dangereuse. Une RCE pré-authentification sur cette surface transforme la machine qui est censée défendre le réseau en point de départ de l’intrusion. La règle d’or, rappelée en creux par l’avis, reste la même : le Management ne doit jamais être joignable depuis Internet.
Ce que recommande l’éditeur
La consigne tient en trois actions. Installer les correctifs immédiatement — c’est la seule mesure qui ferme réellement les deux brèches. Inspecter les journaux à la recherche de connexions Mobile Access anormales fondées sur des certificats, sans se limiter aux sujets listés ci-dessus. Traquer l’activité de second étage : les attaquants, une fois connectés, lancent souvent des scans de ports et de services internes pour préparer le déplacement latéral.
Pour les équipes qui gèrent des parcs Spark, le risque est immédiat : l’exploitation de CVE-2026-85102 est en cours et automatisée. Pour celles qui exposent un serveur de Management, la question ne se pose même pas — le réflexe est de couper l’exposition avant d’appliquer le correctif.
Une fenêtre de trois jours, encore une fois
Le calendrier de CVE-2026-85102 — correctif le 9 septembre, exploitation le 12 septembre — rappelle une tendance désormais structurelle : la fenêtre entre la publication d’un correctif et son exploitation de masse ne cesse de se réduire. L’éditeur publie, l’attaquant transforme en quelques jours, parfois moins.
Pour un équipement de périmètre, la seule parade qui gagne est l’automatisation. Patcher en quelques heures, pas en quelques semaines, et surveiller en continu les interfaces d’administration pour repérer le moindre signe d’exploitation avant qu’il ne se transforme en compromission confirmée.
Comment évaluer votre exposition
La première étape n’est pas de patcher, c’est de savoir ce que vous faites tourner. Sur une passerelle ou un serveur de Management Check Point, la commande cpinfo -y all renvoie la version produit et le Jumbo Hotfix Take installé. C’est ce numéro de Take qu’il faut comparer aux seuils vulnérables listés dans l’avis.
# Version produit + niveau de correctif installé
cpinfo -y all | grep -iE 'version|take|hotfix'
# Lister les connexions Mobile Access récentes (chasse à CVE-2026-85102)
fw log -f | grep -iE 'mobile access|vpn|certificate'
# Vérifier si le Management écoute sur une interface publique (à proscrire)
netstat -tulpn | grep -E ':(443|80|18264)\b'Un parc qui tourne encore en R81 ou R81.10 — tous deux en fin de vie — cumule deux risques : une faille connue et l’absence de correctif officiel à venir. Pour ces versions, la réponse n’est pas un patch mais une migration planifiée vers une branche supportée. Plus ces boîtiers restent en ligne, plus ils offrent une cible large à une campagne qui a déjà prouvé qu’elle tire dans les jours qui suivent une divulgation.
Verdict
Check Point livre la démonstration d’un schéma désormais classique : un correctif publié, un délai de trois jours, puis une exploitation automatisée contre les équipements exposés. Si vous exploitez des passerelles Check Point, en particulier des boîtiers Spark, appliquez sk1000117 sans attendre et chassez les connexions VPN à certificat anormal. Si vous gérez un serveur de Management, appliquez sk1000171, vérifiez qu’il n’est pas exposé publiquement et traitez tout accès non autorisé comme un incident. Les deux failles offrent une exécution de code à distance sans authentification : le coût du correctif est sans commune mesure avec celui d’une passerelle ou d’un Management compromis.