Retour au blog
CVEN-ableN-centralMSPauthentificationagents IA

N-able N-central CVE-2026-18577 : contournement d'auth

Publié le 2026-08-03 · Mis à jour le 2026-10-295 min de lecture
En bref : CVE-2026-18577 est un contournement d'authentification (CWE-288, CVSS 4.0 de 8.2) dans la plateforme de supervision N-able N-central, activement exploité en août 2026. Il vient d'un correctif incomplet de CVE-2026-18556 et touche tous les builds antérieurs à 2026.3.1.7, publié le 2 août. N-able demande désormais le Hotfix 2, le build 2026.3.1.10, même à ceux qui ont déjà installé le premier. Les attaquants ont utilisé Take Control pour atteindre des postes gérés et ont enregistré des tunnels Cloudflare comme services Windows. Mettre à jour ne supprime pas ces tunnels.

Que s'est-il passé ?

Selon The Hacker News, N-able a ouvert une enquête le 31 juillet après un volume inhabituel d'erreurs de licence venant de clients sur site. Deux identifiants CVE existent, tous deux notés 8.2 en CVSS 4.0 : CVE-2026-18556, qui couvre les versions jusqu'à 2026.1 (CWE-288), et CVE-2026-18577, issue d'un chemin d'exploitation alternatif découvert ensuite et que le premier correctif ne bloquait pas. Passer à 2026.3 ne suffit donc plus : il faut au moins 2026.3.1.7.

Après avoir pris le contrôle d'un serveur N-central, les attaquants ont utilisé la fonction Take Control pour atteindre des terminaux gérés, puis ont enregistré des tunnels Cloudflare comme services. Ces tunnels initient des connexions sortantes, n'exigent aucune règle de pare-feu entrante et ont continué à fonctionner après la révocation de l'accès via N-central. Cloudflare lui-même n'est pas compromis.

Qui est concerné ?

N-able indique que les instances hébergées (N-central On Demand) sont mises à jour automatiquement, alors que les clients autohébergés doivent appliquer eux-mêmes le correctif. Les sources divergent sur la portée exacte des versions affectées ; la plus restrictive à retenir est « tout build antérieur à 2026.3.1.10 » pour un déploiement autohébergé. Huntress a observé l'activité sur une instance autohébergée d'un compte partenaire, avec un poste atteint dans chacune de neuf organisations, apparemment limitée à l'énumération de processus. N-able n'a pas communiqué le nombre de clients touchés, ni la date de début, ni l'auteur. Microsoft rattache l'activité à Storm-1175 selon Help Net Security.

Comment tester si vous êtes exposé ?

  1. Relevez le numéro de build de chaque serveur N-central et comparez-le à 2026.3.1.10.
  2. Vérifiez si l'interface web est joignable depuis Internet.
  3. Examinez l'historique des sessions Take Control sur la période suspecte.
  4. Cherchez sur les terminaux gérés un service nommé Cloudflared, un exécutable svchost.exe dans le dossier Documents d'un utilisateur, et des connexions sortantes vers l'infrastructure Cloudflare qui ne correspondent à aucun usage légitime.
  5. Comparez les adresses IP de connexion avec les indicateurs publiés par N-able. Huntress précise que quatre des six adresses publiées sont des sorties de VPN grand public : un blocage par IP seul est donc fragile.
  6. Cherchez des comptes nouveaux ou réinitialisés, dont un compte nommé veeam signalé par Sophos.

Comment corriger ?

  • Installer le build 2026.3.1.10 (Hotfix 2). N-able indique qu'il est requis même après le Hotfix 1.
  • Supprimer les tunnels malveillants sur les terminaux : la mise à jour du serveur ne les retire pas.
  • Traiter l'environnement comme potentiellement compromis si le correctif a été appliqué plusieurs jours après sa sortie : revoir tous les comptes et privilèges, changer les mots de passe administrateur, imposer l'authentification multifacteur.
  • Filtrer le trafic sortant des serveurs de gestion et des terminaux qui n'ont pas besoin de services de tunnel.
  • Ne pas exposer la console de gestion à Internet quand l'accès par VPN ou par une passerelle authentifiante suffit.

Pourquoi les tunnels Cloudflare échappent-ils aux pare-feux ?

Parce que la connexion part de la machine compromise vers l'extérieur, en HTTPS, vers un service légitime. Aucun port n'est ouvert en entrée, et la plupart des politiques laissent passer le trafic sortant. La parade est le filtrage et la surveillance du trafic sortant : alerter sur les nouvelles destinations, bloquer les services de tunnel sur les machines qui n'en ont pas l'usage, et inventorier les services Windows installés récemment.

Que change la présence d'un agent IA sur ce système ?

Une plateforme de supervision concentre des droits d'administration sur des centaines de machines. Si un agent IA y est branché, par exemple pour trier des alertes, lancer des scripts de remédiation ou répondre à des tickets, il hérite de cette puissance.

  • Droits d'action étendus. Un agent autorisé à lancer des scripts ou ouvrir une session de prise de contrôle peut être amené, par le contenu d'un ticket, d'une alerte ou d'un journal qu'il lit, à exécuter une action choisie par l'attaquant. C'est l'injection de prompt indirecte appliquée à l'exploitation IT, avec le risque d'agence excessive décrit par OWASP (LLM06).
  • Jetons et identifiants dans le contexte. La clé d'API de la plateforme et les identifiants des comptes de service sont souvent donnés à l'agent pour qu'il agisse. Un serveur N-central compromis, ou un prompt qui fait lire ces secrets, expose tous les terminaux gérés d'un coup.
  • Actions non validées. Redémarrer un service, installer un logiciel ou désactiver une protection sont des actions que l'agent peut enchaîner automatiquement. Sans validation humaine pour les actions à effet de bord, une consigne piégée a le même impact qu'un opérateur légitime.
  • Un attaquant qui prend l'agent pour cible. Dans l'incident décrit, l'attaquant a ajouté de la persistance sur les terminaux. Contre un agent, la persistance peut se loger dans sa mémoire, ses consignes ou ses outils (voir MITRE ATLAS), et survivre à un correctif du serveur.
  • Traçabilité. Une action menée par l'agent apparaît dans les journaux comme une action du compte de service. Il faut conserver l'instruction d'origine et les arguments des outils.

Les contre-mesures utiles sont un compte dédié à l'agent avec un périmètre étroit, des actions à risque soumises à validation, et une couche de contrôle des actions indépendante du modèle. Notre page sur la sécurité des agents IA détaille ces vecteurs, et celle sur l'injection de prompt explique comment un contenu lu par l'agent devient une instruction.

Comment tester un agent relié à vos outils d'administration ?

On fournit à l'agent des tickets, alertes et journaux piégés, puis on observe les outils appelés, les secrets accessibles et les actions effectuées sans validation. Le Red Team Agent Express réalise ce test en 5 jours pour 1 900 €, avec un rapport de preuves. Le rendez-vous découverte, 30 minutes et gratuit, sert à cartographier l'accès de votre agent à l'outil d'administration à distance.

Votre produit embarque un agent IA ? CleanIssue teste ce qu’un inconnu peut lui faire faire avec le Red Team Agent Express (5 jours, 1 900 €), ou un red team sur mesure pour plusieurs agents et serveurs MCP. Premier échange : un rendez-vous découverte de 30 minutes, gratuit.

Sachez ce que votre agent peut faire avant un attaquant.

Rendez-vous découverte de 30 minutes, gratuit : vous décrivez votre agent, je vous dis ce que je testerais et à quel prix. Cinq études de cas sont publiées.

Prendre rendez-vous