Check Point VPN : le client dicte l'authentification (CVE-2026-50751)

Certaines vulnérabilités sont remarquables par leur gravité, d'autres par l'élégance perverse de leur mécanisme. CVE-2026-50751, notée CVSS 9.3, appartient à la seconde catégorie. Documentée par watchTowr Labs et Rapid7, elle permet à un attaquant non authentifié d'établir une session VPN complète sur une passerelle Check Point sans jamais fournir d'identifiant valide. Le principe : le client indique lui-même au serveur avec quelle rigueur vérifier son identité, et le serveur obéit.

Cette faille n'est pas théorique. Elle est activement exploitée depuis au moins le 7 mai 2026, soit plus d'un mois avant la publication du correctif, et figure au catalogue des vulnérabilités activement exploitées de la CISA. Une chaîne de compromission confirmée s'est terminée par le déploiement du rançongiciel Qilin. Pour toute organisation dont l'accès distant repose sur une passerelle Check Point en IKEv1, la priorité est immédiate.

Le mécanisme : quatre octets qui désarment la vérification

La cause racine se situe dans la façon dont les passerelles Check Point traitent la charge Vendor ID nommée VPNExtFeatures lors de l'échange de clés IKEv1. La passerelle lit quatre octets de fin dans cette charge fournie par le client et les écrit directement dans un registre de drapeaux d'authentification, à un décalage interne précis. Le client peut positionner le bit 0x4 pour désactiver la vérification de signature, ou le bit 0x2 pour ignorer entièrement le traitement du certificat. Autrement dit, le paquet du client contient un indicateur, ici la valeur 0x00000004, qui commande au serveur de baisser sa propre garde.

Il s'agit d'un contournement d'authentification, référencé T1190 (Exploit Public-Facing Application) suivi de T1133 (External Remote Services). Point important pour la détection réseau : le contournement fonctionne aussi sur TCP 443 lorsque l'accès UDP est bloqué ou filtré, ce qui élargit la surface d'exposition au delà du port IKE habituel.

Les indicateurs de compromission publiés

Les chercheurs ont publié plusieurs indicateurs exploitables. Côté journaux de la passerelle, la présence de l'entrée « not a Check Point peer » est un marqueur du schéma d'exploitation. Côté réseau, neuf adresses IP sources ont été associées aux attaques :

45.77.149.152
209.182.225.136
38.60.157.139
162.33.177.101
45.76.26.42
144.208.127.155
38.54.88.201
38.54.107.167
66.42.99.200

Deux empreintes MD5 de charges associées ont également été relevées : 52fda5c1b9704544f32ee98d9060e689 et 51d39aa39478beeac94f2d12f682ecce. Un affilié Qilin observé dans une intrusion a utilisé une infrastructure VPS dédiée pour mener l'attaque.

Une règle Suricata sur le Vendor ID malveillant

La signature réseau la plus robuste vise la charge Vendor ID VPNExtFeatures portant le drapeau qui désactive la vérification. watchTowr Labs a d'ailleurs publié un générateur d'artefact de détection pour tester si une passerelle accepte le Vendor ID malveillant. Voici une règle Suricata qui alerte sur le schéma d'exploitation en surveillant le trafic IKE :

alert udp any any -> $HOME_NET 500 (msg:"CheckPoint IKEv1 VPNExtFeatures auth bypass CVE-2026-50751"; \
  content:"|00 00 00 04|"; \
  flow:to_server; \
  threshold:type limit, track by_src, count 1, seconds 60; \
  reference:url,labs.watchtowr.com/marking-your-own-homework-check-point-remote-access-vpn-ikev1-authentication-bypass-cve-2026-50751/; \
  classtype:attempted-admin; sid:2026050751; rev:1;)

Cette règle est un point de départ à affiner selon votre segmentation : le contenu recherché correspond au drapeau qui désactive la vérification. Complétez-la par un jeu de règles bloquant les neuf adresses IP source ci-dessus, et par une surveillance du port 443 sur les passerelles concernées, puisque le contournement y fonctionne aussi.

Le correctif et la mesure structurelle

Check Point a publié un correctif sous la référence sk185033. Au delà du correctif, la mesure de fond est de forcer IKEv2 et d'abandonner IKEv1, protocole déprécié à l'origine de la faille. Si votre déploiement le permet, désactivez IKEv1 sur les passerelles d'accès distant : cela supprime la classe de vulnérabilité entière, pas seulement cette instance. Vérifiez enfin, dans les journaux, l'absence de sessions établies depuis les IP listées avant l'application du correctif, car une session ouverte via ce contournement a pu servir de tête de pont.

Détecter et bloquer une exploitation réseau active demande des signatures à jour et un flux d'indicateurs qualifiés. C'est ce que fournit le feed NIDS ThreatClaw : des règles Suricata construites sur le mécanisme d'exploitation réel, pas seulement sur une liste d'IP éphémères, pour couper l'accès avant que le rançongiciel ne suive.