Il 4 agosto 2026, i ricercatori di Mysk hanno pubblicato un'analisi di tre meccanismi di WebKit che inviano traffico bypassando il proxy configurato — direttamente dal dispositivo. Sono stati colpiti tutti i browser iOS con modalità proxy, inclusi i browser Tor, e anche il servizio di Apple — iCloud Private Relay. Il proxy è attivato, l'interfaccia mostra un paese straniero, ma il sito vede il tuo vero IP e il tuo risolutore DNS domestico.
Questa non è una vulnerabilità esotica per i paranoici. È una dimostrazione chiara di una regola architettonica che tutti coloro che lavorano tramite proxy dovrebbero apprendere: il proxy a livello di applicazione protegge solo il traffico che passa attraverso lo stack di rete di quell'applicazione. Tutto ciò che genera il sistema operativo o un singolo servizio di sistema passa oltre.
Cosa esattamente sta trapelando
La ricerca è iniziata con una situazione comune: un utente del browser proxy Psylo si è lamentato con lo sviluppatore di una fuga di DNS. L'analisi della lamentela ha rivelato tre canali di fuga indipendenti — tutti si trovano all'interno di WebKit, e non in un'applicazione specifica.
1. DNS prefetching — il più semplice e il più sgradevole
Meccanismo: il tag <link rel="dns-prefetch"> chiede al browser di risolvere in anticipo il nome host per accelerare il caricamento futuro. Il problema è che WebKit su iOS risolve tali nomi attraverso il normale percorso DNS del dispositivo, e non attraverso il proxy.
Safari desktop supporta il dns-prefetch sin dai tempi di Safari 5, ma iOS ha ignorato questo tag — fino a iOS 26.0 (settembre 2025). Allora WebKit lo ha attivato nell'ambito della stessa modifica che ha rimosso il vecchio dns-prefetching speculativo implicito (bug 285744).
Come viene sfruttato: la pagina incorpora in tali tag nomi host unici per ogni visitatore, e poi osserva semplicemente come le richieste arrivano al suo stesso server DNS autoritativo — dall'indirizzo reale della rete del visitatore. Nessun JavaScript, nessuna interazione con l'utente. Basta aprire la pagina.
2. Richieste di origine correlate a WebAuthn — fuga attraverso il passkey
Questo canale è emerso già in iOS 18.0. Quando un sito richiede credenziali WebAuthn (cioè passkey), il sistema va a controllare il file https://<rpId>/.well-known/webauthn — per assicurarsi che il dominio sia effettivamente collegato al party di fiducia specificato.
Dettaglio chiave: questa richiesta di verifica non proviene dallo stack di rete del browser. Viene eseguita dal servizio di credenziali del sistema operativo, che invia direttamente una richiesta HTTPS dal dispositivo. Il proxy configurato all'interno del browser semplicemente non ne è a conoscenza (bug 268426).
Quindi, è sufficiente che la pagina avvii una richiesta di passkey — e il server dell'attaccante ottiene una connessione dal tuo vero IP.
3. WebTransport — QUIC direttamente dal dispositivo
Il canale più recente. La chiamata new WebTransport(url) apre una connessione QUIC direttamente dal dispositivo, bypassando la configurazione del proxy. WebTransport in WebKit è stato a lungo disattivato ed è stato reso pubblico in iOS 26.4 a marzo 2026 (bug 260810 e 303453).
A chi riguarda
Apple richiede che tutti i browser su iPhone utilizzino WebKit. Di conseguenza, saranno colpiti ogni browser iOS che si basa sull'API proxy di WebKit — inclusi tutte le versioni iOS dei browser Tor e lo stesso Psylo, da cui è iniziata l'indagine. Inoltre, Safari e iCloud Private Relay.
Cosa non è colpito — le applicazioni VPN. Lavorano a livello di sistema e incapsulano tutto il traffico del dispositivo, compreso quello generato dai servizi di sistema. Questa è la sostanza della differenza: un tunnel di sistema non ha "bypass". Un'eccezione separata è l'Onion Browser a livello di sicurezza Silver con la modalità Lockdown attivata: è immune alla fuga attraverso WebTransport.
Dal lato degli sviluppatori, c'è già una reazione. In Psylo 1.3.1 sono stati chiusi tutti e tre i canali: l'app blocca i suggerimenti dns-prefetch (la pagina non può più costringere il dispositivo a risolvere nomi sotto il controllo dell'attaccante), e WebTransport e WebAuthn sono disattivati per impostazione predefinita — possono essere attivati selettivamente, tramite interruttori separati. Apple, secondo le informazioni al momento della pubblicazione, dovrebbe risolvere i problemi in un futuro aggiornamento; la società non ha fornito scadenze specifiche.
Perché è emerso solo ora
La cronologia qui è indicativa, e vale la pena analizzarla separatamente — spiega perché il problema non è stato notato prima.
- Settembre 2024, iOS 18.0 — emerge il meccanismo delle Richieste di Origine Correlate a WebAuthn. Il canale di fuga esiste da quasi due anni e per tutto questo tempo non è stato discusso da nessuno: la verifica del dominio per il passkey sembra un elemento di sicurezza, e non un modo per rivelare l'indirizzo.
- Settembre 2025, iOS 26.0 — WebKit attiva il supporto per il dns-prefetch sui dispositivi mobili. Formalmente è un'ottimizzazione della velocità di caricamento; di fatto, la pagina ottiene la possibilità di costringere il dispositivo a contattare un nome DNS arbitrario bypassando il proxy.
- Marzo 2026, iOS 26.4 — WebTransport viene attivato pubblicamente. Terzo canale.
- Agosto 2026 — la lamentela di un utente su una fuga di DNS porta a un'analisi che rivela tutti e tre contemporaneamente.
Il denominatore comune: nessuna di queste funzioni è stata concepita come canale di de-anonimizzazione. Tutte e tre sono normali capacità della piattaforma: accelerazione della risoluzione, verifica del passkey, trasporto moderno. Diventano una fuga solo in combinazione con la modalità proxy a livello di applicazione, ed è per questo che nessuno le ha testate in questo contesto per anni.
La conclusione per la pratica è semplice e sgradevole: l'assenza di notizie sulle fughe non significa che non ci siano. È necessario controllare da soli e regolarmente, e non aspettare che qualcuno pubblichi un'analisi.
Come verificare se stessi
I ricercatori hanno pubblicato un banco di prova pubblico — leaks.psylo.app. Controlla tre cose: traffico HTTPS normale (quale IP e quali risolutori DNS vede il server), WebTransport e la combinazione WebAuthn + dns-prefetch. Apri con il proxy attivato e confronta il risultato con l'indirizzo che ti aspetti di vedere.
Vale la pena controllare anche l'igiene di base — se l'IP, il DNS e l'indirizzo WebRTC coincidono nella tua configurazione di lavoro. Se prima non ti sei occupato sistematicamente di questo, inizia con la nostra analisi: come controllare il proxy per la fuga di DNS.
Conclusione pratica: il livello conta
La storia con WebKit è un caso particolare di una regola generale che vale la pena tenere a mente quando si lavora tramite proxy, su qualsiasi piattaforma.
- Proxy nel browser ≠ proxy sul dispositivo. La configurazione all'interno dell'app copre esattamente il traffico che l'app stessa invia. I servizi di sistema, i processi in background, gli aggiornamenti, le connessioni push e, come si è scoperto, il servizio passkey incorporato — tutto questo segue il proprio percorso.
- Le fughe non avvengono solo in luoghi "noti". WebRTC è da tempo sotto i riflettori, e hanno imparato a tappare le falle. E il dns-prefetching e la verifica di WebAuthn — sono funzioni di prestazione e sicurezza che nessuno ha considerato come canale di de-anonimizzazione. Nuove funzionalità dei browser creano regolarmente nuovi percorsi di bypass.
- Un aggiornamento della piattaforma può silenziosamente compromettere la tua sicurezza. Qui è evidente letteralmente dalle date: il dns-prefetching è "attivato" in iOS 26.0, WebTransport — in iOS 26.4. L'utente non ha cambiato nulla, e la superficie di fuga è aumentata da sola.
Cosa significa questo per il multi-accounting e l'automazione
Per coloro che gestiscono più account o raccolgono dati, il rischio qui non è astrattamente privato, ma piuttosto finanziario. I sistemi antifrode delle piattaforme confrontano i segnali: se una sessione dichiara un IP, ma una richiesta associata arriva da un altro indirizzo e da un risolutore domestico, questo è un motivo valido per collegare gli account tra loro o contrassegnare la sessione come sospetta.
Le conseguenze pratiche:
- Non gestire sessioni di multi-account lavorative in browser mobili con modalità proxy. Finché la piattaforma non ha chiuso le falle, il livello dell'app su iOS è inaffidabile per definizione.
- Incapsula il traffico a livello di sistema. Se l'obiettivo è un ambiente mobile, è più saggio sollevare un proxy a livello di dispositivo o instradare attraverso un gateway separato, piuttosto che fare affidamento sulla configurazione all'interno del browser.
- Controlla la configurazione dopo ogni grande aggiornamento del sistema operativo e del browser. Almeno una volta al trimestre. Includi questo nella tua lista di controllo, e non "quando qualcosa va storto".
- Disattiva ciò che non usi. WebTransport e WebAuthn nel profilo di lavoro per il parsing o SMM non sono quasi mai necessari — disattivarli rimuove due canali di fuga su tre.
La qualità dell'IP stesso rimane una variabile separata: anche con una configurazione ermetica, un indirizzo di data center si rivela attraverso l'ASN. Per scenari in cui è importante apparire come un utente normale, funzionano proxy residenziali, e per applicazioni mobili e piattaforme con il più rigoroso antifrode — proxy mobili con IP di veri operatori cellulari. Ma nessuna classe di proxy salverà, se parte del traffico passa fisicamente oltre — prima l'ermeticità, poi la qualità dell'indirizzo.
Conclusione
I tre bug di WebKit — dns prefetching, Richieste di Origine Correlate a WebAuthn e WebTransport — hanno dimostrato che "il proxy è attivato" e "tutto il traffico passa attraverso il proxy" sono due affermazioni diverse. Su iOS, il divario tra di loro si è rivelato sufficientemente ampio da consentire a una normale pagina web, senza una singola riga di JavaScript, di conoscere il vero indirizzo di un visitatore del browser Tor.
Finché Apple prepara una correzione, l'unica strategia funzionante è controllare, e non presumere. Apri il banco di prova, confronta gli indirizzi, disattiva le API superflue. E considera ogni grande aggiornamento del sistema operativo come un evento dopo il quale è necessario ricontrollare la configurazione. La differenza tra privacy e la sua illusione spesso consiste esattamente in una domanda non posta in tempo: "è davvero tutto il traffico?". È utile anche capire quali altri segnali ti rivelano oltre all'indirizzo — di questo abbiamo scritto nel materiale sulla protezione contro il fingerprinting del browser.