Una falla critica di ScreenConnect alimenta attacchi simili a worm attraverso sessioni remote attive

ConnectWise ha rilasciato un aggiornamento di sicurezza urgente per CVE-2026-84869, una vulnerabilità critica del client ScreenConnect già sfruttata attivamente.

In determinate condizioni, la falla consente a un attaccante di trasferire ed eseguire file attraverso una sessione remota attiva di ScreenConnect senza un’autorizzazione adeguata o la conferma dell’host. Huntress ha rilevato attività di exploit dal 20 agosto, inclusi attacchi che hanno utilizzato client ScreenConnect compromessi o malevoli per distribuire payload ad altri client connessi.

La vulnerabilità ha ottenuto un punteggio CVSS v3 di 9,9. CISA l’ha aggiunta al catalogo delle vulnerabilità sfruttate note l’11 settembre 2026, fissando al 14 settembre 2026 la scadenza per la risoluzione da parte delle agenzie federali statunitensi.

Sono vulnerabili i client ScreenConnect precedenti alla build 26.6.5.9742

Il componente vulnerabile è il client ScreenConnect. Secondo la scheda NVD, i server ScreenConnect non sono interessati da questa specifica condizione di sicurezza.

Le informazioni sulla versione sono espresse con livelli di precisione diversi. ConnectWise identifica ScreenConnect 26.6.5 come la release che contiene la correzione, mentre NVD indica come vulnerabili le versioni precedenti a 26.6.5.9742.

Gli amministratori dovrebbero quindi verificare la build completa installata, anziché basarsi esclusivamente sulla release funzionale visualizzata. La soglia di sicurezza è ScreenConnect 26.6.5.9742 o una versione successiva.

La vulnerabilità è associata a due categorie di debolezze:

• CWE-269 — Gestione impropria dei privilegi
• CWE-862 — Autorizzazione mancante

Il vettore CVSS di NVD è:

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

Il vettore descrive una falla raggiungibile dalla rete, con bassa complessità di attacco. Lo sfruttamento richiede privilegi bassi, ma non l’interazione dell’utente che controlla l’host preso di mira. Il cambiamento dell’ambito indica che uno sfruttamento riuscito può oltrepassare un confine di sicurezza, mentre gli impatti su riservatezza, integrità e disponibilità sono tutti classificati come elevati.

ConnectWise afferma che il client corretto rafforza la gestione delle sessioni per le operazioni di trasferimento ed esecuzione dei file.

Gli attaccanti trasformano le sessioni affidabili in percorsi di propagazione

La campagna osservata inizia con l’ingegneria sociale. Gli attaccanti convincono le vittime a eseguire client ScreenConnect contraffatti, ottenendo il punto d’appoggio iniziale necessario per abusare delle relazioni di supporto remoto attive.

Secondo le informazioni basate sulle osservazioni di Huntress, un’istanza modificata di ScreenConnect distribuisce quindi quattro file VBScript. Gli script sono progettati per creare persistenza e contribuire alla diffusione del payload verso altri client ScreenConnect.

I client malevoli verificano la disponibilità di sessioni remote attive. Quando individuano sistemi connessi, gli attaccanti sfruttano il comportamento vulnerabile di trasferimento ed esecuzione per inviare i payload VBScript attraverso tali sessioni.

È per questo che l’attività è stata definita simile a un worm. Un client compromesso o controllato dall’attaccante può utilizzare le connessioni ScreenConnect esistenti per raggiungere altri sistemi, estendendo l’intrusione attraverso relazioni che gli amministratori potrebbero altrimenti considerare affidabili.

La descrizione non dimostra che il malware sia un worm di rete completamente autonomo. La compromissione iniziale coinvolge l’ingegneria sociale e la propagazione dipende dalle sessioni ScreenConnect attive. Tuttavia, la possibilità di spostarsi da un client ad altri client connessi può accelerare la compromissione negli ambienti di supporto remoto.

I managed service provider, gli help desk, gli amministratori IT e le organizzazioni con numerose relazioni tra sessioni ScreenConnect sono esposti a un rischio operativo particolarmente elevato. Un singolo client malevolo può diventare un punto di distribuzione quando entra in contatto con altri client attivi.

L’esecuzione non autorizzata può compromettere interi ambienti di supporto

Uno sfruttamento riuscito può consentire a un attaccante di collocare ed eseguire file selezionati sui sistemi associati a sessioni vulnerabili del client ScreenConnect. Le conseguenze immediate possono includere la persistenza, l’ulteriore distribuzione di malware o l’espansione verso endpoint aggiuntivi.

L’elevata valutazione dell’impatto sulla riservatezza riflette la potenziale esposizione dei dati accessibili dai sistemi compromessi. L’impatto sull’integrità comprende la modifica e l’esecuzione non autorizzate, mentre la valutazione della disponibilità tiene conto della possibilità di interruzioni o attività distruttive.

