// 2 ZERO-DAY · 6 CVE · 7 EXPLOIT · 1 ADVISORY NELLE ULTIME 24H→
Ricercatori hanno rilasciato AnyPwn, exploit pre-autenticazione per AnyDesk Linux che ottiene root. AnyDesk aveva corretto il bug in giugno 2026 senza CVE né

Il 9 ottobre 2026 ricercatori hanno pubblicato il codice completo di AnyPwn, un exploit pre-autenticazione per AnyDesk Linux che esegue codice remoto con privilegi di root. La pubblicazione rende praticabile un attacco teorizzato già a giugno, quando AnyDesk rilasciò la versione 8.0.3 con una descrizione minimale del problema. Il vendor non ha mai assegnato un CVE né emesso un advisory di sicurezza formale, lasciando gli amministratori senza indicazioni sulla gravità reale della falla.

Punti chiave
  • L'exploit AnyPwn permette RCE come root su AnyDesk Linux senza richiedere approvazione della connessione
  • Il bug è stato corretto silenziosamente in AnyDesk 8.0.3 a giugno 2026, ma il changelog descriveva solo un crash potenziale
  • L'exploit è probabilistico: dipende dal layout heap della build 8.0.2 target, con offset specifici che necessitano ricalibrazione per altre versioni
  • Non esiste CVE assegnato né advisory di sicurezza formale da parte di AnyDesk al 9 ottobre 2026

Il meccanismo: da integer overflow a heap corruption

La vulnerabilità risiede nel protocollo di sessione AnyDesk, nello specifico nei cosiddetti mode-5 stream packets. Il calcolo della dimensione di allocazione memoria avviene con aritmetica a 32 bit senza controllo di overflow: il codice somma 16 byte di header alla lunghezza del payload, entrambi in un intero senza segno a 32 bit. Quando il payload dichiarato è 0xFFFFFFF0, la somma con 0x10 produce un wrap a zero, allocando un buffer minimo mentre il sistema registra la lunghezza originale.

Ogni byte scritto dall'attaccante eccede così i confini del buffer allocato, generando un heap buffer overflow. Questa corruzione di oggetti adiacenti nel layout heap consente di costruire una ROP chain per l'esecuzione arbitraria di comandi con privilegi di root. Il servizio AnyDesk su Linux gira infatti con permessi elevati, rendendo la compromissione completa del sistema il risultato naturale dell'exploit riuscito.

L'exploit pubblicato è tuttavia probabilistico: la riuscita dipende dalla presenza di un oggetto target adiacente al buffer corrotto nello specifico layout heap del processo. Se questa condizione non si verifica, il servizio termina con un crash. Gli offset nel codice rilasciato sono tarati sulla build specifica di AnyDesk Linux 8.0.2; altre build richiedono ricalibrazione manuale.

La timeline di un silenzio: da giugno a ottobre senza CVE

La vulnerabilità è stata scoperta da Rick de Jager del team V12 security, che utilizzò l'engine di code review V12 per identificare il percorso vulnerabile. Il 22 giugno 2026 i ricercatori annunciarono pubblicamente la falla; AnyDesk rispose il giorno successivo con il rilascio della versione 8.0.3. Il changelog di quella versione descriveva la correzione come "fixed a bug that could lead to a crash".

"fixed a bug that could lead to a crash" — AnyDesk changelog, versione 8.0.3 (giugno 2026)

La formulazione minimizzò la natura pre-autenticazione dell'exploit e ometteva qualsiasi riferimento a RCE o privilegi root. Al 9 ottobre 2026, quattro mesi dopo, non risulta assegnato alcun CVE alla vulnerabilità e non è stata pubblicata advisory di sicurezza formale. I ricercatori hanno notato che la build 8.0.2 è scomparsa dalla pagina di download, sebbene rimanga visibile nel changelog; hanno commentato che il vendor "appears to have deleted (?) the 8.0.2 build" in coincidenza con la pubblicazione del loro video proof-of-concept.

Il perimetro dell'attacco: diretto, non relay

AnyDesk dichiarò a giugno che la vulnerabilità è "limited to direct connections on Linux (connections that do not go through our relays)" e che "Windows and macOS are not affected". L'exploit pubblicato funziona esclusivamente su connessioni TCP dirette sulla porta 7070, che rappresentano un sottoinsieme delle modalità di connessione AnyDesk.

I ricercatori hanno tuttavia validato con strumentazione Frida che lo stesso percorso vulnerabile è raggiungibile anche attraverso i relay server AnyDesk, anche se non hanno dimostrato la completezza della catena di exploit in quella configurazione. Questo elemento rimane non verificato sul piano pratico: il trigger del bug è confermato, la RCE su relay non è stata provata con il codice rilasciato.

L'exploit targetizza esplicitamente la versione 8.0.2. I ricercatori implicano che versioni precedenti come 8.0.1 possano condividere il percorso vulnerabile, ma non hanno confermato l'exploitation su quelle build. AnyDesk Linux 8.1.0 risulta l'ultima versione disponibile al momento della notizia.

Perché è importante

Il caso documenta una discrepanza sistemica tra la gravità tecnica di una vulnerabilità e la sua rappresentazione pubblica da parte del vendor. Un pre-auth root RCE è stato descritto come crash potenziale; la correzione è stata distribuita senza CVE, senza advisory, senza indicazioni di priorità per gli aggiornamenti. Questo modello di disclosure lascia gli amministratori di sistema senza gli strumenti per valutare il rischio: il patch management dipende dalla percezione della criticità, e la percezione è stata deliberatamente attenuata.

L'assenza di CVE ha inoltre impedito l'ingestione automatica nelle piattaforme di vulnerability management, ritardando potenzialmente la copertura nelle organizzazioni che si affidano a quei flussi. La rimozione della build vulnerabile dalla pagina di download, se confermata come intenzionale, costituisce una forma di response opaca che non sostituisce la trasparenza informativa.

Il brief non specifica misure correttive aggiuntive raccomandate da AnyDesk o dai ricercatori, né documenta se esistano configurazioni che limitino l'esposizione della porta 7070 o che isolino il servizio dall'interfaccia di rete esterna. La fonte non chiarisce se l'exploit sia stato riprodotto su installazioni con personalizzazioni di compilazione diverse dalla build standard 8.0.2.

Per il settore, l'episodio solleva questioni sulle responsabilità di disclosure: quando un vendor corregge una falla critica senza documentarla adeguatamente, la pubblicazione dell'exploit diventa l'unico meccanismo per forzare la visibilità del rischio, con il costo collaterale di armare anche gli attaccatori.

Fonti

Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.

Fonti


Fonti e riferimenti
  1. thehackernews.com
  2. securityweek.com
  3. blog.netmanageit.com
  4. guardianmssp.com
  5. theregister.com
  6. nvd.nist.gov
  7. sec.cloudapps.cisco.com
  8. support.citrix.com