N-central CVE-2026-86218 : RCE pré-auth CVSS 10

Qu'est-ce que CVE-2026-86218 ?

C'est une injection de code statique (CWE-96) dans le serveur N-central, la plateforme de supervision et d'administration à distance (RMM) utilisée par les prestataires informatiques gérés (MSP). N-able lui attribue un CVSS 4.0 de 10,0, et le NIST un CVSS 3.1 de 9,8. Aucune authentification n'est requise. watchTowr a reproduit la faille et souligne que les changements effectués dans N-central peuvent se propager à tous les systèmes connectés.

Quelles versions sont concernées et quel est le correctif ?

Les versions de N-central antérieures à 2026.3.1.14 sont concernées. Le correctif est le Hotfix 4 de la version 2026.3, publié le 5 septembre 2026, qui remplace le Hotfix 3. Ce dernier ne couvre pas cette faille. N-able a déjà corrigé ses environnements hébergés ; les déploiements auto-hébergés doivent être mis à jour manuellement. Le correctif n'impose pas de mise à niveau des agents installés sur les postes.

Y a-t-il eu des attaques réelles ?

Les éléments sont partagés. Une notice urgente de N-able aux clients indique que la faille « a été observée comme étant exploitée ». L'avis public, lui, dit ne pas avoir de confirmation d'exploitation en production. Le CISA a inscrit la CVE au KEV le 8 septembre, ce qui signale une exploitation active selon ses critères.

Huntress a enquêté sur la compromission, le 4 septembre 2026, d'un environnement N-central de production d'un client, pourtant entièrement à jour avant le Hotfix 4. Faute de journaux suffisants sur l'appliance, Huntress ne peut pas dire si CVE-2026-86218 en est la cause ni écarter d'autres failles. Deux autres vulnérabilités, CVE-2026-86206 et CVE-2026-86207 (signalées par Stephen Fewer de Rapid7), peuvent être enchaînées pour contourner l'authentification et créer un compte administrateur système. Elles sont corrigées par le Hotfix 3.

C'est le second épisode majeur sur N-central en peu de temps : voir notre article sur le contournement d'authentification CVE-2026-18577.

Comment détecter une compromission de N-central ?

La réponse courte : cherchez des comptes et des actions que personne n'a demandés, sur le serveur et en aval.

• Comptes administrateurs inconnus ou créés récemment, élévations de rôle inexpliquées.
• Journaux d'accès du serveur : requêtes anormales vers l'interface web avant la date de correction, depuis des adresses non attendues.
• Scripts et tâches de déploiement modifiés, nouvelles automatisations, sessions de prise de contrôle à distance inhabituelles.
• Connexions sortantes inattendues depuis l'appliance, tunnels ou outils d'accès à distance non déployés par vous.
• Postes gérés : exécutions de commandes massives ou installations de logiciels sur l'ensemble du parc dans une même fenêtre.

N-able recommande de vérifier les journaux d'accès du serveur avant la mise à jour et de limiter l'accès à l'interface d'administration depuis les réseaux non fiables.

Que faire concrètement ?

1. Appliquer le Hotfix 4 (build 2026.3.1.14) sur chaque instance, y compris celles que vous gérez pour vos clients.
2. Retirer l'interface d'administration d'Internet : accès par VPN ou liste d'adresses autorisées.
3. Si l'instance était exposée avant le 5 septembre, enquêter avant de conclure : mettre à jour ne retire pas un compte administrateur créé par l'attaquant.
4. Faire tourner les secrets stockés dans la plateforme (identifiants de domaine, mots de passe d'automatisation, jetons d'API).
5. Centraliser les journaux de la console vers un SIEM, avec rétention suffisante. L'enquête Huntress montre ce que coûte leur absence.

Qu'est-ce qui change quand un agent IA a accès à une console comme N-central ?

Un agent IA relié à un RMM dispose d'un levier de masse : il peut exécuter des scripts sur des centaines de machines. Si ses droits sont trop larges, ou si un attaquant prend la console, ce levier devient le vecteur de l'attaque. Quatre points sont à examiner.

Les identifiants dans le contexte de l'agent. Un agent qui automatise le support ou la remédiation détient souvent un jeton d'API de la console avec des droits étendus. Ce jeton se trouve dans son contexte ou dans la configuration de ses outils. Compromettre le serveur, ou injecter une instruction dans ce que l'agent lit, donne l'accès à tout le parc.

Les actions automatiques sans validation. Un agent autorisé à lancer un script de déploiement sur tout le parc exécute ce que le modèle propose. Une injection de prompt indirecte placée dans un ticket de support ou un e-mail peut le pousser à lancer une commande à l'échelle. Voir notre page sur l'injection de prompt.

Le compte administrateur créé par l'attaquant est aussi un utilisateur pour l'agent. Si l'agent fait confiance à la liste des utilisateurs ou des tâches planifiées de la console, un compte ou une tâche forgés par l'attaquant peut entrer dans le flux de travail de l'agent et être traité comme légitime.

Un agent comme post-exploitation. Des agents installés sur des postes peuvent être détournés pour la reconnaissance et le mouvement latéral, comme décrit dans notre article sur l'agent Hermes en post-exploitation.

Les défenses ressemblent à celles d'un accès privilégié : un jeton par tâche avec portée minimale, une liste fermée d'actions que l'agent peut déclencher, une validation humaine pour toute action à l'échelle du parc, des journaux d'appels d'outils reliés à une identité, et une surveillance de la création de comptes. Le risque correspond à LLM06 (Excessive Agency) du Top 10 OWASP pour les applications LLM. Voir aussi notre page sur la sécurité des agents IA.

Comment tester votre exposition ?

Listez les consoles d'administration que vos agents peuvent appeler, les jetons qu'ils détiennent et les actions de masse qu'ils peuvent lancer. Notre Red Team Agent Express (1 900 €, 5 jours) attaque un agent réel avec ses outils : injection indirecte, abus de jeton et actions sans validation, avec des preuves reproductibles à la clé.