Il 2026 non sta risparmiando gli strumenti di accesso remoto usati ogni giorno dai fornitori IT europei. L’11 settembre CISA ha aggiunto al catalogo Known Exploited Vulnerabilities una falla critica in ConnectWise ScreenConnect, il software di remote support usato da migliaia di Managed Service Provider (MSP) per gestire i sistemi dei clienti. Il codice è CVE-2026-84869, il punteggio è CVSS 9,9 su 10, e secondo i ricercatori di Huntress lo sfruttamento attivo era già in corso da fine agosto. Non è un bollettino qualunque: quando un attaccante può eseguire file su un endpoint tramite una sessione di supporto remoto legittima, il danno si propaga automaticamente a chiunque quell’endpoint gestisca a sua volta. Per gli MSP italiani ed europei, che vendono proprio la promessa di “gestione remota sicura”, è il tipo di notizia che cambia le priorità della settimana.
Cos’è CVE-2026-84869 e perché il CVSS è quasi il massimo
ScreenConnect è il prodotto di remote access e remote support di ConnectWise, uno dei nomi più diffusi nell’ecosistema RMM (Remote Monitoring and Management) usato dagli MSP per intervenire da remoto sui PC e server dei clienti. La falla identificata come CVE-2026-84869 riguarda il client ScreenConnect, non il server: secondo il bollettino ufficiale del produttore, in determinate circostanze i file possono essere trasferiti ed eseguiti attraverso una sessione remota attiva senza autorizzazione né conferma da parte dell’host. In pratica, chi ha già accesso a una sessione con privilegi minimi può forzare l’esecuzione di codice arbitrario sulla macchina collegata, senza che l’utente clicchi nulla e senza popup di conferma.
Il vettore CVSS 3.1 pubblicato è AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, che tradotto significa: attacco sfruttabile da rete, bassa complessità, privilegi bassi richiesti, nessuna interazione dell’utente necessaria, impatto scope-changed (l’attaccante esce dal perimetro del proprio contesto) e compromissione totale di confidenzialità, integrità e disponibilità. Il risultato è un CVSS 9,9, uno dei punteggi più alti registrati quest’anno per uno strumento di gestione remota, appena sotto il tetto teorico di 10. La classificazione tecnica assegnata è “Improper Privilege Management and Missing Authorization”, una doppia etichetta che riflette due problemi concomitanti: mancano controlli sui privilegi di chi avvia il trasferimento file, e manca un passaggio di autorizzazione esplicita prima dell’esecuzione.
ConnectWise ha specificato che i server ScreenConnect non sono coinvolti: il problema riguarda esclusivamente il comportamento del client durante le sessioni di accesso e supporto remoto, comprese sia le installazioni cloud sia quelle on-premise. Questo dettaglio è importante per chi deve dare priorità alla risposta: non basta verificare la versione del server, occorre aggiornare e ridistribuire gli agent client su ogni singolo endpoint gestito.
La cronologia: da fine agosto alla scadenza CISA del 14 settembre
La sequenza degli eventi aiuta a capire quanto velocemente si sia mossa la vicenda. Secondo l’azienda di sicurezza Huntress, lo sfruttamento attivo è iniziato attorno al 20 agosto 2026, con almeno tre incidenti distinti individuati nelle settimane successive. ConnectWise ha pubblicato il bollettino di sicurezza e la versione corretta, ScreenConnect 26.6.5, l’8 settembre 2026. CISA ha aggiunto la falla al catalogo KEV l’11 settembre, insieme ad altre vulnerabilità critiche in GitLab e JFrog Artifactory, imponendo alle agenzie federali statunitensi una finestra di appena tre giorni per applicare la patch, come riportano The Hacker News e Security Affairs. La scadenza di remediation per gli enti federali è quindi caduta il 14 settembre 2026, appena un giorno prima della pubblicazione di questo articolo.
Tre giorni di finestra sono un tempo estremamente ridotto per qualsiasi organizzazione, figuriamoci per un MSP che gestisce decine o centinaia di clienti con configurazioni diverse. La direttiva vincolante che regola queste scadenze per gli enti federali USA, la BOD 26-04, riflette una valutazione di rischio molto alta da parte di CISA: quando l’agenzia stringe i tempi a questo modo, di norma è perché lo sfruttamento è già diffuso e non più teorico. In questo caso la conferma arriva direttamente dalla documentazione tecnica pubblicata da Computerworld, che nota come ConnectWise abbia rilasciato la patch cinque giorni dopo la scoperta iniziale del problema, un tempo di reazione comunque rapido per un vendor delle dimensioni di ConnectWise.
Come funziona l’attacco: la catena VBScript in quattro fasi
La parte più interessante, dal punto di vista tecnico, non è la falla in sé ma il modo in cui è stata sfruttata sul campo. Secondo l’analisi pubblicata da Huntress e ripresa da The Hacker News, gli attaccanti hanno usato tre metodi di accesso iniziale completamente diversi tra loro: una truffa di supporto tecnico via Quick Assist, un installer MSI diffuso tramite phishing, e un falso modulo di rimborso a marchio Geek Squad. Nonostante l’ingresso vari, il payload finale è identico: una catena di quattro script VBScript, numerati semplicemente da 1.vbs a 4.vbs, che vengono eseguiti in sequenza tramite Windows Script Host.
Il primo script profila la macchina infetta: controlla se ScreenConnect è già installato, cataloga i prodotti di sicurezza attivi e verifica la quantità di RAM disponibile, un accorgimento comune per distinguere un vero endpoint aziendale da una macchina virtuale usata da un analista malware. Gli script successivi scaricano payload cifrati ospitati su Dropbox e installano un client ScreenConnect modificato, strumenti per il bypass dello User Account Control e l’escalation di privilegi, utility di tunneling per il movimento laterale e, in diversi casi osservati, il miner di criptovalute XMRig.
Il dettaglio che rende questa campagna un vero “worm” e non un semplice attacco mirato è il meccanismo di propagazione: un client ScreenConnect già compromesso può trasferire ed eseguire in automatico la stessa catena di quattro script su qualunque nuovo endpoint a cui si connette. In altre parole, basta che un tecnico MSP apra una sessione di supporto verso un cliente pulito usando una postazione già infetta perché la catena di infezione si propaghi, senza bisogno di ulteriore interazione umana o di un nuovo vettore di accesso iniziale. È esattamente questo comportamento a spiegare il punteggio CVSS quasi massimo: non è solo una vulnerabilità grave sulla carta, è una vulnerabilità che si autoalimenta all’interno dell’infrastruttura di gestione remota.
Perché gli MSP europei e italiani sono il bersaglio ideale
ScreenConnect non è un prodotto di nicchia: è tra gli strumenti RMM più diffusi tra i managed service provider di piccole e medie dimensioni, la categoria di aziende che in Italia gestisce l’IT per gran parte delle PMI prive di un reparto interno dedicato. Un MSP tipico ha accesso privilegiato a decine, a volte centinaia, di reti clienti attraverso un’unica piattaforma centralizzata. È l’architettura stessa a creare il problema: la stessa capacità che rende ScreenConnect utile per il supporto legittimo, accesso pervasivo e a basso attrito su molte macchine diverse, diventa, in caso di compromissione, un moltiplicatore di danno.
La stampa italiana e la comunità MSP nazionale avevano già segnalato in passato problematiche di trasferimento file non autorizzato su ScreenConnect, raccomandando come mitigazione provvisoria la disattivazione dei permessi TransferFiles e TransferFilesInSession per i ruoli che non ne hanno bisogno operativo. Con CVE-2026-84869 quella raccomandazione informale diventa una misura di mitigazione ufficiale, indicata dallo stesso ConnectWise come palliativo temporaneo per chi non può aggiornare immediatamente tutti gli agent distribuiti.
Va detto con chiarezza, per rispettare l’evidenza disponibile: al momento non esistono conteggi ufficiali di istanze ScreenConnect esposte via Shodan o Censys collegati a questo CVE specifico, né sono stati pubblicati numeri di vittime italiane confermate. Le fonti consultate non riportano nemmeno l’attribuzione a un gruppo ransomware con un nome noto: il linguaggio usato da CISA, da Huntress e dagli altri analisti resta generico (“attori malevoli”, “campagna worm-like”), senza collegamenti a marchi ransomware già noti in Italia come Qilin, Akira o DragonForce. Questo non riduce la gravità tecnica del problema, ma è corretto non gonfiare i numeri oltre quanto documentato.
Il confronto con altri incidenti nel mondo RMM: Kaseya come precedente
Chi segue la sicurezza degli strumenti di gestione remota da qualche anno riconoscerà subito lo schema. Nel 2021 una vulnerabilità nella piattaforma VSA di Kaseya fu sfruttata dal gruppo ransomware REvil per colpire in un colpo solo centinaia di aziende a valle, sfruttando proprio il rapporto di fiducia tra MSP e clienti gestiti. Quell’incidente resta il punto di riferimento quando si parla di rischio sistemico legato agli strumenti RMM, per la scala dell’impatto a cascata che generò in tutto il mondo.
CVE-2026-84869 condivide con il precedente Kaseya la logica di fondo, il compromesso di un singolo canale di gestione che si traduce in accesso a molte reti diverse, ma non, finora, la scala documentata. Kaseya coinvolse un difetto lato server sfruttabile con autenticazione limitata su larga scala; ScreenConnect richiede invece una sessione remota già attiva, il che restringe la superficie di attacco iniziale ma non elimina il rischio di propagazione interna una volta ottenuto un primo punto d’appoggio. La tabella seguente mette a confronto gli elementi chiave dei due casi, sulla base dei dati pubblicamente disponibili.
| Caratteristica | Kaseya VSA (2021) | ConnectWise ScreenConnect (2026) |
|---|---|---|
| CVE / gravità | CVE-2021-30116 e correlate | CVE-2026-84869, CVSS 9,9 |
| Componente colpito | Server VSA on-premise | Client ScreenConnect (server non impattato) |
| Prerequisito d’accesso | Accesso di rete al server VSA | Sessione remota attiva con privilegi bassi |
| Attore collegato | Gruppo ransomware REvil (confermato) | Nessun gruppo nominato nelle fonti pubbliche |
| Meccanismo di propagazione | Distribuzione malevola tramite agent centralizzato | Client compromesso che infetta nuovi endpoint connessi |
| Tempo di risposta del vendor | Giorni, sotto forte pressione mediatica | 5 giorni dalla scoperta alla patch (26.6.5) |
| Scadenza di remediation federale USA | Non regolata da KEV (KEV nato nel 2021) | 3 giorni dalla notifica CISA (BOD 26-04) |
Il paragone con altri strumenti di accesso remoto come TeamViewer o AnyDesk è meno diretto: in quei casi la maggior parte degli incidenti noti è nata da furto di credenziali o abuso di configurazioni permissive, non da una falla di privilegio nel codice del client come in questo caso. CVE-2026-84869 è più vicino, per struttura tecnica, a un difetto di progettazione del prodotto che a un errore di configurazione lato utente, il che sposta parte della responsabilità di rimedio dal cliente finale al vendor e ai suoi partner MSP.
La risposta di ConnectWise: patch, versioni e mitigazioni
ConnectWise ha reagito pubblicando un bollettino di sicurezza datato 8 settembre 2026 in cui descrive il problema come “a condition in the ScreenConnect client that may allow files to be transferred and executed through an active remote session without authorization or Host confirmation in certain circumstances”, specificando esplicitamente che “ScreenConnect servers are not impacted”. La versione corretta è la 26.6.5 (alcuni feed di sicurezza indicano il build completo 26.6.5.9742 come riferimento per la remediation totale). Le distribuzioni cloud sono state aggiornate automaticamente dal vendor; per le installazioni on-premise, invece, resta a carico del partner MSP l’aggiornamento del server e, soprattutto, la reinstallazione o l’aggiornamento degli agent client su ogni endpoint gestito.
Questo secondo passaggio è quello su cui si concentra il rischio operativo maggiore. Aggiornare un server centrale è un’operazione singola e veloce; aggiornare centinaia di client distribuiti su reti clienti eterogenee, con orari di manutenzione diversi e in alcuni casi con accesso fisico limitato, richiede giorni o settimane anche per un MSP organizzato. Nel frattempo, la mitigazione temporanea raccomandata resta la disattivazione dei permessi di trasferimento file (TransferFiles e TransferFilesInSession) per i ruoli non essenziali, una misura che riduce la superficie di attacco senza richiedere un intervento immediato su ogni singola macchina.
ConnectWise ha inoltre pubblicato la vulnerabilità come disclosure ufficiale tramite il proprio repository di advisory, un passaggio di trasparenza che, insieme alla velocità di rilascio della patch, gli analisti di settore valutano positivamente rispetto a precedenti gestioni di incidenti simili nel comparto RMM.
L’impatto di mercato: fiducia, contratti e concorrenza tra piattaforme RMM
Per un’azienda come ConnectWise, che vende ScreenConnect come componente di una suite più ampia di strumenti per MSP, un CVSS 9,9 con sfruttamento attivo confermato prima della patch pesa sulla percezione di affidabilità del prodotto, indipendentemente dalla velocità della risposta tecnica. Gli MSP scelgono le piattaforme RMM anche in base alla fiducia che possono trasferire ai propri clienti finali: un incidente di questa portata, per quanto risolto rapidamente, alimenta discussioni su alternative come Kaseya VSA (nonostante il precedente 2021), Datto RMM, Atera o NinjaOne, tutte piattaforme che competono sullo stesso segmento di mercato europeo delle PMI gestite.
Nel breve termine, il costo più concreto per gli MSP non è tanto la sostituzione dello strumento quanto le ore di lavoro straordinario necessarie per applicare la patch su tutta la base clienti in una finestra ristretta, verificare eventuali compromissioni pregresse a partire da fine agosto e comunicare in modo trasparente ai clienti finali cosa è successo. Per i clienti finali delle PMI italiane, spesso ignari di quale software RMM il proprio fornitore IT utilizzi, l’incidente resta invisibile fino a quando non si traduce in un disservizio o, nel peggiore dei casi, in una violazione di dati a valle.
Contesto storico: una vulnerabilità in un settore già sotto pressione
Il 2026 è stato un anno particolarmente intenso per le vulnerabilità critiche in strumenti aziendali di larga diffusione. Solo nelle ultime settimane il catalogo CISA KEV ha accolto falle critiche in prodotti come JFrog Artifactory (CVE-2026-82329, CVSS 9,8), GitLab e diverse componenti Microsoft, in un ritmo di aggiunte che riflette sia una maggiore capacità di rilevamento sia un’attività offensiva più aggressiva contro l’infrastruttura software delle aziende. Gli strumenti RMM, in particolare, restano un obiettivo strutturalmente attraente per gli attaccanti perché offrono, per progettazione, un accesso privilegiato e persistente a più reti contemporaneamente: è la stessa logica che rese Kaseya VSA un bersaglio nel 2021 e che oggi riguarda ScreenConnect.
La tabella seguente riassume la cronologia essenziale dell’incidente, utile per chi deve ricostruire la tempistica in un rapporto interno di incident response.
| Data | Evento |
|---|---|
| 20 agosto 2026 (circa) | Inizio dello sfruttamento attivo osservato da Huntress |
| Fine agosto 2026 | Identificati almeno 3 incidenti distinti con vettori di accesso iniziale diversi |
| 8 settembre 2026 | ConnectWise pubblica il bollettino di sicurezza e rilascia ScreenConnect 26.6.5 |
| 11 settembre 2026 | CISA aggiunge CVE-2026-84869 al catalogo Known Exploited Vulnerabilities |
| 14 settembre 2026 | Scadenza di remediation obbligatoria per le agenzie federali USA (BOD 26-04) |
| 15 settembre 2026 | Analisi e reportistica di settore in corso, patch disponibile e mitigazioni pubblicate |
Cosa devono fare adesso gli MSP e i clienti finali
Le priorità operative indicate da ConnectWise e riprese dagli analisti di settore si possono riassumere in pochi passaggi concreti. Primo, aggiornare immediatamente il server ScreenConnect on-premise alla versione 26.6.5 o successiva, anche se le installazioni cloud sono già state aggiornate automaticamente dal vendor. Secondo, ridistribuire o aggiornare tutti gli agent client attivi sugli endpoint gestiti, perché il server aggiornato da solo non chiude la falla lato client. Terzo, disattivare temporaneamente i permessi di trasferimento file per i ruoli che non ne hanno un bisogno operativo stretto, come misura ponte fino al completamento del rollout.
Quarto, e spesso trascurato: verificare retroattivamente i log delle sessioni ScreenConnect a partire da fine agosto 2026, cercando pattern coerenti con la catena descritta da Huntress, come l’esecuzione di script denominati in sequenza numerica tramite Windows Script Host o connessioni a servizi di hosting file come Dropbox non riconducibili all’attività normale del team di supporto. Quinto, per chi gestisce clienti regolamentati (settore sanitario, finanziario, pubblica amministrazione), documentare formalmente la finestra di esposizione e le azioni correttive intraprese, un passaggio che diventa rilevante anche ai fini degli obblighi di notifica previsti dal quadro normativo NIS2 in vigore negli Stati membri UE.
Previsioni: cosa aspettarsi nelle prossime settimane
Sulla base della cronologia osservata finora, è ragionevole aspettarsi alcuni sviluppi. Primo, è probabile che nelle prossime settimane emergano rapporti di incident response che collegano casi concreti di compromissione ScreenConnect a estorsioni ransomware, dato lo schema di propagazione che favorisce proprio questo tipo di monetizzazione una volta ottenuto l’accesso a più reti clienti. Secondo, è plausibile un aumento delle richieste di audit di sicurezza specifiche per le piattaforme RMM da parte dei clienti enterprise verso i propri MSP, sulla scia della maggiore attenzione mediatica generata da questo incidente.
Terzo, ConnectWise dovrà probabilmente affrontare un periodo di scrutinio rafforzato sulla sicurezza dell’intera suite di prodotti, non solo di ScreenConnect, un pattern già visto con altri vendor colpiti da vulnerabilità critiche ad alto profilo. Quarto, è ragionevole attendersi che CISA e i CERT nazionali europei pubblichino ulteriori bollettini di follow-up se emergeranno nuove varianti della catena VBScript o nuovi vettori di accesso iniziale oltre ai tre già documentati da Huntress. Quinto, nel medio periodo è probabile una spinta regolatoria, soprattutto in ambito UE, verso requisiti di sicurezza più stringenti per i fornitori di strumenti RMM classificati come componenti critiche della supply chain digitale delle PMI, un tema già presente nel dibattito attorno al Cyber Resilience Act.
Il quadro competitivo tra strumenti RMM dopo l’incidente
ScreenConnect non opera in un mercato senza alternative. Kaseya VSA, dopo il precedente del 2021, ha investito pesantemente in hardening e certificazioni di sicurezza; Datto RMM, oggi parte del gruppo Kaseya, punta su un’architettura cloud-native con minore superficie on-premise; NinjaOne e Atera si posizionano come alternative più recenti, spesso scelte da MSP di dimensioni più piccole proprio per la promessa di una gestione degli agent più semplice da aggiornare in blocco. Nessuna di queste piattaforme è immune per definizione da vulnerabilità simili: la storia recente del settore RMM suggerisce che il rischio strutturale è legato alla categoria di prodotto, non a un singolo vendor.
Quello che distingue la risposta di un vendor dall’altro, in casi come questo, è la velocità di comunicazione, la chiarezza delle istruzioni di mitigazione e la trasparenza sui numeri di sfruttamento reale. Su questi tre fronti, la gestione di ConnectWise, patch in 5 giorni, bollettino pubblico dettagliato, mitigazione temporanea chiaramente indicata, si colloca nella fascia alta rispetto ad altri incidenti RMM osservati negli ultimi anni, anche se questo non cancella il rischio già corso dai clienti compromessi tra fine agosto e l’8 settembre.
Domande frequenti
Cos’è CVE-2026-84869?
È una vulnerabilità critica (CVSS 9,9) nel client di ConnectWise ScreenConnect che permette il trasferimento e l’esecuzione di file non autorizzati durante una sessione di accesso remoto attiva, senza conferma da parte dell’host.
Il server ScreenConnect è vulnerabile?
No. Secondo il bollettino ufficiale di ConnectWise, il problema riguarda esclusivamente il comportamento del client durante le sessioni remote; i server ScreenConnect non sono impattati direttamente.
Da quando è sfruttata attivamente questa falla?
Secondo Huntress, lo sfruttamento attivo risale almeno al 20 agosto 2026, con tre incidenti distinti identificati nelle settimane successive, prima ancora della pubblicazione della patch l’8 settembre.
Quale versione risolve il problema?
ScreenConnect 26.6.5 (alcuni feed indicano il build 26.6.5.9742 come riferimento completo). Le installazioni cloud sono state aggiornate automaticamente; quelle on-premise richiedono un aggiornamento manuale del server e degli agent client.
Esiste una mitigazione se non posso aggiornare subito?
Sì, disattivare i permessi TransferFiles e TransferFilesInSession per i ruoli non essenziali riduce la superficie di attacco fino al completamento dell’aggiornamento.
È collegata a un gruppo ransomware noto?
Le fonti pubbliche consultate, incluse CISA e Huntress, non attribuiscono al momento la campagna a un gruppo ransomware nominato: il linguaggio usato resta generico (“attori malevoli”, attività “worm-like”).
Quanti sistemi sono esposti in Europa o in Italia?
Non esistono al momento conteggi ufficiali pubblici di istanze esposte tramite Shodan o Censys collegati specificamente a questo CVE, né dati confermati su vittime italiane.
In cosa differisce da Kaseya VSA 2021?
Kaseya richiedeva l’accesso al server VSA ed è stata sfruttata dal gruppo REvil su scala globale; CVE-2026-84869 richiede una sessione remota già attiva sul client e si propaga da endpoint a endpoint tramite client compromessi, senza al momento un’attribuzione a un gruppo ransomware specifico.
