Check Point corrige deux failles VPN de gravité 9,8 permettant une exécution de code non authentifiée

Check Point a publié le 9 septembre des mises à jour d'urgence pour deux vulnérabilités critiques dans le traitement des certificats de ses produits VPN, des failles qui permettraient à un attaquant non authentifié d'exécuter du code sur un pare-feu ou un serveur de gestion situé à la périphérie d'un réseau d'entreprise.

À lire aussi: WordPress corrige Comment2Shell, une faille dans les commentaires menant à la prise de contrôle du serveur · Oracle publie 673 correctifs de sécurité, dont six failles de sévérité maximale.

Les deux failles portent un score CVSS de 9,8, la note de gravité maximale, et peuvent toutes deux être déclenchées à distance sans identifiants. La première, suivie sous la référence CVE-2026-85102, est une validation incorrecte des données de certificat lors de la négociation VPN. La seconde, CVE-2026-85103, est un débordement de tampon dans le tas lors du décodage ASN.1 des certificats VPN. Check Point a publié les avis sk1000117 et sk1000118, et le CERT-EU de l'Union européenne a émis sa propre alerte.

Les produits concernés sont Check Point Security Gateway, Security Management Server et Spark Firewall, sur les branches R81.20, R82 et R82.10 configurées pour l'accès VPN à distance (Remote Access VPN) ou le VPN site à site. Check Point précise que la branche plus récente R82.20 n'est pas touchée. Parce que ces équipements gèrent les règles de pare-feu et terminent les tunnels VPN, une compromission réussie n'expose pas seulement un appareil : elle peut offrir à un attaquant un point d'ancrage à la périphérie du réseau et un chemin vers les systèmes internes et la console de gestion qui contrôle toutes les passerelles du parc.

Pourquoi l'analyse des certificats est le point faible

Les deux failles se situent dans la partie de la poignée de main VPN qui s'exécute avant que l'identité de l'utilisateur soit vérifiée. Pour établir un tunnel, la passerelle doit analyser et valider un certificat présenté par l'autre partie. Cette analyse intervient tôt, sur un port réseau accessible, exactement la combinaison que les attaquants recherchent dans un équipement exposé à internet.

Dans CVE-2026-85102, la passerelle ne parvient pas à établir correctement la confiance dans un certificat présenté, ce qui permet à un attaquant non authentifié de pousser la négociation assez loin pour exécuter du code. Dans CVE-2026-85103, un certificat spécialement conçu corrompt la mémoire du tas à l'intérieur du décodeur ASN.1, donnant à l'attaquant le contrôle de l'exécution à la fois sur les Security Gateways et les Security Management Servers. Armis, qui suit la seconde faille, indique que les versions vulnérables sont R82.10 avec Jumbo Hotfix Take 43 ou antérieur, R82 avec Take 125 ou antérieur, et R81.20 avec Take 165 ou antérieur.

La distinction entre les deux importe pour les administrateurs. CVE-2026-85102 touche les Security Gateways et les Spark Firewalls utilisés pour le VPN. CVE-2026-85103 atteint aussi le plan de gestion, ce qui signifie qu'un seul certificat malformé pourrait compromettre la console qui déploie les règles sur l'ensemble des pare-feu d'une organisation.

Qui est exposé, et à quelle urgence

Check Point indique que les deux vulnérabilités ont été découvertes en interne et qu'elle n'a aucun signe d'exploitation. L'entreprise précise aussi qu'aucun code de preuve de concept public n'existait au moment de la divulgation. C'est une position de départ, pas une situation définitive.

Le Centre national de cybersécurité des Pays-Bas a jugé élevées la probabilité d'exploitation et l'impact potentiel, et a déclaré le 10 septembre s'attendre à voir des tentatives d'exploitation prochainement. Le raisonnement est classique pour cette catégorie de faille : une exécution de code à distance non authentifiée et accessible à distance dans un équipement de périmètre attire les groupes de rançongiciels et les acteurs liés à des États, et l'histoire montre que la fenêtre entre divulgation et exploitation est courte. La faille de traversée de chemin de GitLab, corrigée le lendemain de la mise à jour de Check Point, était déjà sondée en quelques heures, rappel de la rapidité du cycle de balayage.

Check Point a découvert les deux problèmes elle-même. C'est bon signe pour les tests internes de l'entreprise, mais cela signifie aussi que le public n'a pas eu l'occasion d'évaluer indépendamment la difficulté de déclenchement des failles, et qu'aucune preuve de concept n'a circulé pour permettre aux défenseurs de tester leur propre exposition.

Versions corrigées et contournements

Pour les branches prises en charge, les états corrigés sont R82.10 Jumbo Hotfix Take 44 ou ultérieur, R82 Take 126 ou ultérieur, et R81.20 Take 166 ou ultérieur. Les correctifs de Spark Firewall sont inclus dans R82.00.10 Build 2325 ou ultérieur et R81.10.17 Build 4968 ou ultérieur. Les clients ayant activé Check Point LivePatch devraient recevoir les correctifs automatiquement ; l'entreprise a lancé le déploiement de LivePatch le 9 septembre. Les administrateurs qui n'ont pas vérifié que le correctif s'est réellement installé ne doivent pas présumer que la voie automatique a fonctionné, et doivent comparer l'état du hotfix installé ou de LivePatch avec l'avis.

