N-able déconnecte N-central après la publication de plus de 30 exploits zero-day

N-able a mis hors ligne ses environnements N-central hébergés dans le monde entier le 9 novembre 2026, après que le chercheur en sécurité Sean Bales a publié plus de 30 vulnérabilités zero-day présumées dans sa plateforme de surveillance et de gestion à distance (RMM), dont des chaînes d'exploitation permettant à un attaquant de créer un compte administrateur et d'exécuter des commandes en tant que root. N-able a confirmé l'incident à 15h15 UTC et a demandé aux clients exploitant des serveurs N-central sur site de les éteindre jusqu'à nouvel ordre.

N-central constitue l'épine dorsale que de nombreux prestataires de services gérés (MSP) utilisent pour administrer à distance les réseaux de leurs clients : déploiement de correctifs, installation de logiciels et surveillance des terminaux pour des dizaines, voire des centaines d'organisations clientes, depuis une seule console. Cette concentration d'accès explique pourquoi les plateformes RMM sont devenues une cible de choix pour les groupes de ransomware depuis l'attaque de Kaseya VSA en 2021, où un seul outil compromis avait propagé un logiciel malveillant à environ 1 500 entreprises en l'espace d'un week-end. Une faille nouvelle et non corrigée dans N-central présente le même risque de point de défaillance unique pour chaque client MSP qui en dépend.

Bales a publié ses découvertes sur LinkedIn dans la nuit de dimanche 8 novembre, et a mis en ligne du code de démonstration (proof-of-concept) dans un dépôt GitHub qu'il a baptisé « Able2Shell ». Il a déclaré à BleepingComputer que les vulnérabilités avaient été découvertes avec l'aide de l'intelligence artificielle et testées sur N-central Appliance 2026.4.0.31, une version préliminaire, mais qu'il pense que la plupart des failles touchent également des versions antérieures actuellement déployées. La chaîne la plus critique exploite une faille XML External Entity (XXE) non authentifiée dans la fonction d'import de services pour voler une session locale de confiance, réinitialiser un mot de passe et exécuter des commandes via le compte de service nable ; le même bug peut aussi créer un compte administrateur activé et contrôlé par l'attaquant. Une faille distincte de script intersite stocké (stored XSS) permet d'exécuter des commandes en tant que root dès qu'un administrateur consulte des métadonnées de correctif piégées, et un troisième bug élève les privilèges du compte nable directement à root.

N-able affirme n'avoir observé aucune exploitation active des failles révélées et travaille sur un correctif d'urgence, avec des mises à jour de statut promises toutes les quatre heures. Il s'agirait du cinquième cycle de correctif d'urgence de l'entreprise depuis le 1er août, après une série de vulnérabilités de N-central cette année, dont une faille d'exécution de code à distance pré-authentification de gravité maximale et activement exploitée, corrigée en septembre.

Bales affirme avoir renoncé à la divulgation coordonnée parce que N-able avait laissé sans suite deux bugs d'exécution de code à distance sans lien et une faille d'élévation de privilèges qu'il avait signalés dans un autre produit de l'entreprise cinq à six mois plus tôt, ignorant plusieurs e-mails de relance et sans verser de prime de bug bounty. « Ils ne prennent pas la divulgation au sérieux », a-t-il déclaré à BleepingComputer. Il a ajouté que le PDG et le CTO de N-able l'avaient contacté après la publication sur GitHub pour lui demander de retirer le dépôt, mais que l'entreprise ne l'avait pas menacé. N-able n'a pas répondu aux questions concernant les rapports antérieurs non corrigés.

Pour les MSP, la solution à court terme est simple mais coûteuse : mettre N-central hors ligne, comme le recommande N-able elle-même, jusqu'à la publication du correctif. Le problème de fond est le schéma qui se dessine derrière cet incident : une plateforme qui gère la sécurité de milliers d'entreprises clientes a publié cinq correctifs d'urgence en trois mois, et son propre chercheur affirme que des signalements sans rapport sont restés sans réponse pendant six mois. Chaque nouveau cycle de divulgation affaiblit l'argument consistant à faire passer un tel volume d'accès par une seule console nécessitant des correctifs aussi fréquents.

D'après BleepingComputer.