Une vulnérabilité critique affectant un plugin déployé dans des environnements cPanel fait désormais l’objet d’une exploitation active confirmée. Le signal le plus important n’est pas uniquement la publication d’un correctif ou d’un avis éditeur : la faille a été ajoutée au catalogue Known Exploited Vulnerabilities de la CISA, ce qui change immédiatement la priorité opérationnelle pour les hébergeurs, infogéreurs, administrateurs Linux et équipes sécurité. Lorsqu’une entrée rejoint le KEV, cela signifie que des attaques réelles ont été observées et que la fenêtre entre exposition et compromission tend à se réduire fortement.

Selon l’alerte relayée par BleepingComputer, la CISA a demandé aux agences fédérales américaines de corriger sous quatre jours une faille touchant un plugin utilisé avec cPanel. Pour les opérateurs privés, notamment ceux qui administrent des serveurs mutualisés, des VPS ou des infrastructures d’hébergement chez OVH, o2switch, Scaleway ou en datacenter interne, l’enjeu est identique : identifier rapidement les systèmes exposés, confirmer la présence du composant vulnérable, appliquer le correctif disponible et réduire l’accessibilité du panneau d’administration tant que la remédiation complète n’est pas effective.

Le risque est particulièrement élevé sur les serveurs où cPanel & WHM est accessible depuis Internet sans filtrage d’IP, MFA strict ni segmentation d’administration. Une faille dans un plugin ou un composant intégré au panneau d’administration peut conduire, selon le cas, à une exécution de code, une élévation de privilèges, une prise de contrôle du compte administrateur ou l’implantation d’une porte dérobée sur l’hôte. Sur des plateformes d’hébergement, l’impact ne se limite pas au serveur de gestion : il peut s’étendre aux comptes clients, aux bases de données, aux boîtes mail, aux sauvegardes et aux secrets présents sur la machine.

La source initiale mentionnée par BleepingComputer s’appuie sur l’avis de la CISA relatif à son catalogue KEV. L’avis officiel de la CISA et l’advisory de l’éditeur du plugin concerné doivent être considérés comme les références prioritaires pour confirmer le CVE-ID, les versions exactes touchées et les builds corrigés. En l’absence d’un environnement homogène, il faut partir du principe que tout serveur cPanel exposé à Internet et utilisant ce plugin est à vérifier en urgence. Si un score CVSS est publié dans l’avis éditeur ou dans le NVD, il doit être utilisé comme base de qualification, mais l’ajout au KEV prime déjà sur la seule sévérité théorique : une faille activement exploitée mérite un traitement accéléré, même si les contraintes de production rendent le patching délicat.

Pour les équipes francophones, il est utile d’aligner cette alerte avec les pratiques de réponse habituelles recommandées par le CERT-FR : inventaire, qualification de l’exposition, réduction de surface d’attaque, collecte d’indices de compromission, patch, puis revue post-incident. Sur des infrastructures cPanel, cela implique aussi de distinguer les accès WHM, Webmail et cPanel, les proxys inverses éventuels, les ACL réseau et les modules tiers installés au fil du temps par l’infogérance ou l’hébergeur.

Versions affectées

Le point de vigilance principal est de ne pas raisonner uniquement en version globale de cPanel & WHM. L’alerte vise un plugin ou composant additionnel utilisé dans l’écosystème cPanel, avec un cycle de mise à jour potentiellement distinct du panneau principal. Il faut donc vérifier à la fois la version de cPanel et celle du plugin concerné.

Les informations exactes à confirmer dans l’avis officiel de l’éditeur sont les suivantes :

  • CVE-ID : à confirmer dans l’advisory éditeur et l’entrée CISA KEV correspondante.
  • CVSS : à confirmer dans le bulletin officiel ou le NVD si déjà enrichi.
  • Versions vulnérables : toutes les versions du plugin antérieures au build corrigé indiqué par l’éditeur.
  • Versions corrigées : la première version incluant le correctif de sécurité, ou le hotfix spécifique si l’éditeur a publié un patch hors cycle.
  • Canaux impactés : installations manuelles, images préconfigurées, templates d’hébergement, appliances ou environnements gérés par un prestataire.

