ScreenConnect ha un problema di sicurezza nel trasferimento file che riguarda sia il servizio Cloud sia le installazioni On-Premise. ConnectWise non ha ancora pubblicato una patch definitiva e, nell’attesa, raccomanda di disabilitare il permesso che consente ai tecnici di trasferire file nelle sessioni Remote Access.
Il punto operativo è semplice: se utilizzi ScreenConnect, non aspettare l’aggiornamento per ridurre l’esposizione. Puoi bloccare subito TransferFiles, controllare i log per attività anomale e prepararti a installare la correzione appena verrà resa disponibile.
ScreenConnect vulnerabile: cosa ha confermato ConnectWise
ConnectWise ha pubblicato il 3 settembre 2026 un avviso dedicato a ScreenConnect Remote Access. Il produttore indica che il problema interessa gli ambienti Cloud e On-Premise e coinvolge le sessioni di supporto e accesso remoto.
Al momento della verifica non è stato pubblicato un CVE specifico e la correzione è ancora in sviluppo. Nella propria pagina ufficiale degli advisory di sicurezza, ConnectWise indica come mitigazione temporanea la disattivazione del trasferimento file per i ruoli che non ne hanno necessità.
Questa distinzione è importante: non va presentato come un bug già corretto e non va associato a un numero CVE che oggi non esiste. La misura più utile, finché non arriva la patch, è ridurre i privilegi disponibili nelle sessioni.
Come disabilitare TransferFiles in ScreenConnect
La mitigazione indicata da ConnectWise consiste nel togliere ai ruoli il permesso di trasferire file. Prima di intervenire, verifica quali gruppi utilizzano questa funzione per attività legittime e prepara un’alternativa se il trasferimento file è necessario per il supporto quotidiano.
- Accedi alla console amministrativa di ScreenConnect.
- Apri Administration e poi Security.
- Entra nella sezione Roles.
- Modifica ciascun ruolo assegnato ai tecnici.
- Controlla i permessi applicati ai diversi gruppi di sessione.
- Disabilita TransferFiles. Nelle versioni o configurazioni legacy il permesso può comparire come TransferFilesInSession.
- Ripeti il controllo per tutti i ruoli che possono aprire sessioni Remote Access o Support.
Dopo la modifica, prova con un account tecnico non amministratore e verifica che il trasferimento file sia effettivamente bloccato. Non considerare completata la mitigazione soltanto perché il permesso è stato tolto a un singolo ruolo: in ambienti con più gruppi o privilegi ereditati è necessario controllare tutte le assegnazioni operative.
Cosa cercare nei log di ScreenConnect
Il problema è diventato particolarmente importante dopo l’analisi di installazioni ScreenConnect anomale osservate in ambienti compromessi. Huntress ha documentato client modificati capaci di trasferire ed eseguire una catena di script sui sistemi raggiunti.
Nella propria analisi tecnica sulle installazioni ScreenConnect anomale, Huntress segnala attività che coinvolgono script VBS e processi come wscript.exe. Nei log di audit meritano particolare attenzione eventi RunFiles o RanFiles associati a Process: Guest, soprattutto se riguardano script non riconosciuti.
- File VBS sconosciuti eseguiti durante o subito dopo una sessione remota.
- wscript.exe o cscript.exe avviati senza una ragione amministrativa chiara.
- PowerShell richiamato da script o processi che non fanno parte delle procedure abituali.
- RunFiles o RanFiles da Process: Guest verso file non riconosciuti.
- Nuovi client o sessioni ScreenConnect che non corrispondono all’inventario previsto.
Un singolo evento non dimostra automaticamente una compromissione. Se però trovi più indicatori coerenti, tratta il sistema come potenzialmente compromesso, isola l’endpoint dalla rete e avvia la risposta all’incidente prima di limitarti a rimuovere il software sospetto.
Se trovi segnali di compromissione, non limitarti a cambiare il permesso
Disabilitare TransferFiles riduce l’esposizione futura, ma non ripulisce un computer su cui è già stata eseguita una catena malevola. Huntress raccomanda per gli host con evidenze di compromissione di valutare il reimaging da un supporto conosciuto e affidabile.
In un ambiente aziendale conviene anche controllare account amministrativi, credenziali utilizzate sulle macchine coinvolte, sessioni remote attive e sistemi raggiungibili dallo stesso segmento di rete. Il principio è lo stesso che vale per altre vulnerabilità operative recenti, come abbiamo visto nelle guide su N-central e Hotfix 4 e su JFrog Artifactory e CVE-2026-82329: la patch è essenziale, ma va accompagnata dalla verifica di ciò che è accaduto prima dell’aggiornamento.
Cosa fare quando ConnectWise pubblicherà la patch
ConnectWise ha indicato che una correzione è in sviluppo. Quando sarà disponibile, la priorità sarà installarla senza rimandare, soprattutto sulle istanze On-Premise esposte a Internet.
- Verifica la nuova versione indicata nell’advisory ufficiale.
- Aggiorna prima le istanze più esposte.
- Controlla che l’aggiornamento sia stato applicato correttamente.
- Rivedi i log anche dopo l’installazione.
- Riattiva il trasferimento file soltanto per i ruoli che ne hanno una necessità operativa reale.
Non c’è alcun vantaggio nel riabilitare subito TransferFiles a tutti. Il principio del privilegio minimo resta valido anche dopo la patch: se un tecnico non deve trasferire file durante una sessione, quel permesso può rimanere disattivato.
ScreenConnect: cosa fare adesso in sintesi
Se amministri ScreenConnect, la sequenza più prudente è questa: disabilita TransferFiles, verifica tutti i ruoli, controlla gli audit log e prepara l’aggiornamento appena ConnectWise rilascerà la correzione. Se trovi script sconosciuti, eventi RunFiles sospetti o client non autorizzati, passa dalla semplice mitigazione alla risposta all’incidente.
La situazione è ancora in evoluzione e la parte più importante, oggi, è non trattare l’assenza di una patch come un motivo per restare fermi. Il produttore ha già fornito una mitigazione concreta e applicabile subito.
