VPN sous le feu : Check Point (Qilin) et Cisco SD-WAN, deux zero-days exploités en juin 2026

Coup double sur les passerelles d'accès distant : la CVE-2026-50751 (CVSS 9.3) contourne l'authentification des VPN Check Point en IKEv1 et sert déjà au ransomware Qilin, tandis que la CVE-2026-20245 ouvre un accès root sur Cisco Catalyst SD-WAN Manager. Analyse, chaînes d'exploitation et remédiation.

La semaine du 8 juin 2026 aura été brutale pour les équipes réseau. Deux fournisseurs majeurs de l'accès distant d'entreprise — Check Point et Cisco — ont publié coup sur coup des correctifs pour des vulnérabilités déjà exploitées en conditions réelles. Dans les deux cas, le point d'entrée est exactement celui qu'on défend en priorité : la passerelle VPN et le contrôleur SD-WAN, c'est-à-dire la porte d'entrée du réseau et le poste de pilotage de toute l'infrastructure.

Pour un administrateur, ces deux failles partagent une leçon désagréable : appliquer le patch ne suffit pas. Quand un VPN a été contournable pendant des semaines et qu'un opérateur de ransomware était déjà à la manœuvre, le correctif ferme la porte mais ne déloge pas l'intrus déjà entré. Décortiquons les deux dossiers.

Check Point CVE-2026-50751 : le VPN IKEv1 contourné, Qilin à la manœuvre

Le 8 juin 2026, Check Point a publié un hotfix qualifié d'« important » pour une faille d'authentification critique affectant ses passerelles d'accès distant. La CVE-2026-50751, notée CVSS 9.3, est une improper authentication (CWE-287) qui permet d'établir une session VPN sans présenter d'identifiants valides.

La cause racine : un protocole déprécié qu'on n'a jamais éteint

La vulnérabilité ne touche que les configurations qui s'appuient encore sur IKEv1, la première version du protocole d'échange de clés IPsec, dépréciée depuis des années au profit d'IKEv2. Concrètement, une faille logique dans la validation du certificat lors de l'échange de clés IKEv1 permet à un attaquant de négocier une session sans franchir l'étape d'authentification. Sont concernés les déploiements Remote Access VPN et Mobile Access configurés en IKEv1, ainsi que les pare-feux de la gamme Spark.

C'est le scénario classique de la dette technique qui se transforme en surface d'attaque : un protocole legacy laissé actif « au cas où » des clients anciens en auraient besoin, et qui devient le maillon faible. Au passage, les chercheurs ont identifié une seconde faille, la CVE-2026-50752 (CVSS 7.4), permettant une attaque de l'homme du milieu sur les tunnels VPN site-à-site en IKEv1.

Exploitation active : l'empreinte de Qilin

Ce qui rend ce dossier urgent, c'est l'exploitation en cours. Selon les analyses, la faille est exploitée depuis le 7 mai 2026, avec un pic d'activité début juin et plusieurs dizaines d'organisations touchées. L'attribution pointe, avec une confiance moyenne, vers un affilié de Qilin — un ransomware-as-a-service anciennement connu sous le nom d'« Agenda », crédité de plusieurs centaines de victimes.

Le mode opératoire post-exploitation est typique d'un acteur ransomware mature : une fois le tunnel VPN établi sans authentification, exfiltration des données via Rclone et communication de commande et contrôle via le protocole Tox. La CISA a ajouté la CVE-2026-50751 à son catalogue KEV (Known Exploited Vulnerabilities) le jour même, avec une échéance de remédiation au 11 juin pour les agences fédérales américaines — un signal du niveau d'urgence.

Versions affectées et remédiation

Le périmètre couvre plusieurs branches, dont (liste non exhaustive) R82.10, R82, R81.20 sur des niveaux de hotfix inférieurs aux Take corrigés. Quatre branches en fin de support (R80.20, R80.40, R81, R81.10) sont également concernées et ne recevront pas toutes de correctif — une raison de plus de migrer.

Le plan d'action :

  1. Appliquer immédiatement le hotfix (références sk185033 / sk185035 selon la plateforme).
  2. Migrer de IKEv1 vers IKEv2 et désactiver complètement les clients legacy : c'est la vraie correction de fond.
  3. Rendre obligatoire le certificat machine et activer les signatures IPS pertinentes.
  4. Lancer une chasse aux menaces remontant au 7 mai : le patch ne remédie pas à une compromission antérieure. Cherchez les sessions VPN anormales, les traces de Rclone et tout trafic Tox sortant.

Ce dossier rappelle l'importance des fondamentaux que j'évoquais dans mon guide sur les bonnes pratiques de durcissement SSH : désactiver ce qu'on n'utilise pas est aussi important que protéger ce qu'on utilise.

Cisco Catalyst SD-WAN : root sur le contrôleur, sans patch à la divulgation

Quelques jours plus tôt, le 5 juin 2026, Cisco publiait un advisory pour la CVE-2026-20245 (CVSS 7.8), une injection de commandes dans la CLI de Catalyst SD-WAN Manager (et de ses composants Controller et Validator). Un fichier spécialement conçu, uploadé via l'interface, déclenche une exécution de commandes avec les privilèges root en raison d'une validation insuffisante des entrées.

Pourquoi le CVSS 7.8 sous-estime le danger

Pris isolément, le score paraît modéré : l'exploitation requiert des privilèges netadmin authentifiés. Mais c'est en chaîne que cette faille devient dévastatrice. Elle est combinable avec des vulnérabilités antérieures de score maximal :

  • CVE-2026-20127 (CVSS 10.0) : contournement d'authentification permettant d'obtenir un compte netadmin.
  • CVE-2026-20182 (CVSS 10.0) : injection de clé SSH dans le compte vmanage-admin via le démon vdaemon (DTLS/UDP 12346).