Sur le plan opérationnel, les serveurs à auditer en priorité sont :

  • les hôtes exposant WHM sur 2087/tcp ou 2086/tcp directement sur Internet ;
  • les hôtes exposant cPanel sur 2083/tcp ou 2082/tcp sans filtrage d’IP ;
  • les serveurs mutualisés ou revendeurs où plusieurs administrateurs délèguent l’installation de plugins ;
  • les nœuds d’hébergement administrés par une infogérance externe avec historique d’extensions installées hors dépôt standard ;
  • les environnements clonés depuis des snapshots ou templates anciens, susceptibles d’avoir conservé une version vulnérable du plugin.

La vérification doit couvrir les emplacements usuels de composants et d’extensions cPanel, par exemple :

  • /usr/local/cpanel/
  • /var/cpanel/
  • /usr/local/cpanel/whostmgr/docroot/cgi/
  • /usr/local/cpanel/base/frontend/
  • /var/cpanel/apps/

Selon le plugin concerné, il peut être enregistré comme application WHM, module Perl, script CGI, composant PHP, binaire auxiliaire ou intégration tierce. Une simple vérification de la version de cPanel via /usr/local/cpanel/cpanel -V ne suffit donc pas.

Exemples de commandes utiles pour inventorier un serveur :

/usr/local/cpanel/cpanel -V rpm -qa | grep -i cpanel find /usr/local/cpanel /var/cpanel -maxdepth 4 -type f | grep -Ei 'plugin|addon|extension|whm|cgi' grep -Rin "version" /usr/local/cpanel /var/cpanel 2>/dev/null | head -100

Sur des flottes importantes, il est recommandé de centraliser cette recherche via Ansible, Salt, Rundeck ou un EDR disposant d’une capacité d’inventaire fichier/package. Pour les hébergeurs, la priorité doit aller aux serveurs en frontal public et aux nœuds administrant plusieurs centaines ou milliers de comptes clients.

Vecteur d'attaque

L’intérêt offensif d’une faille touchant un plugin de cPanel est évident : le panneau concentre des privilèges élevés et donne accès à des fonctions structurantes du serveur. Selon la nature exacte de la vulnérabilité, l’attaquant peut viser l’interface d’administration, une route HTTP exposée, un endpoint AJAX, un script CGI, un mécanisme d’import ou une fonction backend appelée avec des privilèges supérieurs.

Dans un scénario classique, le vecteur d’attaque suit l’une des chaînes suivantes :

  • Accès non authentifié à une fonctionnalité du plugin exposée via une route web mal protégée ;
  • Contournement d’authentification ou de contrôle d’accès dans l’interface WHM ;
  • Injection de commande dans un paramètre transmis à un script shell ou à un wrapper système ;
  • Upload de fichier arbitraire conduisant à une webshell ou à un implant persistant ;
  • Exécution de code à distance via désérialisation, appel système non filtré, template injection ou mauvaise validation d’entrée ;
  • Élévation de privilèges locale après compromission d’un compte limité du panneau.

Sur un serveur d’hébergement, l’impact concret est souvent supérieur à celui d’une application web classique. Un accès administrateur à WHM permet potentiellement de :

  • créer ou modifier des comptes d’hébergement ;
  • déployer des tâches planifiées malveillantes ;
  • consulter ou remplacer des certificats TLS ;
  • modifier des zones DNS ;
  • accéder aux boîtes mail et paramètres de routage ;
  • extraire des sauvegardes ;
  • poser une persistance dans les hooks cPanel ou les scripts de maintenance.

Le fait que la CISA ait ajouté la faille au KEV indique qu’il ne s’agit plus d’un risque théorique. Pour un administrateur, cela change la séquence de décision : il ne faut plus attendre la prochaine fenêtre de maintenance hebdomadaire si le serveur est exposé et si le plugin est présent. La probabilité d’exploitation opportuniste augmente généralement dès la publication d’un PoC, d’un diff de patch ou d’une simple annonce relayée dans la presse spécialisée.

