Une faille critique de ScreenConnect alimente des attaques semblables à des vers via des sessions distantes actives

ConnectWise a publié une mise à jour de sécurité urgente pour CVE-2026-84869, une vulnérabilité critique du client ScreenConnect déjà exploitée dans la nature.

Sous certaines conditions, cette faille permet à un attaquant de transférer et d’exécuter des fichiers au cours d’une session distante ScreenConnect active, sans autorisation appropriée ni confirmation sur l’hôte. Huntress observe des exploitations depuis le 20 août, notamment des attaques utilisant des clients ScreenConnect compromis ou malveillants pour diffuser des charges utiles vers d’autres clients connectés.

La vulnérabilité obtient un score CVSS v3 de 9,9. La CISA l’a ajoutée à son catalogue des vulnérabilités exploitées connues le 11 septembre 2026 et a fixé au 14 septembre 2026 la date limite de correction pour les agences fédérales américaines.

Les clients ScreenConnect antérieurs à la build 26.6.5.9742 sont concernés

Le composant vulnérable est le client ScreenConnect. D’après la fiche NVD, les serveurs ScreenConnect ne sont pas concernés par cette condition de sécurité particulière.

Les informations de version sont exprimées avec différents niveaux de précision. ConnectWise identifie ScreenConnect 26.6.5 comme la version qui contient le correctif, tandis que la NVD considère comme vulnérables les versions antérieures à 26.6.5.9742.

Les administrateurs doivent donc vérifier la build complète installée et ne pas se fier uniquement à la version fonctionnelle affichée. Le seuil de sécurité est ScreenConnect 26.6.5.9742 ou une version ultérieure.

La vulnérabilité est associée à deux catégories de faiblesses :

• CWE-269 — Gestion incorrecte des privilèges
• CWE-862 — Autorisation manquante

Son vecteur CVSS NVD est le suivant :

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H

Ce vecteur décrit une faille accessible via le réseau, présentant une faible complexité d’attaque. Son exploitation nécessite des privilèges limités, mais aucune interaction de la part de l’utilisateur qui contrôle l’hôte ciblé. Le changement de périmètre indique qu’une exploitation réussie peut franchir une frontière de sécurité, tandis que les impacts sur la confidentialité, l’intégrité et la disponibilité sont tous jugés élevés.

ConnectWise indique que le client corrigé renforce la gestion des sessions pour les opérations de transfert et d’exécution de fichiers.

Les attaquants transforment des sessions de confiance en voies de propagation

La campagne observée commence par de l’ingénierie sociale. Les attaquants convainquent leurs cibles d’exécuter des clients ScreenConnect malveillants, établissant ainsi le point d’appui initial nécessaire pour exploiter les relations de support distant actives.

Selon les informations fondées sur les observations de Huntress, une instance ScreenConnect modifiée déploie ensuite quatre fichiers VBScript. Ces scripts sont destinés à assurer la persistance et à contribuer à la propagation de la charge utile vers d’autres clients ScreenConnect.

Les clients malveillants vérifient si des sessions distantes actives sont disponibles. Lorsqu’ils détectent des cibles connectées, les attaquants exploitent le comportement vulnérable de transfert et d’exécution pour pousser les charges utiles VBScript au travers de ces sessions.

C’est la raison pour laquelle cette activité est qualifiée d’attaque semblable à un ver. Un client compromis ou contrôlé par l’attaquant peut utiliser les connexions ScreenConnect existantes pour atteindre d’autres systèmes et étendre l’intrusion par l’intermédiaire de relations que les administrateurs considèrent généralement comme fiables.

Cette description ne permet pas d’affirmer que le malware est un ver réseau totalement autonome. L’ingénierie sociale intervient lors de la compromission initiale et la propagation dépend de sessions ScreenConnect actives. Néanmoins, la possibilité de passer d’un client à d’autres clients connectés peut accélérer la compromission des environnements de support distant.

Les fournisseurs de services managés, les services d’assistance, les administrateurs informatiques et les organisations ayant de nombreuses relations de session ScreenConnect sont particulièrement exposés sur le plan opérationnel. Un seul client malveillant peut devenir un point de diffusion lorsqu’il rencontre d’autres clients actifs.

Une exécution non autorisée peut affecter l’ensemble des environnements de support

Une exploitation réussie peut permettre à un attaquant de déposer et d’exécuter certains fichiers sur les systèmes associés à des sessions de clients ScreenConnect vulnérables. Les conséquences immédiates peuvent inclure la persistance, le déploiement d’autres malwares ou l’extension de l’attaque à des terminaux supplémentaires.

Le niveau élevé attribué à la confidentialité reflète le risque d’exposition des données accessibles depuis les systèmes compromis. L’impact sur l’intégrité couvre les modifications et exécutions non autorisées, tandis que la note de disponibilité tient compte de la possibilité d’une interruption ou d’une activité destructive.

