La réponse courte
Un plugin Acronis Backup non corrigé permet à un compte limité sur un serveur d'hébergement de devenir root. CVE-2026-87886 (CVSS 7.8) est une élévation de privilèges locale due à des permissions de fichiers par défaut non sécurisées (CWE-276) dans le plugin Acronis Backup pour cPanel & WHM et l'extension pour Plesk sous Linux. Un attaquant disposant déjà d'un accès peu privilégié passe root sans interaction. Acronis a confirmé une exploitation dans la nature contre le plugin cPanel & WHM, et la CISA l'a ajoutée au catalogue KEV le 16 septembre 2026. Le correctif : passer au build 1.9.3.1021 (cPanel/WHM) ou 1.8.11.638 (Plesk) ou ultérieur.
Pour les équipes françaises, le tranchant tient à l'endroit où se loge la faille : la couche de sauvegarde et de panneau de contrôle est de confiance, privilégiée et presque jamais dans un périmètre de test. Une élévation locale à cet endroit est précisément l'étape qui transforme un point d'appui bon marché en contrôle total de l'hôte. C'est la posture que nous intégrons à un test d'intrusion et audit de sécurité — traiter la plomberie privilégiée de votre stack d'hébergement comme une surface d'attaque et prouver qu'elle tient.
Ce qu'Acronis a divulgué
Le plugin Acronis Backup pour cPanel & WHM et l'extension correspondante pour Plesk relient un panneau de contrôle d'hébergement à l'infrastructure de sauvegarde Acronis. Ils permettent aux administrateurs de sauvegarder et restaurer sites web, bases de données, boîtes mail et serveurs entiers directement depuis le panneau — le plugin s'exécute donc avec un large accès aux fichiers et processus de la machine. Un logiciel aussi privilégié est une cible de choix : une faiblesse en son sein ne reste pas confinée à un seul compte.
En septembre 2026, Acronis a divulgué CVE-2026-87886, une élévation de privilèges locale enracinée dans des permissions de fichiers par défaut non sécurisées (CWE-276). Parce que certains fichiers ou répertoires installés par le plugin sont accessibles en écriture ou en exécution par des comptes qui ne devraient pas y avoir droit, un attaquant authentifié disposant déjà d'une position peu privilégiée sur le serveur Linux peut s'en servir pour élever ses droits — jusqu'à root — sans aucune interaction d'un utilisateur légitime. La faille porte un score CVSS de 7.8, et Acronis décrit l'exploitation comme peu complexe.
Point crucial : Acronis a indiqué qu'une exploitation avait été détectée dans la nature dans des attaques limitées et ciblées contre le plugin cPanel & WHM ; l'extension Plesk n'a pas été vue exploitée, bien qu'elle soit également concernée et doive être corrigée. Peu après la divulgation, la CISA a ajouté CVE-2026-87886 à son catalogue des vulnérabilités activement exploitées le 16 septembre 2026, avec une échéance au 19 septembre pour les agences fédérales civiles américaines — le même traitement que les failles de sévérité maximale bien plus voyantes du jour, car c'est l'usage réel, et non le score brut, qui vaut une entrée au KEV. La remédiation est simple : mettre le plugin à jour vers le build corrigé. La discipline de durcissement que nous appliquons sur une plateforme Cloud et DevOps — moindre privilège, droits de fichiers stricts et un pipeline de correctifs rapide — est exactement ce dont cette faille a manqué.
Pourquoi une faille « locale » est grave
Il est tentant de classer une faille locale, authentifiée et notée 7.8 sous les vedettes 10.0 pré-authentification — et cet instinct est précisément la manière dont ces failles se font exploiter. Les vraies intrusions sont des chaînes, pas des étapes isolées. Les attaquants obtiennent un point d'appui peu privilégié à bas coût : une application web vulnérable, une clé SSH fuitée, une web shell déposée via un CMS compromis, ou simplement un compte locataire sur une machine partagée. Seul, ce point d'appui est limité. Une faille d'élévation de privilèges est la seconde moitié de la chaîne — l'étape qui transforme « je peux exécuter du code en utilisateur restreint » en « je possède la machine ».
Sur un serveur d'hébergement multi-locataire, ce rayon d'impact est énorme. Root ne signifie pas un seul site ; il signifie tous les sites, bases de données et boîtes mail de l'hôte, plus le plan de contrôle des sauvegardes lui-même. Ce dernier point rend une escalade proche des sauvegardes particulièrement dangereuse : un attaquant qui atteint la couche gérant les sauvegardes peut les lire, les exfiltrer ou les détruire, supprimant en silence la voie de récupération sur laquelle une organisation compte si un rançongiciel suit. L'outil acheté pour garantir la restauration devient le pivot qui la sabote.
Aucune configuration astucieuse ne corrige des droits de fichiers non sécurisés dans du code tiers — les permissions corrigées arrivent dans le build patché, c'est pourquoi mettre à jour le plugin constitue toute la remédiation. Cela recadre le vrai risque autour de la vélocité de correction des logiciels que vous n'avez pas écrits : plugins de panneaux de contrôle, agents de sauvegarde et modules de gestion dérivent de votre cadence de mises à jour justement parce qu'ils ressemblent à de l'infrastructure plutôt qu'à du code applicatif, et c'est dans cet écart qu'attend une escalade exploitée dans la nature.
Ce que cela signifie pour les équipes françaises
La première leçon est que les modules privilégiés de votre stack d'hébergement font partie de votre surface d'attaque. Les équipes inventorient et corrigent les frameworks de leurs propres dépôts, puis traitent le panneau de contrôle et ses plugins comme une boîte noire qui « tourne toute seule ». Mais les agents de sauvegarde et extensions de panneau détiennent certains des accès les plus puissants du serveur, et une faille de permissions dans l'un d'eux est une route directe vers root. Tout ce que vous faites pour durcir le code applicatif — moindre privilège, accès fichiers minimal, mises à jour rapides — doit s'étendre au logiciel tiers qui se trouve en dessous.
La deuxième leçon porte sur la défense en profondeur, pour qu'un point d'appui ne soit pas fatal. Cette escalade ne paie qu'après qu'un attaquant dispose déjà d'une position peu privilégiée ; donc tout contrôle qui rend ce premier point d'appui plus difficile ou plus bruyant — isoler les locataires, restreindre ce qu'un processus web peut exécuter, surveiller les changements de privilèges inattendus et garder le plan de sauvegarde sur des identifiants et réseaux séparés — limite directement les dégâts. Supposez que des points d'appui initiaux surviendront, et concevez pour que atteindre root exige plus qu'un seul plugin non corrigé.
Troisièmement, il s'agit d'un événement de conformité et d'assurance de restauration, pas seulement d'un ticket d'exploitation. Un compromis root d'un serveur hébergeant des sites et boîtes mail de clients relève des attentes RGPD, NIS2 et DORA en UE — et parce que la couche de sauvegarde est dans le périmètre, il touche aussi votre capacité à démontrer que la restauration est intacte. Pouvoir montrer quels hôtes exécutaient le plugin concerné, quand vous avez corrigé et que vos sauvegardes étaient vérifiées et à accès contrôlé est le dossier que les auditeurs et régulateurs demanderont en premier.
Que faire maintenant
- Inventoriez les hôtes concernés. Trouvez chaque serveur Linux exécutant cPanel & WHM ou Plesk avec le plugin ou l'extension Acronis Backup — y compris les machines de préproduction, héritées et de revendeurs qui échappent à la liste principale des actifs.
- Mettez le plugin à jour immédiatement. Installez le build 1.9.3.1021 (1.9.3 HF3) pour cPanel & WHM ou 1.8.11.638 (1.8.11) pour Plesk, ou ultérieur. Il n'existe pas de contournement de permissions, traitez donc cela comme un changement d'urgence. Corrigez aussi Plesk, même si seule l'exploitation de cPanel/WHM a été observée.
- Chassez l'escalade. Examinez les journaux serveur, sudo et plugin pour repérer des changements de privilèges inattendus, de nouveaux fichiers ou tâches cron appartenant à root, et l'activité de comptes peu privilégiés ayant soudain agi en root. Un intrus root peut avoir altéré ces journaux : recoupez plusieurs sources.
- Vérifiez vos sauvegardes. Confirmez que les sauvegardes sont présentes, restaurables et stockées avec des identifiants et un accès réseau séparés des hôtes qu'elles protègent — l'objectif d'une attaque sur la couche de sauvegarde est de supprimer votre option de récupération avant l'étape suivante.
- Confinez, faites tourner, puis testez. Si un hôte était accessible et non corrigé, traitez-le comme potentiellement compromis : faites tourner identifiants, clés et secrets qu'il détenait, et ajoutez les panneaux d'hébergement et leurs plugins au périmètre de votre prochain test d'intrusion pour que l'infrastructure privilégiée cesse d'être un angle mort.
Questions fréquentes
Qu'est-ce que CVE-2026-87886 ?
C'est une élévation de privilèges locale (CVSS 7.8) dans le plugin Acronis Backup pour cPanel & WHM et l'extension pour Plesk sous Linux. Des permissions de fichiers par défaut non sécurisées (CWE-276) permettent à un utilisateur authentifié et peu privilégié sur le serveur d'élever ses droits — jusqu'à root — sans aucune interaction. Ce n'est pas une faille non authentifiée exposée sur Internet ; l'attaquant doit d'abord disposer d'un point d'appui sur l'hôte.
Est-elle exploitée dans la nature ?
Oui. Acronis indique qu'une exploitation a été détectée dans des attaques limitées et ciblées contre le plugin Acronis Backup pour cPanel & WHM. Aucune exploitation active de l'extension Plesk n'a été signalée. La CISA a ajouté CVE-2026-87886 à son catalogue des vulnérabilités activement exploitées le 16 septembre 2026, avec une échéance de remédiation au 19 septembre pour les agences fédérales civiles américaines.
Quelles versions sont concernées et quels sont les correctifs ?
Le plugin cPanel & WHM est concerné avant le build 1.9.3.1021 (publié en 1.9.3 HF3), et l'extension Plesk avant le build 1.8.11.638 (publié en 1.8.11). Mettez à jour vers ces builds ou une version ultérieure. Il n'existe pas de contournement par configuration pour des permissions de fichiers non sécurisées — les permissions corrigées sont livrées dans le build patché, donc l'installer constitue la remédiation.
Pourquoi une faille locale et authentifiée compte-t-elle autant ?
Sur un serveur d'hébergement partagé ou multi-locataire, un point d'appui peu privilégié est bon marché — un site compromis, une web shell ou un compte locataire. Cette faille le transforme en root, soit le contrôle de tous les sites, bases de données et boîtes mail de l'hôte, plus le plan de sauvegarde. L'élévation locale est la seconde moitié de la plupart des intrusions réelles, donc une 7.8 déjà exploitée mérite la même urgence qu'une faille distante.
Que doivent faire les équipes maintenant ?
Inventoriez chaque serveur Linux exécutant cPanel & WHM ou Plesk avec le plugin Acronis Backup, et mettez à jour immédiatement vers le build 1.9.3.1021 ou 1.8.11.638 (ou ultérieur). Examinez les journaux pour repérer des changements de privilèges inattendus et une activité root, traitez les hôtes exposés comme potentiellement compromis, faites tourner les secrets qu'ils détenaient, vérifiez que les sauvegardes sont intactes et à accès contrôlé, et ajoutez les panneaux d'hébergement et leurs plugins au périmètre de votre prochain test d'intrusion.
Sources
Help Net Security — Acronis backup plugin flaw exploited in targeted attacks (CVE-2026-87886)
Security Affairs — CISA Adds Acronis Backup, Cisco ISE, and Google Pixel Flaws to KEV Catalog
CISA — CISA Adds Two Known Exploited Vulnerabilities to Catalog