Cosa è successo

Il 27 ottobre 2026 TeamViewer ha pubblicato il bollettino TV-2026-1011 e la versione 15.83, che corregge tre vulnerabilità di gravità alta. La più discussa è la CVE-2026-111585 (CVSS 8.8): un integer overflow nell'elaborazione dello schermo durante le sessioni di controllo remoto. Il ricercatore Omri Dar di Remedio, che l'aveva segnalata il 14 agosto, ne ha pubblicato l'analisi tecnica il 29 ottobre; TeamViewer aveva confermato il problema il 22 ottobre.

La particolarità è la direzione dell'attacco, rovesciata rispetto all'immaginario comune. Di solito si teme che un attaccante si colleghi al computer della vittima. Qui è il contrario: l'host controllato dall'attaccante (o un host compromesso) attacca il viewer, cioè la persona che si collega per fare assistenza. Nella fase di sessione l'host comunica le dimensioni del proprio schermo; il viewer le usa per calcolare quanta memoria riservare, ma il calcolo, fatto con una moltiplicazione a 32 bit, può andare in overflow. Con dimensioni enormi (nell'analisi si cita uno schermo da 32.768 × 32.768 pixel) il programma alloca circa 4 MB, ma poi elabora i dati come se lo spazio fosse sufficiente: il risultato è un heap buffer overflow.

Nel caso minimo l'effetto è un crash della sessione del viewer, ripetibile a piacere dall'host. Su Windows, Remedio sostiene di essere riuscita ad aggirare DEP e CFG e a eseguire codice arbitrario sulla macchina del tecnico; la dimostrazione si è appoggiata a un componente di supporto sull'host per fornire parte dei dati, quindi non è ancora un attacco interamente via rete. Non è chiaro se funzioni anche su macOS, Linux e Android: secondo TeamViewer l'esecuzione di codice dipende dalla piattaforma. Non servono password né clic ulteriori oltre ad accettare la sessione, e la configurazione predefinita è vulnerabile.

Stato dello sfruttamento e versioni

TeamViewer dichiara di non conoscere attacchi in corso; la falla non risultava nel catalogo CISA KEV al 29 ottobre e Remedio non ha pubblicato codice di exploit. Non è quindi un'emergenza da zero-day, ma una falla con un'analisi tecnica pubblica: il tempo tra "descrizione dettagliata" e "exploit funzionante" è tipicamente breve.

La CVE-2026-111585 colpisce il Full Client (incluso Portable) per Windows, Linux e macOS e l'app Android Remote Control nelle versioni precedenti alla 15.83, oltre ai rami legacy 15.64 (Windows), 14.7 e 13.2. Lo stesso bollettino corregge:

  • CVE-2026-92372 (CVSS 8.8): scrittura fuori dai limiti nel decoder delle immagini dello schermo su Linux e macOS, sfruttabile anche con una registrazione di sessione .tvs appositamente creata (richiede interazione dell'utente);
  • CVE-2026-92374 (CVSS 7.8): escalation di privilegi a root in locale su macOS tramite una race condition nell'helper privilegiato.

Le build corrette: 15.83 per Full Client, Host, Portable e app Android; 15.64.10 per il ramo 15.64 su Windows 7 e 8; 14.7.48868 per il ramo 14.7; 13.2.36231 (Windows), 13.2.154008 (Linux) e 13.2.154007 (macOS) per il ramo 13.2. Un bollettino complementare, TV-2026-1012, riguarda sei falle nei componenti add-on di Remote Management, distribuiti con aggiornamento automatico.

Cosa significa per le aziende italiane

Il bersaglio ideale di questa falla non è l'utente finale ma chi lavora nell'assistenza: help desk interni, MSP, fornitori IT che gestiscono parchi di PMI, studi professionali con il "tecnico di fiducia". Sono postazioni che, per mestiere, si collegano a macchine altrui e spesso hanno privilegi elevati, credenziali di molti clienti e accesso a console di amministrazione. Comprometterne una vale più che comprometterne cento utenti.

Il ragionamento da fare è quello della catena di fornitura. Per un MSP italiano una postazione tecnica compromessa è un ponte verso tutti i clienti gestiti: lo scenario per cui NIS2 chiede di valutare la sicurezza dei fornitori e la gestione delle terze parti, e per cui il GDPR impone, a chi tratta dati per conto di altri, misure adeguate (art. 32). Se un incidente partito dal PC di un tecnico espone dati personali dei clienti, il fornitore deve informare tempestivamente i titolari, che a loro volta valutano la notifica al Garante entro 72 ore.

Uno scenario concreto: un finto cliente apre un ticket e chiede supporto urgente avviando TeamViewer sul proprio host modificato. Il tecnico, abituato ad accettare, ottiene una sessione "normale" e, con la versione vulnerabile, il suo PC può essere compromesso. Non serve nessun malware inviato via email, e per questo i controlli classici sul phishing non lo intercettano.

Cosa fare subito

  • Aggiornare TeamViewer a 15.83 (o alla build corretta del ramo che usate) su tutte le postazioni, dando priorità ai tecnici di supporto, e sui dispositivi Android usati per il controllo remoto. Verificate anche gli Host, che beneficiano delle altre due correzioni.
  • Fare l'inventario delle installazioni: molte aziende hanno TeamViewer su PC dimenticati o in versione Portable, non gestiti dal sistema di patching.
  • Accettare sessioni solo da controparti attese e verificate, tramite ticket o canale ufficiale; istruire il personale a non accettare richieste di supporto da sconosciuti.
  • Isolare le postazioni dei tecnici: privilegi minimi, utente non amministratore per le attività quotidiane, segmentazione di rete e credenziali separate per i clienti.
  • Monitorare processi figli anomali avviati dal client TeamViewer (shell, PowerShell, script) con l'EDR: sono un indicatore di tentata esecuzione di codice.
  • Nei contratti con i fornitori IT, chiedere conferma dell'aggiornamento e delle misure sulle postazioni di assistenza, soprattutto se operano per un soggetto NIS2.

Nota metodologica

I dettagli tecnici derivano dal bollettino ufficiale TeamViewer e dall'analisi riportata da The Hacker News e da Hackread. L'esecuzione di codice è stata dimostrata dal ricercatore su Windows con un setup specifico; per le altre piattaforme non ci sono conferme. Aggiorneremo l'articolo in caso di sfruttamento attivo o di aggiunta al catalogo KEV.