Check Point : CVE-2026-123039 exploitée pour obtenir root et effacer un ESXi
Le CERT-FR alerte sur des correctifs Check Point (CVE-2026-123039 parmi d'autres) ; l'éditeur observe une exploitation active chaînée avec PHP2Shell pour déployer une porte dérobée et un wiper ESXi.
Check Point a publié des correctifs d'urgence pour ses passerelles, et le CERT-FR a relayé l'alerte le 13 novembre. Parmi les failles corrigées, CVE-2026-123039 — une élévation de privilèges vers root dans le processus DynamicCLI de Gaia OS — est activement exploitée. Les attaquants l'enchaînent avec la brèche PHP2Shell pour transformer un web shell en accès root, déployer une porte dérobée, puis dans au moins un cas effacer un hôte VMware ESXi. Si vous opérez des passerelles Check Point, traitez l'appliance comme potentiellement compromise tant que le correctif n'est pas posé.
Produits et correctifs
Selon l'avis CERTFR-2026-AVI-1529, sont concernés : Security Gateway, Security Management, Multi-Domain Security Management, Scalable Platforms et Force Firewalls. L'avis liste trois CVE — CVE-2026-107484, CVE-2026-120490 et CVE-2026-123039 — pour des risques d'élévation de privilèges et de contournement de la politique de sécurité.
Versions correctives :
- Branche 81.x : passer en 81.20 take 174.
- Branche 82.x : passer en 82.20 take 14.
Le CERT-FR renvoie aux bulletins éditeur sk1000291, sk1000362 et sk1000364, tous publiés le 12 novembre 2026.
Statut d'exploitation
D'après le rapport de recherche Check Point, l'accès initial provient de PHP2Shell (CVE-2026-109618 / CVE-2026-109619), corrigée le 21 octobre. CVE-2026-123039 est l'étage d'escalade qui manquait au tableau public : une fois root, les opérateurs déploient la porte dérobée TSGA et TSProxy, décrites comme des variantes d'un framework que Check Point nomme PhiliKit.
- Check Point fait état d'une exploitation active contre une vingtaine de clients, à partir de fin octobre.
- Première vague contre des organisations israéliennes vers le 30 octobre ; seconde vague dès le 2 novembre, répartie sur plusieurs pays, sans secteur privilégié.
- Dans au moins un cas, déplacement latéral vers un hôte VMware ESXi suivi de l'exécution d'un wiper — une intrusion destructrice, pas seulement de l'espionnage.
Check Point rattache PhiliKit au cluster UNC5221, à nexus chinois, connu pour l'exploitation d'Ivanti. À considérer comme l'évaluation de l'éditeur, pas comme un fait établi.
Que faire
- Appliquez le correctif (81.20 take 174 ou 82.20 take 14) et vérifiez que PHP2Shell (CVE-2026-109618 / -109619) est déjà patché : l'escalade n'est utile qu'après le web shell.
- Si le patch doit attendre, la mitigation provisoire de Check Point consiste à arrêter le processus
dynamic_serveret à empêcher son redémarrage. - Chassez la compromission : commandes exécutées hors du wrapper Clish par défaut, usage du sink
system(). Récupérez les IOC depuis le rapport Check Point, sans vous fier à des indicateurs paraphrasés. - Contrôlez votre parc ESXi en cas de signe de foothold PHP2Shell sur une passerelle. Snapshots et sauvegardes immuables comptent ici : l'objectif final était la destruction.
Contexte
Les appliances de sécurité en bordure restent la classe de cibles la plus convoitée : elles terminent la confiance, sont exposées en périmètre et — comme le montre le wiper ESXi — ouvrent une rampe de lancement vers la couche de virtualisation. Un bug PHP2Shell corrigé sans ce correctif d'escalade laisse encore ouverte la moitié dangereuse de la chaîne.