Tard dans la soirée du dimanche 8 novembre, le chercheur en sécurité Sean Bales a publié un dépôt GitHub nommé Able2Shell. Dedans : des exploits de démonstration pour plus de trente vulnérabilités zero-day présumées dans N-central, la plateforme de supervision et de gestion à distance (RMM) que les MSP et les équipes IT utilisent pour administrer les portables, serveurs et réseaux des autres.
Le lundi après-midi, N-able avait coupé ses environnements N-central hébergés aux Amériques, en Europe et en Asie-Pacifique. Les clients sur site étaient invités à éteindre leurs serveurs « jusqu'à nouvel ordre ». Un éditeur avec des milliers de partenaires et des centaines de milliers de terminaux en aval a choisi la panne plutôt que l'exposition.
Ce n'est pas un lundi normal. C'est une porte d'entrée enfoncée pendant que le serrurier lit encore la notice.
Ce qui a été publié exactement
Le dépôt Able2Shell cible N-central Appliance 2026.4.0.31, une version préliminaire, et Bales pense que la plupart, sinon la totalité des failles, remontent à des versions antérieures. Les catégories seules donnent la profondeur :
- contournement d'authentification
- divulgation d'identifiants
- écriture arbitraire de fichiers et directory traversal
- cross-site scripting (XSS) exécutable en root quand un administrateur ouvre des métadonnées de correctif piégées
- injection XML external entity (XXE)
- exécution de code à distance (RCE)
- une élévation de privilèges locale qui porte le code du compte de service
nablejusqu'à root
Le pire est une chaîne. Un XXE non authentifié dans la fonction d'import de services permet de voler une session locale de confiance, de réinitialiser le mot de passe d'un compte et d'exécuter des commandes sous nable. La même chaîne peut créer un compte Default Administrator actif avec des identifiants choisis par l'attaquant : un inconnu possède désormais la console qui gère votre parc. Bales a mis en ligne une vidéo de l'attaque complète, sortie terminal incluse.
N-able affirme n'avoir observé aucune exploitation active ni accès non autorisé aux données, et qu'un correctif est en cours de développement et de validation. Des mises à jour sont promises toutes les quatre heures. Les services Ecoverse derrière N-able Login sont restés disponibles. Tout le reste s'est éteint.
Un détail à laisser infuser : Bales a confirmé à BleepingComputer que la découverte était assistée par IA. Plus de trente failles dans une appliance d'entreprise, en un seul cycle de recherche. C'est le nouveau référentiel de vitesse.
Pourquoi il l'a fait, et pourquoi cela compte plus que les bugs
Bales dit avoir volontairement sauté la divulgation coordonnée. Sa raison : il avait déjà signalé deux RCE indépendants dans un autre produit N-able, plus une élévation de privilèges, environ cinq à six mois plus tôt. Il affirme qu'ils ne sont toujours pas corrigés. Il dit avoir envoyé des relances pendant quatre à six semaines sans réponse, et n'avoir jamais été payé par le programme de bug bounty. Après la publication, le PDG et le CTO de N-able l'ont contacté pour lui demander de retirer le dépôt et de collaborer, sans menaces.
N-able n'a pas répondu aux questions de BleepingComputer sur ces signalements antérieurs.
Alors : chercheur imprudent qui lâche des exploits vivants un lundi, ou processus de divulgation si inopérant que publier était le seul levier ? Les deux peuvent être vrais. La leçon inconfortable : la seule pression qui a réellement fait bouger cet éditeur, c'est la honte publique plus une panne mondiale.
Et il y a un coût réel. Cette semaine, un technicien MSP dans une clinique de 40 personnes clôture des tickets sans console. Publier trente exploits non corrigés met des utilisateurs ordinaires en danger.
Le problème RMM que personne ne veut mettre sur une slide
Le RMM est, par conception, le logiciel le plus privilégié du bâtiment : des agents sur chaque terminal, des identifiants pour chaque environnement client, un shell distant, du déploiement de correctifs, de l'exécution de scripts. Le modèle économique est « une console, des centaines d'organisations ». Le modèle de sécurité est souvent « faites-nous confiance ».
D'où une cible qui imprime de l'argent :
- Un login, des centaines de clients. Compromettez le RMM et vous héritez de toutes les relations clients derrière.
- Exécution distante incluse. Pas besoin de chercher un mouvement latéral : le produit le livre en standard.
- Agents signés partout. La protection des terminaux laisse passer le trafic puisqu'il vient de votre plateforme de gestion.
- Correctifs en retard. Une appliance reste une appliance. Personne ne la patche un mardi soir comme un serveur web.
Que faire dans les 72 heures
- Inventaire d'abord. Quelles instances N-central possédez-vous ou héritez-vous via un partenaire, et quels terminaux sont encore enregistrés ? On ne peut pas éteindre ce qu'on ne trouve pas.
- Isoler. Les environnements hébergés sont déjà hors ligne. Sur site : éteignez comme demandé, ou, à défaut, limitez l'accès entrant aux IP de gestion connues et coupez l'exposition externe immédiatement.
- Considérez les identifiants N-central comme brûlés. Faites tourner tout ce que la plateforme stockait : identifiants de déploiement d'agents, comptes de service, jetons API, connexions déléguées Microsoft 365 et Google Workspace, chaînes SNMP, identifiants de sauvegarde.
- Cherchez les traces de la chaîne. Nouveaux administrateurs locaux, compte Default Administrator activé, connexions sortantes de l'utilisateur
nable, réinitialisations de mot de passe inattendues, appels d'import de services que vous n'avez pas faits. - Vérifiez votre EDR pour les processus enfants de l'agent RMM. Tout shell ou outil d'archivage lancé depuis ce parent mérite un examen cette semaine.
- Testez votre restauration avant d'en avoir besoin. Un correctif arrive. Votre plan de retour arrière ne peut pas être « on verra ».
- Écrivez le SLA de divulgation que vous exigez. Puis demandez à chaque éditeur RMM de formuler le sien par écrit, conditions de bounty et délais de réponse inclus.
L'angle Golfe
Pour les clients de Dubaï et du Golfe, cela tombe à un endroit précis. L'IT externalisée est la norme pour une large part du mid-market local, et beaucoup de cette IT passe exactement par cette catégorie d'outil. Si vous êtes une entité régulée, la latence de correctifs de votre prestataire est désormais un risque prudentiel, pas une note opérationnelle. Les régulateurs posent la même question : qui peut exécuter du code dans votre environnement, et comment le savez-vous ?
La réponse honnête, dans la plupart des entreprises, est « notre MSP, via une console que nous n'avons jamais auditée ». Cela doit changer avant le prochain incident, pas après.
La conclusion
N-central reviendra, probablement en quelques jours. Un correctif sortira, les partenaires patcheront, le cycle de l'actualité passera à autre chose.
La leçon qui survit à la semaine est plus petite et plus dure : votre frontière de confiance est une liste de permissions fournisseurs, et cette liste est plus longue que votre organigramme. Une panne RMM agace une journée. Un RMM compromis, c'est chacun de vos clients, dans un onglet de navigateur d'attaquant.