Plesk : un simple compte avec shell peut obtenir les droits root

Le 27 août 2026, Plesk a publié un correctif pour CVE-2026-67394, une vulnérabilité locale permettant à un compte client ou revendeur disposant d’un accès shell — ou autorisé à modifier cet accès — d’obtenir les privilèges root sur un serveur Plesk pour Linux. L’avis de sécurité publié par Plesk le 27 août 2026 classe comme corrigées les versions Obsidian 18.0.79.9 et 18.0.80.5, ainsi que les versions ultérieures.

RimuHosting a relayé l’alerte quelques heures après sa publication et recommandé une mise à jour immédiate dans une notification opérationnelle datée du 27 août. Cette notification est désormais close, mais ce statut concerne l’intervention de l’hébergeur : il ne permet pas de conclure qu’un serveur administré ailleurs a reçu le correctif.

Les versions vulnérables et corrigées

Le périmètre publié concerne Plesk pour Linux. La mention « version 18.0 » ne suffit pas pour déterminer l’exposition : le dernier nombre du numéro de maintenance sépare ici une installation vulnérable de sa révision corrigée.

• 18.0.34 à 18.0.79.8 : versions vulnérables ; le correctif correspondant est inclus à partir de 18.0.79.9.
• 18.0.80 à 18.0.80.4 : versions vulnérables ; le correctif correspondant est inclus à partir de 18.0.80.5.
• 18.0.79.9 et 18.0.80.5 : premières révisions corrigées de leurs branches respectives.
• Plesk pour Windows : produit non concerné par cette vulnérabilité.

Il ne faut donc pas réduire la matrice à « 18.0.79 est sûre » ou « toutes les versions 18.0 sont vulnérables ». Une installation en 18.0.79.8 reste exposée, tandis que 18.0.79.9 contient le correctif ; la même frontière existe entre 18.0.80.4 et 18.0.80.5.

Comment contrôler la révision installée

La vérification doit faire apparaître le numéro de maintenance complet. Une valeur limitée à 18.0.79 ou 18.0.80 ne permet pas de trancher, puisque chacune de ces branches comprend des révisions vulnérables et une révision corrigée.

1. Dans l’interface d’administration, ouvrir Outils et paramètres > À propos de Plesk. La version peut également apparaître sur l’accueil ou dans l’aperçu du système, selon la vue active.
2. Sur un serveur Linux accessible en ligne de commande, exécuter plesk version ou plesk -v. La procédure officielle de contrôle de la version décrit ces commandes et les emplacements disponibles dans l’interface.
3. Comparer le résultat à la matrice : 18.0.79.8 doit atteindre au minimum 18.0.79.9, et 18.0.80.4 au minimum 18.0.80.5.
4. Si la révision est affectée, lancer la mise à jour de Plesk conformément à la procédure d’exploitation du serveur.
5. Après l’installation, répéter le contrôle et confirmer que la révision corrigée est effectivement affichée.

Le lancement d’une mise à jour ne prouve pas à lui seul son installation sur chaque machine. Pour un parc de plusieurs hôtes, le critère décisif reste la version complète constatée serveur par serveur après l’opération.

Pourquoi l’accès shell est la condition déterminante

CVE-2026-67394 est décrite comme une élévation locale de privilèges, non comme une compromission distante accessible sans compte. Son exploitation suppose un client ou un revendeur possédant déjà un accès shell, ou ayant le droit de modifier son propre accès.

Cette condition reste importante sur un hébergement partagé. Un compte client ou revendeur est normalement séparé de l’administration du système ; l’obtention des droits root supprimerait cette limite et donnerait un contrôle de niveau système sur le serveur.

À l’inverse, les informations publiques ne permettent pas d’affirmer que tout compte Plesk ordinaire peut devenir directement root. Un compte dépourvu de shell et du droit de modifier ce réglage ne remplit pas la condition d’exploitation rendue publique.

Désactiver le shell réduit le risque sans corriger la faille

Lorsque les clients et revendeurs n’ont pas besoin d’un shell, l’accès peut être désactivé pour supprimer la condition nécessaire à l’exploitation. Il faut alors repérer les abonnements, domaines ou espaces concernés, régler l’accès shell sur Interdit et vérifier que le plan de services n’autorise pas l’utilisateur à modifier ce paramètre.

Cette mesure est une réduction temporaire du risque, pas un correctif. Elle n’est pertinente que si la mise à jour ne peut pas être appliquée immédiatement et si aucun utilisateur concerné n’a réellement besoin du shell.

Si le shell reste indispensable à un client ou à un revendeur, aucune mitigation n’est disponible dans l’avis public. Les restrictions réseau, l’authentification renforcée ou une surveillance accrue peuvent compléter la défense générale du serveur, mais elles ne corrigent pas CVE-2026-67394 et ne remplacent pas l’installation d’une révision corrigée.

Ce que l’administrateur peut conclure après le contrôle

Le correctif est disponible et les limites de versions sont connues. Un serveur Linux est donc à traiter tant que le contrôle n’affiche pas au minimum 18.0.79.9 dans la branche 18.0.79 ou 18.0.80.5 dans la branche 18.0.80.

La détection d’une version vulnérable établit une exposition potentielle, mais ne démontre pas qu’une élévation de privilèges s’est produite. En l’état des informations publiques, la conclusion opérationnelle repose sur deux éléments vérifiables : la révision réellement installée et la présence éventuelle de comptes capables d’ouvrir ou d’activer un shell.

À lire aussi:

• Céder ses droits à une marque : « monde entier » peut durer toute une vie
• Suno limite les téléchargements : les morceaux IA deviennent traçables
• Levanta lève 22 millions, les commissions restent aux créateurs