Lorsqu'une correction immédiate est impossible, Check Point recommande une réduction temporaire de l'exposition pour le VPN site à site : désactiver les règles implicites du VPN et définir manuellement un accès VPN pour le port UDP 500 et le port UDP 4500, limité à des adresses IP homologues précises. L'entreprise avertit que cette atténuation ne s'applique pas à l'accès VPN à distance et qu'il n'existe pas de contournement pour les instances Spark Firewall gérées localement, qui doivent être corrigées dès que possible.

Ces restrictions sont une solution provisoire, pas un correctif. Toute adresse homologue encore autorisée à joindre le port VPN peut toujours transmettre le certificat malformé, de sorte que restreindre la liste blanche réduit la surface d'attaque sans éliminer la vulnérabilité.

Le schéma plus large

La divulgation de Check Point intervient dans un mois chargé pour la sécurité du périmètre réseau. Cisco Talos a rapporté que trois groupes de menaces distincts avaient exploité deux failles du Secure Firewall Management Center, dont un contournement d'authentification de gravité maximale, l'un des groupes étant lié à des affiliés du rançongiciel Qilin et un autre à un groupe dont l'outillage recoupe celui de l'APT Sandworm. La CISA a ajouté cinq autres failles activement exploitées à son catalogue des vulnérabilités exploitées connues, concernant JFrog Artifactory, ConnectWise ScreenConnect et MikroTik RouterOS. Et la faille de traversée de chemin de GitLab, notée CVSS 10,0, était sondée dans le jour suivant son correctif.

Pris ensemble, le schéma est familier : les équipements sur lesquels les organisations s'appuient pour faire respecter la confiance à la périphérie du réseau deviennent eux-mêmes la cible, parce qu'en compromettre un ouvre l'accès à tout ce qui se trouve derrière. Les concentrateurs VPN sont particulièrement précieux parce qu'ils sont exposés à l'internet public par conception et parce que leurs utilisateurs s'attendent à pouvoir les joindre.

Comment les attaquants repèrent les passerelles exposées

Le risque concret d'une faille comme celle-ci dépend moins de son score CVSS que du nombre d'appareils touchés joignables depuis internet et de la vitesse d'apparition d'un exploit. Ces deux conditions tendent à favoriser l'attaquant. Les services de balayage à l'échelle d'internet indexent en continu les portails VPN, et une passerelle qui affiche son fournisseur et sa version sur une page de connexion est facile à recenser. Une fois un correctif publié, ces mêmes services permettent à un attaquant de filtrer les appareils non corrigés, et l'écart entre divulgation et armement se mesure souvent en jours.

Les équipements de périmètre sont devenus un vecteur d'accès initial privilégié pour cette raison. Ces dernières années ont vu des campagnes soutenues contre les VPN et les appareils de bord d'Ivanti, Fortinet, Citrix, Palo Alto Networks et Cisco, les groupes étatiques et les affiliés de rançongiciels y voyant tous un moyen d'entrer dans des réseaux autrement bien défendus. Une compromission réussie d'un serveur de gestion est pire encore : elle peut donner à un attaquant la capacité de pousser des règles, d'approuver de nouveaux certificats et d'atteindre toutes les passerelles contrôlées par le serveur.

La mise à jour de ces appareils est plus difficile qu'il n'y paraît. Ils se trouvent dans des environnements à changement contrôlé où toute interruption exige une fenêtre de maintenance, ils fonctionnent souvent par paires de haute disponibilité qui doivent être mises à jour une par une, et beaucoup sont gérés localement par des équipes régionales sans inventaire central. Les équipements produisent aussi bien moins de télémétrie de sécurité que les postes de travail, de sorte qu'une intrusion peut laisser peu de traces évidentes. Le propre conseil de Check Point de vérifier que le LivePatch automatique s'est réellement installé témoigne de la fréquence avec laquelle une affirmation de mise à jour signifie simplement que la mise à jour a été programmée.

La combinaison d'une valeur élevée, d'un armement rapide et d'une remédiation lente explique pourquoi les régulateurs et les entreprises de réponse à incident traitent les vulnérabilités de bord comme urgentes avant même que l'exploitation soit confirmée. Pour les attaquants, une passerelle non corrigée est souvent le chemin le moins coûteux vers un point d'ancrage, et pour les défenseurs, c'est fréquemment le dernier appareil dont on se souvient de faire la mise à jour.

Que faire

Les clients de Check Point doivent inventorier leurs passerelles, serveurs de gestion et équipements Spark, noter la version exacte et le Take de hotfix installé, et vérifier dans les avis du fournisseur si chaque appareil est touché. Les appareils sur un Take corrigé doivent être documentés comme remédiés. Les appareils sur un Take affecté, avec LivePatch non confirmé comme installé, doivent être mis à jour via le chemin Jumbo Hotfix pris en charge pour leur branche.

À plus long terme, l'épisode renforce l'idée de limiter ce qu'un équipement VPN est autorisé à exposer. Restreindre les interfaces de gestion à un réseau isolé, imposer l'authentification multifacteur même lorsque des certificats sont utilisés, et surveiller les erreurs d'analyse de certificats pour détecter des tentatives de sondage réduisent tous le rayon d'impact en cas de correctif tardif. Aucun de ces contrôles ne remplace la mise à jour d'un équipement présentant une faille de pré-authentification notée 9,8. Mais ce sont eux qui transforment une brèche de périmètre en incident circonscrit plutôt qu'en incident à l'échelle du réseau.

L'action immédiate est peu glamour et urgente : corriger, vérifier que le correctif est installé, et ne pas attendre l'apparition d'une preuve de concept pour traiter les failles comme urgentes.