Le 16 septembre 2026, BleepingComputer a rapporté que des attaquants exploitaient activement CVE-2026-84869, une vulnérabilité de ConnectWise ScreenConnect ajoutée au catalogue Known Exploited Vulnerabilities (KEV) de la CISA le 11 septembre. Le défaut concerne le traitement des transferts de fichiers dans les clients ScreenConnect et peut contourner une autorisation attendue au cours d’une session distante active.
ConnectWise a publié la mise à jour 26.6.5 le 8 septembre. Le point important pour les équipes qui administrent l’outil est double : les versions antérieures doivent être corrigées rapidement, et l’avis du fournisseur distingue le client ScreenConnect des serveurs eux-mêmes. Aucune compromission précise d’une entreprise cliente n’est établie par les sources consultées ; le risque documenté est celui d’une exploitation en cours.
Ce que la CISA et les sources publiques ont confirmé
CVE-2026-84869 est désormais suivie comme une faille exploitée dans la nature. BleepingComputer relie cette qualification à l’ajout au catalogue KEV de la CISA et indique que l’agence américaine a demandé aux administrations fédérales de sécuriser leurs systèmes dans un délai court. Le Centre canadien pour la cybersécurité confirme de son côté l’ajout au KEV le 11 septembre et signale des éléments publics indiquant une exploitation active.
Cette qualification change la priorité opérationnelle : il ne s’agit plus seulement d’une vulnérabilité à planifier dans le prochain cycle de maintenance. Pour une organisation qui utilise ScreenConnect pour dépanner, corriger ou administrer des postes, une instance ancienne doit être considérée comme une surface d’accès à traiter sans attendre une preuve de compromission.
Ce que permet CVE-2026-84869
ConnectWise décrit une condition de contrôle d’autorisation manquant et de mauvaise gestion des privilèges dans le client ScreenConnect. Dans certaines circonstances, un attaquant disposant déjà de privilèges de base peut faire transférer puis exécuter un fichier au travers d’une session distante active sans autorisation adéquate ni confirmation de l’hôte. L’avis indique une faible complexité d’attaque et aucune interaction utilisateur nécessaire dans le scénario évalué.
Le score CVSS publié par ConnectWise est de 9,9. Ce score décrit l’impact potentiel sur la confidentialité, l’intégrité et la disponibilité ; il ne prouve pas qu’un fichier précis a été exécuté chez chaque utilisateur. Il faut donc séparer ce que la faille rend possible, ce que la CISA confirme sur l’exploitation active et ce qui resterait à établir dans une investigation locale.
Qui est concerné
L’avis ConnectWise indique que les versions ScreenConnect antérieures à 26.6.5 sont concernées. Le bulletin précise que le problème se situe dans le client et que les serveurs ScreenConnect ne sont pas impactés par cette vulnérabilité. Les environnements cloud et on-premise apparaissent dans le périmètre de l’avis de mitigation, mais les opérations de correction diffèrent selon le mode de déploiement.
Pour un partenaire on-premise, la priorité est d’installer ScreenConnect 26.6.5 ou une version ultérieure compatible avec sa licence. Pour un client cloud, ConnectWise indique qu’aucune action serveur n’est requise ; il faut néanmoins réinstaller les host clients et mettre à jour les agents d’accès après la mise à niveau du service. L’inventaire doit donc couvrir les postes clients et agents, pas uniquement l’URL d’administration.
Les mesures immédiates pour les administrateurs
La correction recommandée est la mise à jour vers ScreenConnect 26.6.5. Si une fenêtre de changement ou un gel de production empêche de l’appliquer immédiatement, ConnectWise recommande de désélectionner la permission TransferFiles pour chaque groupe de sessions et chaque rôle dans Administration > Security > Roles. Dans les anciennes versions, cette permission peut s’appeler TransferFilesInSession.
Cette désactivation est une réduction temporaire de l’exposition, pas un correctif. Après la mise à jour, vérifiez les rôles, les groupes de sessions, les host clients et les agents d’accès afin d’éviter qu’un poste reste sur une version vulnérable. Documentez l’heure de la correction et la liste des systèmes traités : cette trace facilite la recherche d’un événement antérieur.
Les vérifications après exposition
Une équipe qui exploitait une version antérieure doit examiner les journaux de connexion, les sessions distantes et les événements de transfert ou d’exécution de fichiers autour de la période d’exposition. Les noms de fichiers inhabituels, une session hors procédure, un agent apparu sans ticket ou une connexion sortante inattendue sont des signaux à corréler, pas des preuves isolées.
Si une utilisation malveillante est suspectée, isolez les postes concernés sans détruire les éléments de preuve, préservez les journaux et faites vérifier les comptes et sessions associés. Révoquez les identifiants ou jetons susceptibles d’avoir été exposés et contrôlez les autres outils d’administration à distance présents sur les mêmes machines. La CISA et ConnectWise documentent la vulnérabilité ; ils ne publient pas dans les sources consultées un périmètre de victimes permettant de conclure qu’une organisation donnée a été compromise.
Le lien avec Soclyde
Soclyde ne corrige pas ScreenConnect, ne surveille pas les sessions distantes et ne remplace pas une réponse à incident. Son utilité intervient autour du risque de réutilisation des secrets : générer un mot de passe unique pour chaque service, le conserver dans un coffre chiffré local-first et rendre sa rotation plus simple lorsqu’un compte d’administration doit être révoqué ou remplacé.
Cette séparation réduit les conséquences d’un secret réutilisé entre un outil d’accès distant, une messagerie et d’autres services. Elle ne transforme pas un poste compromis en poste sûr : la mise à jour, l’analyse des journaux, la révocation des sessions et le contrôle des agents restent prioritaires pour ScreenConnect.
À retenir
CVE-2026-84869 est exploitée activement et concerne les versions ScreenConnect antérieures à 26.6.5. Les équipes doivent appliquer la mise à jour, ou désactiver temporairement TransferFiles dans tous les rôles si le déploiement doit attendre, puis vérifier les clients et agents après correction.
Le bon réflexe n’est pas d’attendre une alerte sur son propre environnement : inventez les installations, recherchez les événements de transfert et d’exécution, et préparez la rotation des accès associés. Pour réduire la réutilisation des secrets, consultez le guide du générateur de mots de passe sécurisé ou contactez Soclyde.
