CVE-2026-86218 : le troisième zero-day N-central en six semaines donne un RCE pré-auth sur la console qui pilote tous les postes

Rapport CTI technique du 9 septembre 2026

Résumé exécutif

Le 8 septembre 2026, la CISA a ajouté CVE-2026-86218 à son catalogue KEV avec une échéance de correction fixée au 11 septembre pour les agences fédérales américaines, soit trois jours seulement. La faille touche N-able N-central, la plateforme RMM utilisée par des milliers de MSP pour administrer les parcs de leurs clients. Notée CVSS 10.0, classée en injection de code statique (CWE-96), elle permet une exécution de code à distance sans authentification préalable. N-able a confirmé dans une notice « urgente » adressée directement à ses clients que la vulnérabilité « a été observée en exploitation », tout en indiquant dans les notes de version du Hotfix 4 n'avoir « aucune confirmation d'exploitation en environnement de production ». Cette contradiction est un signal en soi.

Le contexte compte autant que la faille. Il s'agit du troisième cycle d'urgence en six semaines sur le même produit : CVE-2026-18556 et CVE-2026-18577 début août, puis CVE-2026-86206 et CVE-2026-86207 le 5 septembre, puis CVE-2026-86218 le lendemain. Huntress a ouvert une investigation le 4 septembre après la compromission d'un environnement N-central de production entièrement à jour, ce qui signifie que l'attaquant disposait d'un vecteur non couvert par les correctifs d'août. Pour un red teamer, un serveur N-central exposé n'est pas une cible parmi d'autres : c'est un point de pivot vers l'ensemble des endpoints administrés, avec exécution de scripts en SYSTEM déjà légitimée par l'agent.

Chronologie

Fiche vulnérabilité

CVE-2026-86218 | CVSS 10.0 (critique) | N-able N-central antérieur à 2026.3.1.14 (Hotfix 4)

Injection de code statique, CWE-96 : « improper neutralization of directives in statically saved code ». La formulation de la CISA est directe : « N-able N-central contient une vulnérabilité d'injection de code statique pouvant permettre une exécution de code à distance en pré-authentification. »

Conditions d'exploitation : accessibilité HTTP/HTTPS de l'appliance. Aucune authentification, aucune interaction utilisateur, complexité d'attaque faible. Le score de 10.0 implique un changement de périmètre (scope changed) et un impact maximal sur confidentialité, intégrité et disponibilité, ce qui est cohérent avec un RCE sur le processus applicatif d'un serveur qui détient les credentials et les canaux de commande vers tous les agents déployés.

PoC disponible : non publié au 9 septembre. Ni Rapid7, ni Huntress, ni N-able n'ont publié d'exploit ou de détail de la primitive. Huntress indique en revanche avoir reconstitué une chaîne d'exploitation expliquant l'activité adverse observée, sans en publier les détails. L'écart entre reproduction interne et publication est court sur ce type de produit : la fenêtre avant apparition d'un PoC public se compte généralement en jours.

Patch : N-central 2026.3 Hotfix 4, version 2026.3.1.14, publié le 5 septembre 2026. Les instances hébergées par N-able ont été corrigées par l'éditeur.

CVE-2026-86206 | CVSS 6.9 | N-central antérieur à 2026.3 HF3

Contournement du filtre de contrôle d'accès donnant accès aux API internes de N-central. Rapportée par Stephen Fewer (Rapid7 Labs).

CVE-2026-86207 | CVSS 7.7 | N-central antérieur à 2026.3 HF3

Contournement d'authentification donnant un accès non autorisé à N-central. Chaînée avec CVE-2026-86206, elle permet à un attaquant distant non authentifié de créer un compte System Administrator sous son contrôle. C'est la chaîne la plus intéressante opérationnellement : elle ne se contente pas d'un accès, elle produit un compte persistant qui survit à un redémarrage et se fond dans l'usage légitime de la console.

Diagramme de la chaîne d'attaque

Chaîne reconstituée à partir des publications Huntress, Rapid7 et N-able des 5 au 8 septembre 2026. Les étapes 3 et 4 correspondent à des comportements observés en incident réel, l'étape 2 recouvre deux vecteurs distincts qui n'ont pas pu être départagés faute de journaux.

Analyse technique

Étape 1 : identification des appliances exposées

N-central s'administre par une interface web. Les instances on-premises des MSP sont massivement exposées sur Internet, parce que les techniciens y accèdent depuis l'extérieur et parce que les agents des clients doivent joindre le serveur. La surface se caractérise facilement par les chemins d'application et les bannières de l'interface de connexion, sans exploitation. Huntress rapporte que l'attaquant a interrogé un endpoint de reconnaissance interne pour cartographier l'appliance avant de tenter l'exploitation, ce qui suggère un préalable de fingerprinting de version : utile pour choisir entre plusieurs primitives selon le niveau de hotfix.

Étape 2 : exécution de code sans authentification

CWE-96 désigne le cas où une entrée contrôlée par l'attaquant est écrite dans du code sauvegardé statiquement, puis interprétée. Le schéma classique est celui d'un template, d'un fichier de configuration ou d'un script généré à partir de données utilisateur : la donnée traverse la frontière entre données et code au moment de la sérialisation, pas au moment de l'évaluation. C'est précisément ce qui rend ce type de faille difficile à repérer en revue statique, puisque le sink apparaît légitime, un simple write, et que l'exécution intervient plus tard, dans un autre composant.