Un point souvent sous-estimé concerne les interfaces cPanel placées derrière un reverse proxy ou un CDN. Même si l’origine n’est pas directement visible, des erreurs de configuration peuvent laisser les ports d’administration accessibles, ou exposer des routes internes via des ACL incomplètes. Les attaquants testent régulièrement :

  • les ports 2082, 2083, 2086, 2087, 2095, 2096 ;
  • les chemins spécifiques au plugin sous /cgi/, /json-api/ ou /execute/ ;
  • les hôtes d’administration oubliés dans le DNS public ;
  • les certificats révélant des noms d’hôtes de management ;
  • les bannières TLS ou HTTP permettant d’identifier cPanel.

Exemple de surface d’exposition à rechercher dans les journaux ou scans internes :

nmap -Pn -p 2082,2083,2086,2087,2095,2096 server.example.net curl -kI https://server.example.net:2087/ ss -lntp | grep -E '2082|2083|2086|2087|2095|2096'

Si le plugin vulnérable est lié à une fonction d’administration ou d’automatisation, l’exploitation peut être très rapide après découverte. Dans un contexte mutualisé, un attaquant peut utiliser le serveur compromis comme pivot pour déposer des scripts dans plusieurs comptes web, détourner des redirections mail, exfiltrer des bases de données ou distribuer du phishing via des domaines légitimes déjà configurés.

Un scénario d’attaque réaliste pour un infogéreur peut ressembler à ceci :

  • scan Internet des ports d’administration cPanel ;
  • détection d’un hôte exposant la signature du plugin vulnérable ;
  • appel de l’endpoint affecté avec une charge forgée ;
  • obtention d’une exécution de commande sous le contexte du service web ou d’un composant privilégié ;
  • dépose d’un script de persistance dans /etc/cron.d/, /root/.ssh/authorized_keys ou un hook cPanel ;
  • vol de secrets dans /root/.my.cnf, /var/cpanel/ ou les fichiers de configuration applicatifs ;
  • mouvement latéral vers les comptes hébergés et les services de messagerie.

Le danger spécifique des environnements d’hébergement est la densité de données et de secrets sur un seul hôte. Là où une compromission d’application web touche un service, une compromission du panneau d’administration peut toucher une grappe entière de services clients.

Impact

L’impact exact dépendra de la primitive offerte par la faille, mais l’ajout au catalogue KEV justifie de la traiter comme un incident potentiel de compromission serveur. Les conséquences les plus probables sont :

  • prise de contrôle du panneau d’administration et création de comptes malveillants ;
  • exécution de code sur l’hôte avec accès à des secrets sensibles ;
  • compromission de comptes clients en environnement mutualisé ;
  • altération des configurations DNS, mail ou TLS pour faciliter phishing et interception ;
  • déploiement de malwares, webshells, mineurs ou proxys abusifs ;
  • persistance discrète via cron, hooks cPanel, services systemd ou clés SSH ;
  • exfiltration de données applicatives, boîtes mail, sauvegardes et identifiants.

Pour les RSSI, le point clé est la criticité métier. Un serveur cPanel n’est pas un simple nœud Linux : il porte souvent la relation client, les noms de domaine, la messagerie, les certificats et l’administration de dizaines à milliers de sites. Une exploitation peut donc provoquer :

  • rupture de service multi-clients ;
  • défiguration ou injection SEO à grande échelle ;
  • émission d’e-mails malveillants depuis une infrastructure légitime ;
  • atteinte à l’intégrité des sauvegardes ;
  • obligations de notification en cas de fuite de données.

Le passage au KEV modifie aussi la gouvernance du patching. Dans de nombreuses organisations, un correctif critique peut encore attendre une validation CAB ou une fenêtre de changement. En revanche, une faille activement exploitée sur une interface d’administration Internet-facing doit basculer dans un régime de traitement accéléré, avec arbitrage sécurité/production explicite. Pour les prestataires d’infogérance, il est prudent de documenter immédiatement :

  • la liste des serveurs exposés ;
  • la présence ou non du plugin ;
  • la version installée ;
  • la date de patch ou les mesures compensatoires appliquées ;
  • les éléments de journalisation conservés pour investigation.

Comment patcher

