RMM au CISA KEV : N-able N-central 2026.3.1.14 et ConnectWise ScreenConnect 26.6.5.9742

Entre le 8 et le 11 septembre 2026, la CISA a ajouté à son catalogue KEV deux vulnérabilités visant des outils de télégestion (RMM) : N-able N-central et ConnectWise ScreenConnect. Quatre jours d'écart, deux éditeurs différents, deux produits qui font la même chose — administrer à distance des milliers de postes clients.

Ce n'est pas une coïncidence statistique. Un outil RMM est un accès administrateur préinstallé et légitime sur tout un parc, et depuis Kaseya en 2021 cette catégorie est traitée par les attaquants comme ce qu'elle est : le moyen le plus efficace de compromettre des centaines d'organisations en exploitant une seule faille.

Versions corrigées : N-central 2026.3.1.14 et ScreenConnect 26.6.5.9742.

Les deux CVE

CVE-2026-86218 — N-able N-central : RCE avant authentification

N-central is vulnerable to a pre-auth remote code execution. This issue affects N-central: before 2026.3.1.14.

La description est minimale, la CISA précise la catégorie : static code injection. Le vecteur dit le reste — réseau, complexité faible, aucun privilège requis, aucune interaction.

Sur N-central, une RCE pré-authentification ne touche pas un serveur : elle touche le serveur qui pilote tous les agents. C'est le point de convergence de l'ensemble du parc administré.

CVE-2026-84869 — ScreenConnect : la faille est dans le client, pas le serveur

C'est le point le plus important de cet article, et celui que la plupart des résumés ratent.

A condition in the ScreenConnect client may allow files to be transferred and executed through an active remote session without authorization or Host confirmation in certain circumstances. ScreenConnect servers are not impacted.

Trois conséquences pratiques :

1. Corriger le serveur ne suffit pas. Le correctif doit atteindre chaque poste sur lequel un client ScreenConnect est installé. Sur un parc de plusieurs milliers de machines administrées, c'est une opération de déploiement, pas une mise à jour de serveur.

2. La confirmation de l'utilisateur est contournée. ScreenConnect permet normalement à la personne devant la machine d'approuver ou de refuser un transfert de fichiers. Cette faille court-circuite ce contrôle — le seul garde-fou visible côté utilisateur disparaît.

3. Le PR:L est trompeusement rassurant. Il faut « des privilèges faibles » — en pratique, une session distante active. Dans un contexte MSP, un attaquant ayant obtenu un accès technicien de bas niveau, ou ayant compromis un compte de support, dispose exactement de cela.

Le S:C (scope changed) reflète la réalité : la faille est dans le client, l'impact est sur la machine du client final.

Versions

Vérifier N-central :

Interface d'administration → Help → About

Vérifier les clients ScreenConnect déployés :

# Windows — inventaire du parc
Get-CimInstance Win32_Product |
  Where-Object { $_.Name -like "*ScreenConnect*" } |
  Select-Object Name, Version, PSComputerName

# Ou via le service installé
Get-Service | Where-Object { $_.Name -like "ScreenConnect*" } |
  ForEach-Object { (Get-Item (Get-CimInstance Win32_Service -Filter "Name='$($_.Name)'").PathName.Trim('"')).VersionInfo }

La question à te poser pour ScreenConnect n'est pas « ai-je mis à jour ? » mais « quel pourcentage de mes clients installés est en 26.6.5.9742 ? ». C'est une métrique de couverture, pas un booléen.

Pourquoi les RMM sont devenus la cible privilégiée

La démultiplication

Un outil RMM est déployé par un prestataire infogérant sur l'ensemble de ses clients. Compromettre le serveur RMM d'un MSP moyen, c'est obtenir un accès administrateur simultané sur cinquante à cinq cents organisations — PME, cabinets médicaux, collectivités, commerces — dont aucune n'a d'équipe sécurité.

C'est le calcul que les opérateurs de rançongiciel font depuis Kaseya VSA en juillet 2021, où l'exploitation d'une seule plateforme a chiffré environ 1 500 entreprises en aval en un week-end.

La légitimité de l'outil

C'est ce qui rend la détection difficile. Un agent RMM a par conception le droit de :

• s'exécuter en SYSTEM
• déployer et lancer des exécutables
• ouvrir des sessions distantes
• désactiver ou reconfigurer des logiciels de sécurité

Un attaquant qui passe par le RMM n'a pas besoin d'outils malveillants : il utilise la fonctionnalité normale du produit. L'EDR voit un agent d'administration légitime faire ce qu'il fait tous les jours. Les listes blanches applicatives ne servent à rien, puisque le binaire est signé et autorisé.

La détection tardive