Nello scenario vulnerabile non è richiesta alcuna conferma sull’host. Questa caratteristica riduce la possibilità che un utente dell’endpoint o un tecnico interrompa un trasferimento malevolo prima dell’esecuzione.

I software di accesso remoto occupano inoltre una posizione sensibile nelle reti aziendali. Collegano operatori, endpoint e infrastrutture di supporto oltre i confini organizzativi. Abusare di questi canali già instaurati può consentire a un attaccante di confondere l’attività malevola con la normale amministrazione e di raggiungere sistemi non esposti direttamente a Internet.

CISA indica come sconosciuto l’uso a fini di ransomware. Non esistono quindi basi confermate per descrivere lo sfruttamento osservato di ScreenConnect come una campagna ransomware.

CISA impone l’applicazione delle patch e il triage forense

CISA ha inserito CVE-2026-84869 nel proprio catalogo delle vulnerabilità sfruttate note l’11 settembre 2026. L’inclusione conferma che la vulnerabilità non è soltanto teorica: sono stati documentati casi di sfruttamento.

La scadenza federale per la risoluzione è il 14 settembre 2026. CISA indica inoltre il triage forense come obbligatorio ai sensi della Binding Operational Directive 26-04, «Prioritizing Security Updates Based on Risk».

Le agenzie federali devono applicare le mitigazioni del fornitore rispettando i requisiti di applicazione delle patch e di triage forense previsti dalla BOD 26-04. Devono inoltre valutare l’esposizione a Internet degli asset interessati. Per i servizi cloud, le organizzazioni devono rispettare i requisiti applicabili della direttiva oppure interromperne l’utilizzo quando non sono disponibili mitigazioni efficaci.

Le organizzazioni del settore privato non sono vincolate dalla scadenza federale, ma gli stessi elementi operativi restano validi. Lo sfruttamento è in corso, la propagazione può avvenire attraverso client connessi e la sola applicazione delle patch potrebbe non rivelare se un sistema sia stato compromesso in precedenza.

Nel registro verificato disponibile non è stato individuato alcun precedente recente nella KEV specificamente collegato a ConnectWise. Questo caso non dovrebbe quindi essere presentato come parte di una serie documentata di recenti inserimenti nella KEV che riguardano il fornitore.

Prima applicare la patch, poi esaminare le sessioni attive e storiche

Le organizzazioni dovrebbero aggiornare i client ScreenConnect alla build 26.6.5.9742 o successiva. Quando non è possibile procedere subito alla distribuzione, ConnectWise consiglia di disabilitare l’autorizzazione TransferFiles fino al completamento dell’aggiornamento.

Una risposta pratica dovrebbe includere i seguenti passaggi:

1. Inventariare i client ScreenConnect e le build esatte. Identificare ogni client precedente a 26.6.5.9742, inclusi i sistemi gestiti da terze parti o utilizzati saltuariamente per attività di supporto.

2. Installare la release corretta. Verificare che la build risultante raggiunga o superi la soglia indicata da NVD, invece di controllare soltanto la denominazione più generica della release 26.6.5.

3. Disabilitare TransferFiles se l’applicazione della patch è rimandata. Considerare questa misura una mitigazione temporanea, non un sostituto dell’aggiornamento.

4. Esaminare le sessioni remote attive e recenti. Cercare connessioni impreviste, relazioni insolite tra sessioni e client che comunicano con sistemi esterni ai normali schemi di supporto.

5. Indagare sui trasferimenti e sulle esecuzioni non autorizzati. Esaminare l’attività di ScreenConnect alla ricerca di file inviati senza un’attività amministrativa prevista o l’approvazione dell’host.

6. Cercare meccanismi di persistenza basati su VBScript. Huntress ha osservato quattro payload VBScript, ma i relativi nomi dei file, hash e altri indicatori concreti non sono stati divulgati. I difensori devono quindi basarsi su ricerche comportamentali, telemetria sull’esecuzione degli script, modifiche alla persistenza e cronologia delle sessioni.

7. Esaminare i binari dei client ScreenConnect. Client imprevisti, modificati o introdotti di recente possono indicare la fase di ingegneria sociale o una distribuzione controllata dall’attaccante.

8. Ricostruire la possibile propagazione. Se un client appare compromesso, esaminare ogni client ScreenConnect connesso a esso durante le sessioni interessate.

9. Eseguire il triage forense prima di chiudere l’incidente. CISA richiede esplicitamente il triage alle agenzie interessate; anche le altre organizzazioni dovrebbero conservare log e prove sugli endpoint prima che la remediation cancelli tracce utili.

L’aggiornamento elimina la condizione di vulnerabilità, ma non rimuove i payload già distribuiti attraverso sessioni precedenti. Qualsiasi organizzazione che utilizzi una build interessata dovrebbe considerare l’applicazione delle patch e la verifica della compromissione come attività parallele.