La remédiation prioritaire consiste à appliquer la version corrigée du plugin indiquée dans l’advisory officiel de l’éditeur, puis à vérifier que le service cPanel/WHM recharge bien les composants mis à jour. La source originale à consulter est l’avis éditeur du plugin concerné, complété par l’entrée correspondante dans le catalogue KEV de la CISA. Si le composant a été installé via un paquet RPM, un installateur shell ou un dépôt tiers, la procédure diffère légèrement.

Avant toute mise à jour :

  • prendre un snapshot ou une sauvegarde cohérente du serveur ;
  • exporter la configuration du plugin si possible ;
  • noter la version actuelle ;
  • préparer un redémarrage contrôlé des services d’administration si requis.

Vérification de version et mise à jour cPanel de base :

/usr/local/cpanel/cpanel -V /usr/local/cpanel/scripts/upcp --force

Si le plugin est distribué sous forme de paquet RPM, rechercher puis mettre à jour le paquet concerné :

rpm -qa | grep -i '<nom-du-plugin>' dnf update '<nom-du-plugin>' yum update '<nom-du-plugin>'

Sur des distributions récentes compatibles dnf, privilégier dnf. Sur des systèmes plus anciens encore présents chez certains hébergeurs, yum peut rester l’outil disponible. Si le plugin provient d’un dépôt tiers, vérifier que ce dépôt est toujours légitime et à jour avant installation. Une mise à jour via dépôt non maîtrisé sur un serveur compromis est risquée.

Si le plugin a été installé manuellement par script ou archive, il faut suivre la procédure éditeur. Le schéma typique ressemble à :

cd /root curl -O https://vendor.example.tld/downloads/<plugin>-<fixed-version>.tar.gz tar xzf <plugin>-<fixed-version>.tar.gz cd <plugin>-<fixed-version> ./install.sh

Après installation, redémarrer ou recharger les composants cPanel si l’éditeur l’exige :

/usr/local/cpanel/scripts/restartsrv_cpsrvd systemctl restart cpanel.service systemctl restart httpd systemctl restart nginx

La commande exacte dépendra de l’architecture du serveur et de la manière dont l’interface est servie. Sur cPanel, le service critique pour l’interface est souvent cpsrvd. Si un reverse proxy local est en place, un redémarrage de httpd ou nginx peut aussi être nécessaire.

Vérifications post-patch à réaliser systématiquement :

  • contrôler la version effective du plugin dans l’interface et sur disque ;
  • tester l’accessibilité normale du panneau d’administration ;
  • vérifier l’absence d’erreurs dans /usr/local/cpanel/logs/error_log ;
  • contrôler les journaux système et web après redémarrage ;
  • rejouer si possible un test de validation interne sur l’endpoint vulnérable.

Exemples de vérification :

grep -i '<nom-du-plugin>' /usr/local/cpanel/logs/error_log tail -n 100 /usr/local/cpanel/logs/access_log tail -n 100 /var/log/messages curl -kI https://127.0.0.1:2087/

En environnement de flotte, il est recommandé de consigner le patching dans un tableau de suivi avec :

  • nom d’hôte ;
  • IP publique ;
  • présence du plugin ;
  • version avant correction ;
  • version après correction ;
  • date/heure de remédiation ;
  • indicateurs de compromission trouvés ou non.

Si le serveur est géré chez un hébergeur français avec offre managée ou support d’infogérance, il faut aussi vérifier si le plugin est intégré à une image standard de l’hébergeur ou déployé par un partenaire. Dans ce cas, la remédiation doit être coordonnée pour éviter qu’un mécanisme d’automatisation réinstalle une version vulnérable lors d’un reprovisionnement.

Mitigation

Lorsqu’un patch ne peut pas être appliqué immédiatement, il faut réduire la surface d’attaque sans attendre. Ces mesures ne remplacent pas la mise à jour, mais peuvent limiter l’exposition durant quelques heures ou quelques jours.

1. Restreindre l’accès réseau au panneau

La mesure compensatoire la plus efficace consiste à limiter l’accès à WHM et cPanel à des IP d’administration connues via pare-feu, ACL fournisseur ou VPN. Sur un serveur Linux, cela peut se faire avec firewalld, iptables ou la solution de filtrage déjà déployée.

