ScreenConnect CVSS 9.9 : la faille qui transforme ton outil de support à distance en ver

Un client de support à distance compromis ne reste pas un problème isolé : il devient le vecteur qui infecte tous les postes qu’il touche ensuite. C’est exactement ce qui s’est passé avec CVE-2026-84869, la faille CVSS 9.9 corrigée début septembre dans ConnectWise ScreenConnect — un des outils RMM les plus utilisés par les MSP et les équipes IT internes pour le support à distance.

Le vecteur d’attaque, en clair

Techniquement, il s’agit d’une mauvaise gestion des privilèges combinée à une absence de contrôle d’autorisation (improper privilege management / missing authorization) dans le mécanisme de transfert de fichiers de ScreenConnect. Concrètement : un attaquant qui a accès à une session active — parce qu’il a convaincu un utilisateur d’installer un client ScreenConnect « maison » par ingénierie sociale, par exemple — peut pousser des fichiers vers l’hôte distant et déclencher leur exécution sans confirmation de l’opérateur. Pas de popup, pas de validation manuelle : le fichier arrive et s’exécute.

Seul le client est concerné, pas les serveurs ScreenConnect. Toutes les versions antérieures à la 26.6.5, publiée le 8 septembre 2026 et listée sur le Trust Center de ConnectWise, sont vulnérables.

Chronologie du traitement

Le calendrier est serré, ce qui en dit long sur la gravité perçue par les équipes de sécurité :

• 8 septembre 2026 — ConnectWise publie le bulletin de sécurité (Priority 1, le niveau le plus élevé de son échelle interne) et la version corrigée 26.6.5.
• 11 septembre 2026 — la CISA ajoute la faille à son catalogue Known Exploited Vulnerabilities (KEV), aux côtés de deux autres failles activement exploitées.
• 14 septembre 2026 — expiration du délai de remédiation imposé aux agences fédérales américaines (BOD 22-01) : trois jours ouvrés, signe d’une exploitation déjà massive au moment de l’ajout au KEV.

Ce que Huntress a vu sur le terrain

Les équipes de Huntress, citées par Help Net Security, ont documenté plusieurs intrusions construites sur ce même schéma, toutes initiées par de l’ingénierie sociale pour faire installer un client ScreenConnect détourné. Une fois la session active, l’attaque pousse quatre scripts VBScript — nommés sobrement 1.vbs à 4.vbs — chargés de profiler la machine, dissimuler l’activité, effectuer de la reconnaissance système et récupérer des composants supplémentaires. La suite est éloquente : persistance, installation d’instances ScreenConnect additionnelles sur la machine compromise, tunneling réseau, modification des contrôles de sécurité, et dans certains cas du minage de cryptomonnaie.

Le détail le plus préoccupant pour qui gère un parc multi-sites : les clients modifiés propagent ensuite les mêmes scripts aux nouveaux systèmes qu’ils touchent, créant une diffusion de type ver. Un seul poste compromis par social engineering peut donc contaminer en cascade tout un environnement géré à distance.

Comment réagir maintenant

Si ton parc utilise ScreenConnect, l’ordre de priorité est simple :

• Mettre à jour immédiatement tous les clients vers la version 26.6.5, pas seulement le serveur.
• Passer en revue les journaux d’audit ScreenConnect des sept derniers jours à la recherche d’entrées RunFiles/RanFiles associées à des processus invités (guest) — c’est la signature directe de cette technique d’exploitation.
• Chercher spécifiquement des transferts de fichiers .vbs, .js, .ps1 ou .bat initiés hors des opérations de support habituelles.
• Restreindre les permissions de transfert de fichiers aux seuls utilisateurs qui en ont réellement besoin, plutôt que de les laisser ouvertes par défaut à toute session active.
• Pour toute machine où une activité suspecte est confirmée, la réimager à partir d’un support fiable — un nettoyage partiel ne suffit pas face à une persistance de ce niveau.

Si tu es MSP et que ScreenConnect sert à administrer les postes de plusieurs clients, le risque de propagation inter-clients mérite une communication proactive plutôt que d’attendre qu’un incident remonte de lui-même.

FAQ

Les serveurs ScreenConnect sont-ils concernés par cette faille ?

Non, uniquement les clients. Mais la mise à jour des clients reste indispensable sur l’ensemble du parc, pas seulement sur les machines visiblement affectées.

Un antivirus classique aurait-il bloqué cette attaque ?

Pas nécessairement au moment du transfert initial : le fichier arrive via un canal de support légitime et sans confirmation utilisateur. La détection repose davantage sur l’analyse des journaux ScreenConnect et le comportement réseau post-compromission que sur la signature du fichier lui-même.

Comment savoir si mon organisation a déjà été ciblée ?

Cherche dans tes journaux ScreenConnect toute entrée RunFiles/RanFiles initiée par un compte invité plutôt qu’un opérateur authentifié, sur les sept à trente derniers jours selon ta politique de rétention de logs.

Et ensuite

Cette faille s’ajoute à la liste déjà longue des vulnérabilités critiques traitées en urgence ce trimestre — après les failles Cisco, Citrix et Fortinet ajoutées au catalogue CISA KEV mi-septembre et la faille critique GitLab CVSS 10. Le point commun : à chaque fois, l’écart entre divulgation et exploitation active se compte en jours, pas en semaines. Si tu n’as pas encore vérifié la version de tes clients ScreenConnect, c’est le moment de le faire avant de passer à autre chose.