La chaîne complète est limpide et catastrophique : accès initial → contournement d'authentification pour obtenir netadmin → CVE-2026-20245 pour passer root → diffusion d'une configuration malveillante vers tous les équipements edge gérés. Autrement dit, compromettre le SD-WAN Manager, c'est compromettre l'ensemble du réseau étendu d'un coup.

Exploitation confirmée, découverte par Mandiant, pas de correctif immédiat

Cisco a confirmé une exploitation en conditions réelles, avec des cas observés de configurations malveillantes poussées vers les équipements edge. La faille a été découverte par les équipes de Google Mandiant, et Cisco Talos relie l'activité à l'acteur suivi sous l'identifiant UAT-8616. Détail aggravant : à la divulgation, il n'existait ni correctif ni contournement pour la CVE-2026-20245 — il s'agit du 7e zero-day SD-WAN de l'année.

En attendant, Cisco recommande d'appliquer les correctifs des failles chaînables déjà disponibles (notamment CVE-2026-20182, corrigée le 14 mai), de durcir les accès, et de collecter un request admin-tech avant toute mise à jour pour préserver les preuves. Côté détection, surveillez /var/log/scripts.log à la recherche d'uploads et d'exécutions de commandes suspectes.

Ce que ces deux failles disent de votre périmètre

Au-delà des numéros de CVE, ces deux dossiers convergent vers un même constat. Les équipements de bordure — VPN, contrôleurs SD-WAN, passerelles — concentrent à la fois le plus de valeur pour un attaquant et le plus de complexité de configuration. Ils sont exposés sur Internet par conception, tournent souvent sur des versions logicielles que personne n'ose mettre à jour de peur de couper l'accès, et embarquent des protocoles legacy activés par défaut.

Trois réflexes à industrialiser :

  • Inventorier et éteindre le legacy. IKEv1, vieux clients VPN, protocoles d'administration obsolètes : si ce n'est pas utilisé, ce doit être désactivé, pas seulement « non configuré ».
  • Traiter le KEV de la CISA comme une file de priorité. Une CVE qui y entre est exploitée maintenant ; l'échéance fédérale est un bon proxy de votre propre urgence.
  • Patcher puis chasser. Pour toute faille exploitée avant la disponibilité du correctif, partez du principe qu'une compromission a pu avoir lieu et menez une investigation rétrospective sur la fenêtre d'exposition.

FAQ

Je suis en IKEv2 sur mes passerelles Check Point, suis-je vulnérable à la CVE-2026-50751 ?

Non. La faille ne concerne que les déploiements Remote Access VPN et Mobile Access configurés en IKEv1, ainsi que les pare-feux Spark. Les configurations exclusivement IKEv2 ne sont pas exposées à ce vecteur. C'est précisément pourquoi la migration vers IKEv2 et la désactivation d'IKEv1 constituent la remédiation de fond recommandée.

Le hotfix Check Point suffit-il à me protéger si j'ai été exposé depuis mai ?

Non. Le correctif ferme la vulnérabilité, mais n'élimine pas un attaquant déjà présent dans le réseau. La faille étant exploitée depuis le 7 mai 2026, toute organisation exposée doit mener une chasse aux menaces couvrant cette fenêtre : sessions VPN anormales, utilisation de Rclone pour de l'exfiltration, trafic de commande et contrôle via le protocole Tox.

Pourquoi la CVE-2026-20245 de Cisco est-elle si dangereuse malgré un CVSS de « seulement » 7.8 ?

Parce que le score isolé ne reflète pas le potentiel de chaînage. Combinée à des bypass d'authentification CVSS 10.0 déjà connus (CVE-2026-20127, CVE-2026-20182), elle permet de passer d'un accès initial à root sur le SD-WAN Manager, puis de pousser une configuration malveillante vers tous les équipements edge. Le risque réel est celui d'une compromission totale du réseau étendu.

Comment détecter une exploitation sur Cisco Catalyst SD-WAN Manager ?

Surveillez /var/log/scripts.log à la recherche d'uploads de fichiers et d'exécutions de commandes inhabituelles. Recherchez également des changements de configuration non planifiés poussés vers les équipements edge. Avant toute mise à jour, collectez un request admin-tech pour préserver l'état du système à des fins d'investigation forensique.

Conclusion

Deux fournisseurs, deux semaines, un même message : la bordure réseau est la ligne de front. La CVE-2026-50751 de Check Point et la CVE-2026-20245 de Cisco ne sont pas des failles théoriques — elles sont exploitées, l'une par un opérateur de ransomware établi, l'autre par un acteur suivi par Mandiant. Dans les deux cas, la valeur défensive ne se joue pas seulement dans la rapidité du patch, mais dans la capacité à éteindre le legacy en amont et à investiguer en aval. Vérifiez vos configurations IKEv1, appliquez les correctifs Cisco chaînables disponibles, et considérez toute fenêtre d'exposition comme une potentielle compromission jusqu'à preuve du contraire.

Cet article vous a plu ?

Commentaires

Morgann Riu

Expert en cybersécurité et administration Linux. J'aide les entreprises à sécuriser et optimiser leurs infrastructures critiques.

Retour au blog

Checklist Sécurité Linux

30 points essentiels pour sécuriser un serveur Linux. Recevez aussi les nouveaux tutoriels par email.

Pas de spam. Désabonnement en 1 clic.