Dans le scénario vulnérable, aucune confirmation sur l’hôte n’est requise. Cette caractéristique réduit la possibilité pour l’utilisateur du terminal ou le technicien d’interrompre un transfert malveillant avant son exécution.

Les logiciels d’accès distant occupent également une position sensible au sein des réseaux d’entreprise. Ils relient les opérateurs, les terminaux et les infrastructures de support au-delà des frontières organisationnelles. L’exploitation de ces canaux établis peut permettre à un attaquant de dissimuler une activité malveillante au milieu d’opérations d’administration légitimes et d’atteindre des systèmes qui ne sont pas directement exposés à internet.

La CISA indique que l’utilisation à des fins de ransomware est inconnue. Il n’existe donc aucun élément confirmé permettant de qualifier l’exploitation observée de ScreenConnect de campagne de ransomware.

La CISA impose l’application des correctifs et une analyse forensique initiale

La CISA a ajouté CVE-2026-84869 à son catalogue des vulnérabilités exploitées connues le 11 septembre 2026. Cette inscription confirme que la vulnérabilité n’est pas purement théorique : son exploitation a été documentée.

La date limite de correction pour les agences fédérales est fixée au 14 septembre 2026. La CISA indique également qu’une analyse forensique initiale est requise au titre de la Binding Operational Directive 26-04, « Prioritizing Security Updates Based on Risk ».

Les agences fédérales doivent appliquer les mesures d’atténuation du fournisseur tout en respectant les exigences de la BOD 26-04 en matière de déploiement des correctifs et d’analyse forensique initiale. Elles doivent également évaluer l’exposition à internet des actifs concernés. Pour les services cloud, les organisations doivent respecter les exigences de la directive applicable ou cesser de les utiliser lorsqu’aucune mesure d’atténuation efficace n’est disponible.

Les organisations du secteur privé ne sont pas soumises à la date limite fédérale, mais les mêmes faits opérationnels s’appliquent. L’exploitation est active, la propagation peut se produire par l’intermédiaire de clients connectés et l’application des correctifs ne suffit pas à déterminer si un système a été compromis auparavant.

Aucun précédent récent spécifique à ConnectWise dans le catalogue KEV n’a été identifié dans les sources vérifiées disponibles. Ce cas ne doit donc pas être présenté comme faisant partie d’une série documentée d’ajouts récents au catalogue KEV concernant l’éditeur.

Appliquer d’abord le correctif, puis examiner les sessions actuelles et historiques

Les organisations doivent mettre à niveau les clients ScreenConnect vers la build 26.6.5.9742 ou une version ultérieure. Lorsque le déploiement immédiat n’est pas possible, ConnectWise recommande de désactiver l’autorisation TransferFiles jusqu’à ce que la mise à jour puisse être effectuée.

Une réponse opérationnelle devrait comprendre les étapes suivantes :

1. Recenser les clients ScreenConnect et leurs builds exactes. Identifiez chaque client antérieur à 26.6.5.9742, y compris les systèmes gérés par des tiers ou utilisés ponctuellement pour le support.

2. Installer la version corrigée. Vérifiez que la build obtenue atteint ou dépasse le seuil NVD, au lieu de contrôler uniquement la désignation générale de la version 26.6.5.

3. Désactiver TransferFiles lorsque l’application du correctif est retardée. Considérez cette mesure comme une atténuation temporaire et non comme un substitut à la mise à niveau.

4. Examiner les sessions distantes actives et récentes. Recherchez les connexions inattendues, les relations de session inhabituelles et les clients communiquant avec des systèmes qui ne correspondent pas aux habitudes normales de support.

5. Rechercher les transferts et exécutions non autorisés. Examinez l’activité de ScreenConnect afin d’identifier les fichiers poussés sans tâche administrative attendue ni approbation de l’hôte.

6. Rechercher une persistance fondée sur VBScript. Huntress a observé quatre charges utiles VBScript, mais leurs noms de fichiers, leurs hachages et les autres indicateurs concrets n’ont pas été communiqués. Les défenseurs doivent donc s’appuyer sur des recherches comportementales, la télémétrie d’exécution des scripts, les modifications de persistance et l’historique des sessions.

7. Inspecter les binaires des clients ScreenConnect. Des clients inattendus, modifiés ou nouvellement introduits peuvent indiquer l’étape d’ingénierie sociale ou un déploiement contrôlé par l’attaquant.

8. Retracer une éventuelle propagation. Si un client semble compromis, examinez tous les clients ScreenConnect qui lui étaient connectés au cours des sessions concernées.

9. Effectuer une analyse forensique initiale avant de clore l’incident. La CISA impose explicitement cette analyse aux agences concernées, et les autres organisations devraient conserver les journaux ainsi que les éléments présents sur les terminaux avant que la remédiation n’efface des traces utiles.

La mise à jour supprime la condition vulnérable, mais pas les charges utiles déjà transmises au cours de sessions antérieures. Toute organisation utilisant une build concernée doit traiter l’application du correctif et l’évaluation d’une éventuelle compromission comme deux tâches menées en parallèle.