Check Point CVE-2026-85102 et 85103 : failles VPN

Que permettent CVE-2026-85102 et CVE-2026-85103 ?

CVE-2026-85102 : un défaut de validation de la confiance des certificats pendant la négociation VPN peut permettre à un attaquant distant non authentifié d'exécuter du code arbitraire sur la passerelle (CVSS v3.1 9,8).

CVE-2026-85103 : un dépassement de tas lors du décodage de la structure ASN.1 d'un certificat VPN peut permettre l'exécution de code arbitraire sur les systèmes Quantum Security Management et Quantum Security Gateway (CVSS v3.1 9,8). Selon un employé de Check Point cité par The Hacker News, le défaut pourrait en théorie être déclenché sans blade VPN activée, dès lors que des certificats VPN sont présents. Check Point n'a pas détaillé les « conditions spécifiques » requises.

Les deux failles se déclenchent pendant le traitement d'un certificat, une entrée contrôlée par l'attaquant dans les flux VPN. Check Point les a découvertes en interne et a attribué lui-même identifiants et scores.

Quelles versions sont concernées et quels correctifs appliquer ?

Selon les enregistrements CVE : R82.10 avec Jumbo Hotfix jusqu'à la Take 43, R82 jusqu'à la Take 125 et R81.20 jusqu'à la Take 165. D'après BleepingComputer, les correctifs sont :

• Live Patch (Take 24) pour R81.20, R82 et R82.10, déployé automatiquement depuis le 9 septembre pour les clients qui l'utilisent ;
• Jumbo Hotfix : R82.10 Take 44 ou plus, R82 Take 126 ou plus, R81.20 Take 166 ou plus ;
• Spark : R82.00.10 build 2325 ou plus, R81.10.17 build 4968 ou plus.

R82.20 n'est pas concernée. Les branches en fin de support (R80 à R80.40, R81, R81.10) sont exposées sans correctif ; des clients ont signalé qu'aucun correctif ni Live Patch n'existe pour R81.10, seulement une mitigation jugée vague. Les avis sont sk1000117 et sk1000118.

Quel est l'état de l'exploitation ?

Le 9 septembre, Check Point indiquait n'avoir aucune trace d'exploitation et n'avoir publié aucun indicateur de compromission. Le NCSC néerlandais a ensuite prévenu qu'il s'attendait à des tentatives d'exploitation rapides, sans preuve de concept publique à cette date. La NVD indique que CVE-2026-85102 a été ajoutée au KEV de CISA le 22 septembre 2026, ce qui signale une exploitation constatée. Les failles VPN Check Point précédentes (CVE-2026-50751 en juin, CVE-2026-16232 en juillet) avaient aussi été inscrites au KEV.

Comment vérifier et détecter ?

1. Relevez la version effective de chaque passerelle et console (niveau de Jumbo Hotfix réellement installé, pas celui prévu), y compris les gammes Spark et les serveurs de gestion.
2. Vérifiez le Live Patch : l'avis précise qu'il ne couvre que R81.20, R82 et R82.10 et pas toutes les configurations.
3. Inventoriez les certificats VPN présents sur les équipements, y compris sur des passerelles dont le VPN semble inactif.
4. Journalisez et alertez sur les échecs de négociation VPN et sur les tentatives de connexion avec des certificats mal formés.
5. Cherchez des signes de compromission sur les passerelles : processus inattendus, nouveaux comptes administrateur, connexions sortantes inhabituelles.

Comment corriger ?

Appliquez le correctif par la voie la plus rapide disponible : Live Patch ou le dernier Jumbo Hotfix. Pour les branches sans correctif, réduisez l'exposition : pour la fonction VPN de site à site, restreignez les règles à des adresses de confiance, limitez les sources autorisées et planifiez la migration vers une branche prise en charge. Après toute exposition d'une passerelle avant correctif, faites tourner les secrets qui y transitent (clés prépartagées, comptes d'administration, certificats).

Que change l'accès d'un agent IA à un VPN ou à une passerelle ?

Beaucoup d'agents et d'outils MCP tournent derrière le VPN avec l'hypothèse implicite que « le réseau interne est de confiance » : pas d'authentification sur le serveur d'outils, jetons à longue durée, accès à des bases et API internes. Une passerelle compromise rend cette hypothèse fausse en un instant : l'attaquant arrive sur le même réseau que les outils de l'agent et peut les appeler directement, ou modifier ce que l'agent lit (OWASP LLM01, LLM06). Voir la sécurité MCP.

Deux effets complémentaires. L'authentification par certificat s'étend aux machines et aux agents (TLS mutuel entre un agent et ses outils) : un défaut de traitement des certificats est donc un risque pour cette couche. Et la dépendance : un agent dont l'accès passe par une passerelle indisponible ou en cours de correction échoue de façon imprévisible ; testez le mode dégradé. Les contrôles utiles : authentification propre à chaque outil, quel que soit le réseau, jetons courts, segmentation derrière la passerelle, journalisation des appels d'outil et validation humaine des actions sensibles. Voir la sécurité des agents IA et l'article sur Citrix NetScaler.

Comment réduire le risque quand le correctif ne peut pas être appliqué tout de suite ?

Limitez les sources autorisées sur les règles VPN aux adresses de confiance, retirez les services VPN inutilisés, activez la journalisation détaillée des négociations et surveillez les redémarrages inattendus de processus VPN. Préparez le retour arrière du correctif, documentez les équipements sur branches non couvertes avec une date de migration et affectez un responsable à chacun. Une mitigation partielle appliquée aujourd'hui vaut mieux qu'un correctif parfait appliqué dans trois semaines.

Comment tester son agent sur Check Point CVE-2026-85102 et 85103 ?

Un test de red team d'agent part de l'hypothèse d'un attaquant déjà présent sur le réseau interne et vérifie ce que les outils de l'agent acceptent sans authentification, quels jetons sont réutilisables et ce qu'une instruction détournée peut atteindre. Le Red Team Agent Express (1 900 €, 5 jours) regarde ce qu'un agent derrière un VPN Check Point vulnérable peut atteindre. La méthode détaille la démarche.

Quelle leçon en tirer ?

Les passerelles VPN et pare-feu sont exposés par fonction et traitent des entrées non authentifiées : leur cycle de correctifs doit être le plus court du parc, et l'architecture doit supposer qu'elles peuvent être compromises, avec segmentation, authentification des services internes et surveillance des comptes qui y passent.