L'éditeur n'a pas précisé quel composant de N-central écrit la donnée non neutralisée. Ce que l'on peut affirmer sans extrapoler : le score de 10.0 impose un vecteur réseau, une absence totale de privilèges requis et un scope modifié, ce qui place la primitive avant toute vérification d'identité dans la chaîne de traitement des requêtes.

En parallèle, la chaîne CVE-2026-86206 puis CVE-2026-86207 offre une alternative documentée : franchir le filtre d'accès aux API internes, puis contourner l'authentification sur ces API, puis appeler la fonction de création de compte administrateur. L'attaquant obtient alors une session légitime plutôt qu'un shell, ce qui est souvent préférable en termes de discrétion.

Étape 3 : persistance par comptes administrateurs déguisés

Le détail le plus exploitable pour la détection vient de Huntress : les attaquants créaient des comptes en ajoutant des chaînes anormales, par exemple le suffixe .invalid, à des adresses e-mail N-able connues. La logique est classique et efficace : un compte nommé d'après une adresse de support de l'éditeur passe la revue visuelle d'un administrateur pressé, et le suffixe garantit qu'aucun e-mail de notification ne partira vers une boîte réelle susceptible d'alerter le titulaire légitime. C'est un compromis assumé entre crédibilité et silence.

Le contrôle à faire est mécanique :

-- Recherche d'adresses e-mail au format anormal dans les comptes N-central SELECT username, email, created_at, role FROM users WHERE email LIKE '%.invalid'   OR email LIKE '%n-able%'   OR email NOT LIKE '%@%.%' ORDER BY created_at DESC;

Étape 4 : pivot vers les endpoints administrés

C'est l'étape qui justifie la criticité réelle, au-delà du score. Un compte System Administrator sur N-central donne accès au moteur d'exécution de scripts, qui déclenche du code sur les agents avec les privilèges du service, donc SYSTEM sur les postes Windows. Le trafic généré est celui de l'agent RMM légitime, vers un serveur légitime, avec des certificats légitimes. Un EDR qui a l'agent N-central en exclusion, configuration courante chez les MSP, ne verra rien d'anormal. C'est le schéma exploité par Storm-1175 en août sur CVE-2026-18577, avec déploiement de tunnels Cloudflare puis de ransomware.

Étape 5 : effacement des traces par rotation des journaux

Huntress note un obstacle qui mérite d'être retenu par les équipes IR : « en raison de la journalisation historique limitée disponible directement sur l'appliance, nous ne pouvons pas confirmer avec certitude quel exploit spécifique l'acteur a utilisé, ni exclure l'usage de vulnérabilités alternatives. » Sur l'incident du 4 septembre, les journaux avaient déjà tourné. Sans export externalisé des logs N-central, l'attribution technique d'une compromission sur ce produit est aujourd'hui difficile, voire impossible.

Indicateurs de compromission

Aucune adresse IP, aucun hash et aucun domaine n'ont été publiés par les parties impliquées au 9 septembre. Les indicateurs disponibles sont exclusivement comportementaux, ce qui impose une chasse par requêtes plutôt que par listes de blocage.

MITRE ATT&CK

Aucune cartographie officielle n'a été publiée par N-able, Rapid7, Huntress ou la CISA pour cette vulnérabilité. Le tableau ci-dessous est notre lecture technique de la chaîne observée, pas une attribution éditeur.

Remédiation : checklist opérationnelle

1. Appliquer immédiatement N-central 2026.3 Hotfix 4 (version 2026.3.1.14). Le Hotfix 3 ne couvre pas CVE-2026-86218. Vérifier le numéro de build, pas le libellé de version.
2. Sortir l'interface d'administration N-central d'Internet. Si un accès distant est requis, le placer derrière un VPN ou un reverse proxy avec authentification forte. Un RMM exposé publiquement est un point de défaillance unique pour tout le parc administré.
3. Auditer intégralement la table des comptes : tout compte System Administrator créé après le 1er août 2026 doit être rapproché d'une demande de changement. Traiter les adresses e-mail malformées ou suffixées comme des compromissions jusqu'à preuve du contraire.
4. Auditer les permissions des comptes existants, l'élévation d'un compte légitime étant moins visible qu'une création.
5. Externaliser les journaux de l'appliance vers un SIEM, immédiatement. La rotation locale a déjà empêché l'analyse d'au moins un incident réel.
6. Faire tourner tous les secrets détenus par le serveur : credentials d'accès aux clients, jetons d'API, clés d'intégration, comptes de service. Un RCE pré-auth donne accès à la configuration en clair ou déchiffrable.
7. Rechercher rétroactivement les exécutions de scripts N-central sur les endpoints administrés depuis le 1er août : tâches planifiées créées, exclusions Defender ajoutées, tunnels sortants inhabituels.
8. Retirer l'agent N-central des exclusions EDR globales et le remplacer par des exclusions ciblées sur les binaires signés, en conservant la télémétrie des processus enfants.
9. Pour les MSP : notifier les clients dont les environnements sont administrés depuis une instance qui a été exposée et non patchée entre le 4 et le 5 septembre.

Sources

• CISA Adds Four Known Exploited Vulnerabilities to Catalog
• N-able N-central Pre-Auth RCE Flaw Exploited in the Wild, The Hacker News
• Critical N-able N-central Vulnerability and Active Exploitation, Huntress
• N-central Security Update, Take Action to Apply 2026.3 HF4, N-able
• N-central 2026.3 Hotfix 3, CVE-2026-86206 et CVE-2026-86207, N-able Status
• CVE-2026-86218, CVE Record
• Back-to-back N-able bugs send admins on a patching spree, CSO Online
• N-able issues patch for zero-day flaw, Cybersecurity Dive