Quand c'est l'outil de votre prestataire qui est piraté : la leçon N-able

Vous avez fait le nécessaire : mots de passe robustes, double authentification sur la messagerie, antivirus à jour, sauvegardes en place. Et pourtant, un attaquant peut entrer chez vous cette semaine sans toucher à aucune de ces protections — simplement parce qu'il a pris le contrôle de la console d'administration de votre prestataire informatique. C'est très exactement ce qui se produit depuis le 1er août 2026 avec N-central, un logiciel de télémaintenance utilisé par des milliers d'infogéreurs pour piloter les parcs de leurs clients.

Ce qui s'est passé

N-central, édité par N-able, appartient à la famille des outils dits RMM, pour Remote Monitoring and Management. C'est le tableau de bord depuis lequel un prestataire supervise, met à jour et dépanne à distance l'ensemble des postes et serveurs de ses clients. Sur chaque machine gérée tourne un agent qui dispose des privilèges les plus élevés du système — c'est la condition pour pouvoir installer un correctif ou prendre la main sur un poste sans déranger l'utilisateur.

Le 2 août 2026, N-able a publié un avis de sécurité concernant CVE-2026-18577, une faille de contournement d'authentification. Elle permet à un attaquant distant, sans aucun compte ni mot de passe, d'obtenir les droits d'administrateur sur un serveur N-central exposé. Circonstance aggravante : cette vulnérabilité est la conséquence d'un premier correctif incomplet, publié quelques jours plus tôt pour une faille voisine (CVE-2026-18556). Les serveurs dont les administrateurs pensaient s'être mis à l'abri restaient donc vulnérables.

L'exploitation active est constatée depuis le 1er août, avant même la publication de l'avis. Le 3 août, l'agence américaine de cybersécurité CISA a inscrit la faille à son catalogue des vulnérabilités activement exploitées et donné trois jours aux administrations fédérales pour corriger — un délai exceptionnellement court, réservé aux situations jugées graves.

Le scénario observé par les équipes de réponse à incident est instructif. Une fois maîtres de la console, les attaquants n'ont pas cherché à chiffrer le serveur de télémaintenance lui-même : ils ont utilisé sa fonction légitime de prise en main à distance pour se connecter aux machines des clients. Puis, sur ces machines, ils ont installé des outils d'accès distant grand public (AnyDesk, TeamViewer, RustDesk), enregistré un service de tunnel réseau pour se ménager une porte dérobée persistante, et désactivé les solutions de sécurité présentes. Leur reconnaissance visait en priorité les contrôleurs de domaine, les serveurs applicatifs et les serveurs de sauvegarde — la signature classique d'une préparation de rançongiciel.

Pourquoi cela concerne votre PME, même si vous n'avez jamais entendu parler de N-central

Parce que le problème n'est pas ce produit en particulier. Le marché du RMM compte une dizaine d'acteurs équivalents, et tous ont connu ou connaîtront le même type d'incident : ces consoles concentrent un pouvoir considérable, ce qui en fait des cibles de premier choix. Un attaquant qui en compromet une seule accède d'un coup à des dizaines d'entreprises clientes. C'est le principe de l'attaque par la chaîne d'approvisionnement : on ne force pas cent portes, on prend le trousseau de clés.

Trois conséquences pratiques pour une PME :

• Vos protections périmétriques ne servent à rien dans ce scénario. La connexion arrive par un canal légitime, avec un agent autorisé, sous un compte d'administration attendu. Ni le pare-feu ni le filtrage de messagerie ne verront quoi que ce soit d'anormal.
• Votre niveau de sécurité intègre celui de vos prestataires. Vous pouvez être irréprochable en interne et compromis par le maillon faible d'un fournisseur. C'est d'ailleurs l'un des points sur lesquels la directive NIS2 met explicitement la pression : la sécurité de la chaîne de sous-traitance devient une obligation, pas une bonne pratique.
• Vous ne le saurez pas tout seul. Sans journalisation des sessions de prise en main à distance ni supervision des installations logicielles, une intrusion de ce type reste invisible jusqu'au jour où les fichiers sont chiffrés.

Les gestes concrets, cette semaine

1. Posez la question à votre prestataire, par écrit. « Utilisez-vous un outil de télémaintenance sur notre parc ? Lequel ? Est-il concerné par les vulnérabilités N-able du 2 août ? Quand avez-vous appliqué le correctif ? » Un infogéreur sérieux répond en quelques heures et vous aura probablement déjà informé. Un silence, une réponse évasive ou un « on va regarder » est en soi un résultat d'audit.
2. Demandez trois garanties de fond, indépendantes de cet incident. L'authentification multifacteur sur tous les comptes de la console d'administration ; l'accès à cette console restreint (non exposé librement sur Internet, filtrage par adresse IP ou VPN) ; la conservation et la mise à disposition des journaux des sessions de prise en main sur votre parc.
3. Faites vérifier vos propres machines. Les indicateurs publiés dans cette affaire sont simples : un fichier nommé svchost.exe présent dans le dossier Documents d'un utilisateur, un service Windows nommé Cloudflared, ou l'apparition d'outils de prise en main que personne n'a demandés. Ajoutez la recherche de comptes administrateurs créés récemment et de connexions hors des horaires habituels.
4. Traitez vos sauvegardes comme le dernier rempart. Au moins une copie hors ligne ou immuable, inaccessible depuis le réseau et depuis les comptes d'administration courants — y compris ceux du prestataire. Et une restauration testée : une sauvegarde jamais restaurée n'est qu'une hypothèse.
5. Inscrivez la notification d'incident dans le contrat. Votre prestataire doit s'engager à vous prévenir sans délai s'il est lui-même victime d'une compromission susceptible de vous atteindre. C'est une clause courte, rarement refusée, et qui change tout le jour venu.

La leçon de fond : le risque fournisseur se pilote comme les autres

Les chiffres de cette affaire disent l'essentiel : plus de la moitié des serveurs concernés étaient encore vulnérables le lendemain de la publication du correctif, et près d'un tiers des installations hébergées chez les prestataires eux-mêmes l'étaient toujours plus de vingt-quatre heures après. La faille n'est pas seulement technique, elle est organisationnelle : personne n'avait de procédure prête pour appliquer un correctif d'urgence sur son propre outillage.

Pour une PME, la conclusion n'est pas qu'il faut se passer d'infogérance — c'est l'inverse. Un prestataire compétent reste la meilleure façon de tenir un parc à jour. Mais la délégation ne doit pas être un angle mort : il est légitime, et sain, de savoir quels outils ont un accès privilégié à votre système d'information, qui les administre, comment ils sont protégés et comment vous serez prévenu en cas de problème. Cela tient en une page : la liste de vos fournisseurs ayant un accès technique, ce à quoi ils accèdent, et le contact à joindre en cas d'incident. Peu d'entreprises l'ont ; celles qui l'ont gagnent des heures décisives lorsque l'alerte tombe.

En conclusion

Cette semaine, des entreprises qui n'avaient rien fait de mal ont vu des attaquants entrer chez elles par la porte de service — celle qu'elles avaient confiée à un tiers de confiance. L'incident N-able n'est ni le premier ni le dernier du genre, et le seul enseignement durable est celui-ci : votre périmètre de sécurité s'arrête là où s'arrêtent les accès de vos fournisseurs, pas là où s'arrête votre réseau.

Vous souhaitez savoir qui dispose réellement d'un accès privilégié à votre système d'information, faire vérifier vos postes après cet incident ou mettre en place une supervision indépendante de votre infogérance ? Parlons-en.