firewall-cmd --permanent --add-rich-rule='rule family="ipv4" source address="203.0.113.10/32" port protocol="tcp" port="2087" accept' firewall-cmd --permanent --add-rich-rule='rule family="ipv4" port protocol="tcp" port="2087" drop' firewall-cmd --reload

Exemple minimal avec iptables :

iptables -A INPUT -p tcp -s 203.0.113.10 --dport 2087 -j ACCEPT iptables -A INPUT -p tcp --dport 2087 -j DROP service iptables save

Le même principe doit être appliqué à 2083, 2086, 2082, 2095 et 2096 si ces ports sont exposés. Pour les hébergeurs, placer l’administration derrière un VPN ou un bastion reste la meilleure pratique.

2. Désactiver temporairement le plugin vulnérable

Si l’éditeur documente une procédure de désactivation sans impact critique, il faut la privilégier jusqu’au patch. Selon l’implémentation, cela peut consister à renommer un répertoire, désenregistrer une app WHM ou retirer un fichier de configuration.

mv /usr/local/cpanel/whostmgr/docroot/cgi/<plugin> /usr/local/cpanel/whostmgr/docroot/cgi/<plugin>.disabled /usr/local/cpanel/scripts/restartsrv_cpsrvd

Cette approche doit être testée avec prudence, surtout sur des serveurs de production mutualisés. Une désactivation brutale peut casser des workflows d’administration ou des intégrations de facturation.

3. Renforcer l’authentification et l’exposition

  • activer le MFA pour tous les comptes administrateurs WHM ;
  • supprimer ou suspendre les comptes admin non utilisés ;
  • interdire l’accès direct depuis Internet si un bastion est disponible ;
  • désactiver les accès root par mot de passe si SSH est encore configuré ainsi ;
  • vérifier les ACL de reverse proxy et de CDN.

Ces mesures ne bloquent pas une exploitation non authentifiée, mais réduisent les voies de compromission secondaire et la persistance.

Détection

Étant donné l’exploitation active, la détection doit être menée en parallèle du patching. Le but n’est pas seulement de voir si le serveur est vulnérable, mais de déterminer s’il a déjà été touché.

Journaux à examiner en priorité :

  • /usr/local/cpanel/logs/access_log
  • /usr/local/cpanel/logs/error_log
  • /var/log/secure ou /var/log/auth.log
  • /var/log/messages ou /var/log/syslog
  • journaux httpd ou nginx si un proxy frontal est utilisé
  • logs du WAF ou du fournisseur réseau

Indicateurs de compromission à rechercher :

  • requêtes inhabituelles vers les routes du plugin ou de WHM depuis des IP inconnues ;
  • pics de requêtes sur 2087 ou 2083 ;
  • codes HTTP atypiques suivis d’une connexion administrateur réussie ;
  • création de comptes administrateurs ou modification de comptes existants ;
  • fichiers récemment créés dans /tmp, /var/tmp, /dev/shm ;
  • tâches cron inattendues ;
  • clés SSH ajoutées dans /root/.ssh/authorized_keys ;
  • binaires ou scripts inconnus dans les répertoires du plugin ;
  • processus enfants anormaux lancés par les services cPanel.

Exemples de commandes de triage :

grep -Ei '2087|2083|<nom-du-plugin>|/cgi/|/json-api/|/execute/' /usr/local/cpanel/logs/access_log | tail -200 find /tmp /var/tmp /dev/shm -type f -mtime -7 -ls crontab -l ls -la /etc/cron.d /etc/cron.daily /var/spool/cron ls -la /root/.ssh/ ps fauxwww ss -plant

Pour vérifier les modifications récentes dans les zones sensibles :

find /usr/local/cpanel /var/cpanel /etc -type f -mtime -7 | sort rpm -Va last -a lastlog

Sur un serveur potentiellement compromis, il faut aussi examiner :

  • les redirections mail et alias créés récemment ;
  • les certificats TLS ajoutés ou remplacés ;
  • les zones DNS modifiées ;
  • les hooks cPanel personnalisés ;
  • les comptes FTP, API tokens et accès SSH créés récemment.

