Check Point CVE-2026-85102 / 85103 : deux failles VPN 9.8 en RCE non authentifiée, exploitation jugée imminente

> En bref : Check Point a corrigé le 9 septembre 2026 deux vulnérabilités critiques dans la façon dont ses pare-feu et consoles gèrent les certificats VPN. CVE-2026-85102 (CVSS 9.8) est un défaut de validation de la confiance des certificats pendant la négociation VPN, permettant potentiellement une exécution de code à distance non authentifiée sur les Security Gateways. CVE-2026-85103 (CVSS 9.8) est un débordement de heap lors du décodage de la structure ASN.1 d'un certificat, touchant les Quantum Security Management et Quantum Security Gateway. Check Point, qui a découvert les failles en interne, indique ne pas avoir de trace d'exploitation — mais le NCSC néerlandais prévient que l'exploitation est imminente. Versions affectées : R82.10 (JHF Take 43 et moins), R82 (Take 125 et moins), R81.20 (Take 165 et moins).

La mécanique : le certificat comme surface d'attaque

Les deux failles se déclenchent pendant le traitement des certificats — une entrée contrôlée par l'attaquant dans les flux VPN. La première fausse la validation de confiance (un certificat malveillant passe pour légitime, avec exécution de code potentielle sur la gateway) ; la seconde corrompt la mémoire au décodage ASN.1 (heap overflow avec le même effet). Deux précisions importantes de Check Point :

Le contexte de l'éditeur presse : en juin, CVE-2026-50751 (contournement d'authentification Remote Access VPN) était déjà exploitée lors de sa divulgation (KEV le 8 juin) ; en juillet, CVE-2026-16232 (SmartConsole) était KEV le jour même. Les failles VPN Check Point ont une histoire : elles se convertissent vite en accès.

Les angles morts de la réponse éditoriale

Le dossier a aussi une valeur d'enseignement opérationnel, rapportée par les clients eux-mêmes sur le forum communautaire : des branches R81.10 sans correctif prévu (mitigation seule, jugée trop vague pour être appliquée), un déploiement Live Patch progressif qui n'avait pas atteint tous les équipements plusieurs jours après l'annonce, des liens de téléchargement cassés, et aucun IoC publié — logique, puisqu'aucun exploit n'existe encore publiquement. Pour vos équipes : ne supposez pas que le correctif est appliqué parce qu'il est disponible ; vérifiez la version effective sur chaque équipement, y compris les lignes secondaires (Spark, management).

Ce qu'il faut faire

La leçon plus large

Les pare-feu et concentrateurs VPN sont la catégorie d'équipement la plus systématiquement convertie en accès initial depuis trois ans (Ivanti, Fortinet, Palo Alto, Citrix, SonicWall, et Check Point à répétition). La raison est structurelle : ils sont exposés par fonction, ils traitent des entrées non authentifiées (certificats, handshakes), et leur compromission livre l'intérieur du réseau. Deux conséquences pour toute organisation : leur cycle de patch doit être le plus court du parc (heures, pas semaines), et l'hypothèse « le VPN peut être compromis » doit exister dans l'architecture — segmentation derrière la gateway, MFA sur les ressources internes, surveillance des comptes qui passent par elle.