En bref

  • CVE-2026-18577 : bypass d'authentification dans N-able N-central (CVSS 8.2) exploité activement depuis le 1er août 2026
  • Toutes versions antérieures à 2026.3.1.7 vulnérables — les déploiements auto-hébergés non patchés sont des portes ouvertes
  • Mettre à jour immédiatement vers 2026.3.1.7 et auditer les journaux N-central des 10 derniers jours

Les faits

Le 31 juillet 2026, la solution MDR d'Adlumin détecte une activité inhabituelle sur l'environnement d'un client MSP. L'investigation révèle qu'un acteur inconnu exploite une faille zero-day sur le serveur N-central de la victime. Dès le 2 août, N-able publie en urgence la version corrective 2026.3.1.7. Le 3 août 2026, la CISA inscrit CVE-2026-18577 à son catalogue des vulnérabilités exploitées connues (KEV), signalant l'exploitation active et imposant aux agences fédérales américaines un délai de correction impératif.

N-able N-central est une plateforme RMM (Remote Monitoring and Management) massivement déployée chez les prestataires de services managés (MSP). Elle permet à ces prestataires d'administrer à distance les postes, serveurs et équipements réseau de leurs clients PME et ETI. Un acteur qui compromet un serveur N-central ne s'arrête pas à la victime directe : il obtient un accès en cascade à l'ensemble du portefeuille client du MSP — c'est l'effet de levier classique des attaques par la chaîne logistique IT.

CVE-2026-18577 est une autorisation impropre (CWE-285) dans la couche d'authentification de N-central. Elle permet à un attaquant distant, sans aucun credential préalable, d'obtenir des privilèges administrateurs sur n'importe quel serveur N-central exposé au réseau. Le score CVSS v4.0 est de 8.2 — sévère en soi — mais l'impact réel dépasse largement ce chiffre en raison de l'effet multiplicateur propre aux plateformes MSP : chaque serveur N-central compromis est une clé permettant d'ouvrir des dizaines voire des centaines de systèmes clients différents.

Selon l'analyse publiée par Rapid7, la vulnérabilité a été introduite lors d'une correction partielle d'une faille antérieure, CVE-2026-18556, corrigée dans N-central 2026.2. La deuxième vulnérabilité est apparue dans le code de remédiation lui-même — phénomène connu sous le nom de « patch-induced bug ». La timeline est éloquente : exploitation détectée le 31 juillet, analyse confirmée le 1er août, correctif publié le 2 août, inscription KEV le 3 août. En quatre jours, la faille est passée du statut de zero-day actif à celui de vulnérabilité cataloguée par la CISA.

Après avoir obtenu un accès administrateur via CVE-2026-18577, les attaquants ont exploité la fonctionnalité légitime Take Control de N-central pour se connecter aux endpoints managés. Take Control est une feature de prise en main à distance intégrée à la plateforme, destinée aux techniciens MSP. Son usage malveillant est quasi indétectable sans surveillance active des journaux N-central, car les connexions apparaissent comme des activités RMM normales dans les logs des postes clients.

Dans les incidents documentés par Huntress et Beazley Security, les attaquants ont déployé cloudflared — l'agent de tunnel Cloudflare — pour établir une persistance discrète. Cette technique tire parti de la confiance accordée aux services Cloudflare : les communications C2 transitent via les infrastructures légitimes de Cloudflare, contournant les contrôles basés sur les listes noires d'IP ou de domaines. Le binaire cloudflared est petit, signé numériquement, et souvent présent légitimement dans les environnements DevOps, ce qui complique sa détection par les outils de sécurité endpoint.

L'ampleur potentielle est considérable. N-able N-central est utilisé par des milliers de MSP dans le monde pour gérer des centaines de milliers de systèmes. Le parallèle avec l'attaque Kaseya VSA de juillet 2021 est inévitable : en quelques heures, ce zero-day avait touché plus de 1 500 entreprises dans 17 pays via un seul serveur RMM compromis. La réactivité de N-able — patch en moins de 24h — a réduit la fenêtre d'exploitation, mais les instances auto-hébergées non patchées restent exposées tant que leurs opérateurs n'appliquent pas manuellement la version 2026.3.1.7.

Les instances hébergées par N-able (cloud N-central) ont été mises à jour automatiquement dans les heures suivant la publication du correctif. En revanche, les déploiements auto-hébergés — particulièrement répandus dans les environnements réglementés (santé, collectivités territoriales, finance) — dépendent de l'action manuelle de l'administrateur. Plusieurs sources dont Cybersecurity News et le Windows Forum confirment des compromissions sur des instances non patchées après la publication de l'advisory, illustrant que la fenêtre de N-jours entre publication et déploiement reste une période de risque maximal.

Impact et exposition

Toute organisation utilisant N-able N-central en version antérieure à 2026.3.1.7 est exposée dès lors que le serveur est accessible depuis Internet ou depuis un réseau interne non segmenté. Les MSP auto-hébergés constituent le groupe le plus à risque : leur compromission n'affecte pas uniquement leur propre infrastructure mais potentiellement l'ensemble de leur base clients. Les clients finaux — souvent des PME sans équipe sécurité — subissent un risque indirect qu'ils ne peuvent pas maîtriser directement. La condition d'exploitation est minimale : seule une connectivité réseau vers le port web de N-central est requise. L'attaque est entièrement automatisable.

Recommandations

  • Immédiat — Mettre à jour N-central vers la version 2026.3.1.7. Les instances cloud N-able sont déjà patchées automatiquement.
  • Audit de compromission — Examiner les journaux N-central des 10 derniers jours : connexions Take Control non initiées par des techniciens connus, création de comptes admin, déploiement de cloudflared sur les endpoints.
  • Restriction réseau — Si la mise à jour immédiate est impossible, restreindre l'accès à l'interface N-central via ACL ou VPN ; ne jamais exposer N-central directement sur Internet.
  • Notification clients (MSP) — Informer proactivement les clients finaux, vérifier l'absence de persistance (cloudflared, tâches planifiées suspectes, nouveaux comptes locaux) sur les endpoints managés.
  • IOC à surveiller — Détecter les binaires cloudflared non autorisés ; surveiller les connexions sortantes vers *.trycloudflare.com et *.cloudflareaccess.com depuis les endpoints.

Alerte critique

Si votre MSP utilise N-able N-central et n'a pas confirmé par écrit l'application du patch 2026.3.1.7, demandez-lui une confirmation immédiate accompagnée d'un rapport d'accès. En cas de doute sur une compromission, isolez les endpoints concernés et engagez une équipe de réponse à incident sans délai.

Comment savoir si mon MSP a bien patché son N-central ?

Demandez à votre prestataire une confirmation écrite de la version N-central en production et la date d'application du correctif 2026.3.1.7. Un MSP sérieux doit pouvoir fournir une capture de l'interface d'administration affichant le numéro de version, ainsi qu'un extrait des journaux des 10 derniers jours sur votre périmètre. Si votre contrat inclut un reporting sécurité, cet incident doit faire l'objet d'une notification proactive sans que vous ayez à la solliciter.

Votre infrastructure est-elle exposée ?

Ayi NEDJIMI réalise des audits de sécurité ciblés pour identifier et corriger vos vulnérabilités avant qu'elles ne soient exploitées.

Demander un audit