Su Android 16 esiste una falla che permette a qualsiasi applicazione, anche senza permessi particolari, di inviare traffico al di fuori del tunnel VPN ed esporre l’indirizzo IP reale del dispositivo. Il problema interessa tutte le app VPN e funziona anche con le opzioni più restrittive attivate, “VPN sempre attiva” e “Blocca connessioni senza VPN”.

La segnalazione arriva dal ricercatore di sicurezza noto come “lowlevel/Yusuf”, che ha pubblicato l’analisi tecnica con il nome The Tiny UDP Cannon. A rilanciare il caso con un proprio post è stata Mullvad, che ha contattato il ricercatore originale e segnalato nuovamente la falla a Google.

// affiliato ▸ Swiss Backup · I tuoi backup, al sicuro in Svizzera · Proteggi i tuoi dati →

Dove nasce il problema

Il bug riguarda un meccanismo introdotto in Android 16 per chiudere in modo ordinato le connessioni QUIC, il protocollo di trasporto basato su UDP usato da HTTP/3 e da un numero crescente di applicazioni. Tramite il metodo registerQuicConnectionClosePayload esposto dal ConnectivityManager, un’applicazione può registrare un payload finale che il sistema invierà al server quando il socket verrà chiuso.

Il problema, come spiega CyberInsider, è che la trasmissione del payload viene gestita dal processo system_server, che opera con privilegi di rete elevati ed è esente dalle restrizioni di instradamento della VPN. Android non verifica né il contenuto del payload né se l’app sia vincolata al tunnel: il pacchetto esce direttamente sull’interfaccia fisica. La dimostrazione è stata fatta su un Pixel 8 con Android 16 e Proton VPN, con entrambe le opzioni di blocco attive.

Per sfruttare la falla serve comunque che sia installata un’app malevola sul dispositivo. Non occorrono permessi sospetti, basta il normale accesso a internet, presente praticamente in ogni applicazione.

La risposta di Google e quella di GrapheneOS

L’Android Security Team ha chiuso la segnalazione come Won’t Fix (Infeasible), decidendo di non includerla nel bollettino di sicurezza. La nuova segnalazione aperta da Mullvad sull’issue tracker pubblico risulta al momento inaccessibile per ragioni che Google non ha spiegato.

In direzione opposta è andato GrapheneOS, che nel modulo Connectivity del proprio codice ha disattivato l’ottimizzazione registerQuicConnectionClosePayload, neutralizzando il vettore di attacco sui dispositivi Pixel supportati. La correzione è arrivata nel giro di pochi giorni dalla divulgazione.

Mitigazione su Android stock

Chi resta su Android così com’è può tamponare manualmente, ma serve abilitare il debug USB e usare adb:

adb shell device_config put tethering close_quic_connection -1
adb reboot

I comandi disattivano la chiusura “gentile” delle connessioni QUIC e chiudono la falla. L’impostazione sopravvive ai riavvii ma può essere annullata dagli aggiornamenti di sistema, nel qual caso va ripetuta. L’effetto collaterale è che i socket QUIC sul server resteranno semiaperti finché non andranno in timeout, senza conseguenze pratiche per il dispositivo.