Dans les cas les plus sensibles, notamment chez les hébergeurs et MSP, il peut être nécessaire de sortir le serveur du trafic d’administration, de prendre une image disque ou un snapshot pour investigation, puis de faire une revue d’intégrité avant remise en production. Si des indices de compromission sont confirmés, un simple patch n’est pas suffisant : il faut traiter l’événement comme un incident de sécurité complet, avec rotation des secrets, révision des accès et contrôle des sauvegardes.

Les équipes disposant d’un SIEM peuvent créer des règles de détection temporaires sur :

  • toute requête vers les routes du plugin depuis une IP jamais vue ;
  • toute connexion admin WHM hors plages horaires habituelles ;
  • création de fichiers exécutables dans /tmp ou /var/tmp par un processus lié à cPanel ;
  • modification de /root/.ssh/authorized_keys ;
  • nouveaux services systemd ou cron jobs non approuvés.

Comparaison avec des incidents antérieurs et perspective écosystème

L’écosystème cPanel reste une cible attractive pour les attaquants depuis des années, non pas parce que le produit serait intrinsèquement plus faible que d’autres panneaux, mais parce qu’il concentre des privilèges élevés sur des serveurs directement exposés à Internet. Historiquement, les campagnes opportunistes se focalisent sur les panneaux d’administration, les webmails, les plugins tiers et les intégrations de facturation. À chaque fois qu’un composant périphérique devient vulnérable, l’effet de levier est important : un seul point d’entrée peut donner accès à une grande quantité de services clients.

La leçon récurrente est que les plugins représentent souvent le maillon le moins bien gouverné. Les versions de cPanel peuvent être suivies correctement, alors que les composants additionnels sont parfois installés manuellement, sans inventaire fiable, sans supervision de version et sans procédure de retrait. C’est précisément ce type de dette technique qui transforme une alerte éditeur en incident majeur lorsqu’une faille rejoint le KEV.

Pour les hébergeurs, l’ajout au catalogue CISA a un effet très concret : il fournit un critère externe, reconnu et exploitable pour reclasser la priorité du correctif, même si le score CVSS n’est pas encore consolidé partout. En pratique, un composant d’administration Internet-facing, activement exploité, doit être traité avant des correctifs critiques non exploités sur des systèmes internes. Cette hiérarchisation est essentielle lorsque les équipes d’exploitation gèrent des dizaines de nœuds cPanel avec des contraintes de disponibilité fortes.

La situation rappelle aussi l’importance de standards de durcissement de base : accès d’administration par IP allowlist, VPN, MFA, journalisation centralisée, suppression des plugins inutiles, revue régulière des ports exposés et surveillance des composants tiers. Ces mesures n’empêchent pas toutes les exploitations, mais elles réduisent fortement la fenêtre d’opportunité et facilitent la détection.

En France, les structures qui gèrent des serveurs pour des tiers devraient également intégrer ce type d’alerte dans leur communication client : qualification du risque, calendrier de patch, éventuelles interruptions, et recommandations de changement de secrets si une compromission est suspectée. Pour les organisations soumises à des exigences réglementaires ou contractuelles, conserver la trace des décisions et des actions menées après l’alerte est indispensable.

La source originale à consulter reste l’avis de la CISA sur le catalogue Known Exploited Vulnerabilities, complété par l’advisory officiel de l’éditeur du plugin cPanel concerné. L’article de BleepingComputer a le mérite de souligner le changement de priorité induit par l’exploitation active, mais la remédiation doit toujours être pilotée à partir des informations techniques de l’éditeur : CVE-ID, versions touchées, version corrigée, procédure de mise à jour et éventuelles mesures compensatoires documentées.

Pour les équipes qui doivent agir vite, l’ordre de priorité est simple : identifier les serveurs cPanel exposés, confirmer la présence du plugin vulnérable, appliquer immédiatement la version corrigée, restreindre les accès d’administration tant que tout n’est pas patché, puis rechercher des indices de compromission. Si cette alerte révèle un manque d’inventaire ou une exposition trop large des panneaux d’administration, il est utile d’en profiter pour revoir durablement le hardening des serveurs et les procédures d’exploitation. Des mesures concrètes de réduction de surface d’attaque et de gouvernance des composants tiers sont détaillées dans la catégorie /categorie/pratiques.

Rubrique Serveurs
Partager
Retour aux actualités