ScreenConnect en particulier est aussi utilisé par les attaquants comme outil d'accès distant après une compromission initiale — au point que sa simple présence sur une machine où le MSP n'intervient pas est un indicateur de compromission classique. Cela crée un bruit de fond qui complique la distinction entre usage légitime et usage malveillant.

Détection

N-central

• Comptes administrateurs inconnus dans la console
• Scripts ou tâches automatisées ajoutés récemment, en particulier ceux ciblant plusieurs clients à la fois
• Déploiements de paquets non corrélés à une demande
• Erreurs applicatives inhabituelles dans les journaux serveur autour du 6 septembre (date de publication) et après
• Trafic sortant du serveur N-central vers des destinations non liées à N-able et à tes clients

ScreenConnect — côté serveur

Administration → Audit

Cherche :

• Transferts de fichiers dans des sessions où aucun ticket ne le justifie
• Sessions ouvertes hors heures ouvrées ou depuis des adresses inhabituelles
• Comptes techniciens créés ou élevés récemment
• Sessions vers des machines qui ne sont pas dans ton périmètre d'infogérance

ScreenConnect — côté poste client

C'est là que la faille s'exploite, donc là que les traces se trouvent :

# Fichiers déposés par le client ScreenConnect
Get-ChildItem "$env:ProgramData\ScreenConnect Client*" -Recurse -File |
  Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-30) } |
  Select-Object FullName, LastWriteTime

# Processus enfants du client — c'est le signal décisif
Get-CimInstance Win32_Process |
  Where-Object { $_.ParentProcessId -in (Get-Process ScreenConnect* -ErrorAction SilentlyContinue).Id } |
  Select-Object ProcessId, Name, CommandLine

Un processus enfant du client ScreenConnect qui n'est pas un outil d'administration reconnu mérite une investigation immédiate.

Le contrôle transversal

Sur un poste où aucun MSP n'intervient, la présence d'un client ScreenConnect est en soi suspecte. Inventorie-la sur l'ensemble du parc, pas seulement sur les machines gérées.

Mitigation

1. Mettre à jour — les deux échéances CISA sont passées ou imminentes

N-central vers 2026.3.1.14, clients ScreenConnect vers 26.6.5.9742. Pour ScreenConnect, pilote le déploiement comme une campagne et mesure le taux de couverture : c'est le seul indicateur qui compte.

2. Restreindre l'accès au serveur RMM

Le serveur N-central ne devrait pas être exposé à Internet sans restriction. Si les techniciens y accèdent à distance, fais-le passer par un VPN avec authentification forte plutôt que par une publication directe.

3. Authentification multifacteur obligatoire — sans exception

Sur les deux plateformes, pour tous les comptes techniciens. C'est la mesure qui coupe le prérequis PR:L de la faille ScreenConnect, et c'est la contre-mesure la plus rentable contre la réutilisation d'identifiants volés.

4. Limiter la portée des comptes techniciens

Un technicien ne devrait avoir accès qu'aux clients dont il s'occupe. Un compte donnant accès à l'ensemble du portefeuille transforme une compromission individuelle en compromission de tous les clients.

5. Surveiller l'usage, pas seulement les vulnérabilités

Les transferts de fichiers et les exécutions distantes devraient générer des journaux corrélés à un système de tickets. Sans cette corrélation, une session malveillante est indiscernable d'une intervention normale — et c'est exactement ce sur quoi repose l'exploitation de cette catégorie d'outil.

6. Si tu suspectes une compromission

1. Considère le périmètre comme étant l'ensemble des clients administrés, pas le serveur seul
2. Révoque et régénère tous les jetons d'agent et identifiants techniciens
3. Audite les scripts et paquets déployés sur une fenêtre large
4. Préviens tes clients en aval — dans un contexte MSP, l'obligation d'information ne s'arrête pas à ta propre organisation
5. Vérifie les sauvegardes avant toute autre chose : si un attaquant dispose du RMM, il dispose aussi du moyen de les atteindre

Pourquoi surveiller en continu vos outils d'administration à distance

Les outils RMM partagent un angle mort avec les autres logiciels d'infrastructure : ils sont installés par l'équipe qui les utilise, mis à jour selon leur propre canal, et absents des inventaires applicatifs. Mais ils ont une particularité qui les rend pires — leur surface n'est pas un serveur, c'est chaque poste où l'agent est installé, et la question « suis-je à jour ? » n'a pas de réponse binaire.

Avec cveo.tech, inventorie tes outils de télégestion et d'accès distant avec leur version exacte, et reçois une alerte automatique dès qu'une CVE critique en concerne un — pour que la campagne de déploiement démarre le jour de la publication, pas après la première intrusion.