Check Point confirme l’exploitation d’une faille VPN corrigée en septembre et publie une zero-day sur le serveur de management

12 septembre 2026. Check Point observe les premières tentatives d’exploitation de CVE-2026-85102 contre ses pare-feu Spark, trois jours seulement après la publication du correctif. 9,8. Le score CVSS des deux failles pré-authentification que Check Point détaille dans son avis « Action Required » publié mi-octobre. 23 juillet 2026. La date des premières attaques ciblées de CVE-2026-93616, une zero-day du serveur de management corrigée seulement maintenant. Pourquoi c’est important : une faille VPN patchée depuis cinq semaines est en train d’être exploitée en masse, et la nouvelle zero-day touche l’appliance que les équipes patchent toujours en dernier — le serveur de management.

La faille VPN : corrigée, puis exploitée

CVE-2026-85102 est une validation incorrecte des données de certificat (CWE-295) pendant la négociation VPN des Security Gateway Check Point. Un attaquant distant non authentifié peut exécuter du code arbitraire sur la passerelle. La faille concerne le Remote Access VPN comme le VPN site-à-site, et les produits touchés vont de R81 à R82.10, y compris les pare-feu Spark (gérés centralement ou localement).

Check Point a divulgué et corrigé la faille le 9 septembre 2026, dans un lot de correctifs d’urgence qui incluait aussi CVE-2026-85103, un dépassement de tampon dans le décodage ASN.1 des certificats, lui aussi à 9,8. À l’époque, l’éditeur indiquait n’avoir « aucune preuve d’exploitation ». Cette prudence n’a pas tenu longtemps.

Le 12 septembre, Check Point observe une vague de tentatives d’exploitation contre des clients Spark. Les tentatives proviennent d’infrastructures d’anonymisation — VPN commerciaux et proxys — et présentent des certificats aux sujets prévisibles : CN=vpn, CN=vpn-user, CN=vpnuser, tous avec OU=users, O=global. L’attaquant frappe donc la porte du VPN avec un certificat malformé dont la validation échoue d’une manière exploitable, sans avoir besoin d’aucun compte.

La zero-day du serveur de management

CVE-2026-93616 est d’une autre nature : c’est une traversée de chemin pré-authentification doublée d’un dépôt de fichier dans le service web du serveur de management Check Point. Elle permet d’exécuter un script depuis un chemin arbitraire et de charger une classe Java arbitraire — donc, là encore, une exécution de code sans authentification.

Check Point la qualifie de zero-day : une poignée d’attaques ciblées a été identifiée dès le 23 juillet 2026. Elle touche Security Management R82.20, R82.10 (Jumbo Hotfix Take 44 ou moins), R82 (Take 126 ou moins), R81.20 (Take 166 ou moins), ainsi que les versions plus anciennes en fin de support. Le correctif n’est disponible que maintenant, avec l’avis « Action Required ».

Le point qui compte : le serveur de management est l’appareil qui contrôle toutes les passerelles d’un parc. Une RCE dessus, ce n’est pas un pare-feu qui tombe, c’est la politique de sécurité entière qui passe sous contrôle — les règles, les objets, les certificats, les comptes d’administration.

Pourquoi « corrigé » ne veut pas dire « protégé »

La leçon de CVE-2026-85102 tient en une chronologie : correctif le 9 septembre, exploitation le 12 septembre, confirmation publique mi-octobre. Le fossé n’est pas technologique, il est opérationnel. Les clients Spark visés disposaient d’un correctif depuis des semaines, mais ne l’avaient pas appliqué — un schéma que l’on retrouve sur les appliances de périmètre, où la peur de casser le VPN en production retarde le patch.

CVE-2026-93616 aggrave le tableau en visant l’autre bout du spectre de la négligence. Le serveur de management est rarement exposé sur Internet, ce qui le fait passer pour moins urgent ; il est pourtant la cible au rendement maximal, puisque sa compromission donne les clés de tout le parc. Check Point précise que son LivePatch (Take 28/29) ne corrige pas cette zero-day — un piège pour les équipes qui comptent sur la correction à chaud sans rebooter.

Ce qu’il faut faire, dans l’ordre

D’abord, le serveur de management. Appliquez le correctif de CVE-2026-93616 (SK sk1000171) en priorité, puis suivez les étapes de hunting et les indicateurs de compromission du même SK pour vérifier qu’aucun script n’a déjà été déposé. C’est l’appareil dont la compromission annule tout le reste.

Ensuite, les passerelles. Si vous n’avez pas appliqué le correctif du 9 septembre, faites-le immédiatement (SK sk1000117) et traitez les passerelles comme potentiellement compromises, pas seulement comme à patcher. Check Point recommande d’examiner les logs à la recherche de connexions Mobile Access par certificat anormales — sans se limiter aux trois sujets connus — puis de chercher l’activité de second temps : balayages de ports et de services internes depuis les comptes connectés.

Enfin, la posture. Les infrastructures d’anonymisation utilisées compliquent l’attribution, mais le modus operandi — certificat malformé, puis reconnaissance interne — est celui d’un acteur qui prépare l’accès initial pour autre chose. Considérez une remédiation complète sur les passerelles exposées, pas un simple redémarrage.

Verdict

Si vous utilisez des appliances Check Point, l’urgence est double mais hiérarchisée : appliquez d’abord le correctif du serveur de management (CVE-2026-93616), puis celui des passerelles (CVE-2026-85102) si ce n’est pas déjà fait, et menez le hunting dans les deux cas. Si vous aviez déjà appliqué le correctif du 9 septembre, vous êtes à l’abri de la faille VPN, mais toujours exposé à la zero-day de management — le sentiment de sécurité est précisément le piège. Et retenez la chronologie : entre la publication d’un correctif et son application, il y a une fenêtre que les attaquants savent mesurer en jours, pas en semaines.

Références

• Check Point Blog — Security Advisory, Action Required : CVE-2026-85102 et CVE-2026-93616
• Check Point — sk1000117 : CVE-2026-85102
• Check Point — sk1000171 : CVE-2026-93616
• CERT-EU — Security Advisory 2026-012, Critical Vulnerabilities in Check Point Products
• Truesec — CVE-2026-85102 & CVE-2026-93616 : Active Exploitation