El 4 de agosto de 2026, los investigadores de Mysk publicaron un análisis de tres mecanismos de WebKit que envían tráfico eludiendo un proxy configurado, directamente desde el dispositivo. Todos los navegadores de iOS con modo proxy, incluidos los navegadores Tor, así como el propio servicio de Apple — iCloud Private Relay — se vieron afectados. El proxy está activado, la interfaz muestra un país extranjero, pero el sitio ve tu verdadera IP y tu resolutor DNS doméstico.
No se trata de una vulnerabilidad exótica para paranoicos. Es una demostración clara de una regla arquitectónica que todos los que trabajan a través de un proxy deben entender: el proxy a nivel de aplicación solo protege el tráfico que pasa a través de la pila de red de esa aplicación. Todo lo que genera el sistema operativo o un servicio del sistema va por otro camino.
¿Qué es lo que se filtra?
La investigación comenzó con una situación cotidiana: un usuario del navegador proxy Psylo se quejó al desarrollador sobre una fuga de DNS. El análisis de la queja reveló tres canales independientes de fuga — todos ellos se encuentran en el propio WebKit, y no en una aplicación específica.
1. DNS prefetching — el más simple y el más desagradable
Mecanismo: la etiqueta <link rel="dns-prefetch"> solicita al navegador que resuelva el nombre del host por adelantado para acelerar la carga futura. El problema es que WebKit en iOS resuelve tales nombres a través del camino DNS normal del dispositivo, y no a través del proxy.
Safari de escritorio ha soportado dns-prefetch desde Safari 5, pero iOS ignoró esta etiqueta — hasta iOS 26.0 (septiembre de 2025). Entonces, WebKit la activó como parte del mismo cambio que eliminó el antiguo dns-prefetching especulativo implícito (error 285744).
Cómo se explota: la página incrusta en tales etiquetas nombres de host únicos para cada visitante, y luego simplemente observa cómo las solicitudes llegan a su propio servidor DNS autoritativo — desde la dirección real de la red del visitante. No se necesita JavaScript, ni interacción del usuario. Basta con abrir la página.
2. WebAuthn Related Origin Requests — fuga a través del pasaporte de passkey
Este canal apareció en iOS 18.0. Cuando un sitio solicita credenciales de WebAuthn (es decir, passkey), el sistema verifica el archivo https://<rpId>/.well-known/webauthn — para asegurarse de que el dominio esté realmente asociado con la parte confiable indicada.
Detalle clave: esta solicitud de verificación no proviene de la pila de red del navegador. La realiza el servicio de credenciales del sistema operativo, que envía la solicitud HTTPS directamente desde el dispositivo. El proxy configurado dentro del navegador simplemente no lo sabe (error 268426).
Es decir, basta con que la página inicie una solicitud de passkey — y el servidor del atacante recibe una conexión desde tu verdadera IP.
3. WebTransport — QUIC directamente desde el dispositivo
El canal más reciente. La llamada new WebTransport(url) abre una conexión QUIC directamente desde el dispositivo, eludiendo la configuración del proxy. WebTransport en WebKit estuvo desactivado durante mucho tiempo y llegó públicamente a iOS 26.4 en marzo de 2026 (errores 260810 y 303453).
¿A quién le concierne esto?
Apple exige que todos los navegadores en iPhone utilicen WebKit. Por lo tanto, se verá afectado cada navegador de iOS que dependa de la API de proxy de WebKit — incluidos todas las versiones de iOS de los navegadores Tor y el propio Psylo, que inició la investigación. Además de Safari y iCloud Private Relay.
Lo que no se ve afectado son las aplicaciones VPN. Funcionan a nivel de sistema y envuelven todo el tráfico del dispositivo, incluidos aquellos generados por los servicios del sistema. Esta es la esencia de la diferencia: un túnel de sistema no tiene "por otro lado". Una excepción particular es Onion Browser en el nivel de seguridad Silver con el Modo de Bloqueo activado: es inmune a la fuga a través de WebTransport.
Desde el lado de los desarrolladores, ya hay una reacción. En Psylo 1.3.1 se han cerrado los tres canales: la aplicación bloquea las sugerencias de dns-prefetch (la página ya no puede hacer que el dispositivo resuelva nombres controlados por el atacante), y WebTransport y WebAuthn están desactivados por defecto — se pueden activar de manera puntual, mediante interruptores individuales. Apple, según la información al momento de la publicación, debe solucionar los problemas en una futura actualización; la compañía no ha dado plazos específicos.
¿Por qué esto ha salido a la luz solo ahora?
La cronología aquí es reveladora, y vale la pena desglosarla por separado — explica por qué el problema no se había notado antes.
- Septiembre 2024, iOS 18.0 — aparece el mecanismo de WebAuthn Related Origin Requests. El canal de fuga ha existido casi dos años y durante todo este tiempo no ha sido discutido por nadie: la verificación del dominio para passkey parece un elemento de seguridad, y no una forma de revelar la dirección.
- Septiembre 2025, iOS 26.0 — WebKit incluye soporte para dns-prefetch en dispositivos móviles. Formalmente es una optimización de velocidad de carga; de hecho, la página obtiene la capacidad de hacer que el dispositivo consulte un nombre DNS arbitrario eludiendo el proxy.
- Marzo 2026, iOS 26.4 — WebTransport se activa públicamente. El tercer canal.
- Agosto 2026 — la queja de un usuario sobre una fuga de DNS lleva a un análisis que revela los tres de inmediato.
El denominador común: ninguna de estas funciones fue concebida como un canal de desanonimización. Las tres son capacidades ordinarias de la plataforma: aceleración de resolución, verificación de passkey, transporte moderno. Se convierten en fugas solo en combinación con el modo proxy a nivel de aplicación, y es por eso que nadie las había probado en este sentido durante años.
La conclusión práctica es simple y desagradable: la ausencia de noticias sobre fugas no significa que no existan. Es necesario verificar por uno mismo y de forma regular, en lugar de esperar a que alguien publique un análisis.
¿Cómo comprobarse?
Los investigadores han publicado un stand público — leaks.psylo.app. Este verifica tres cosas: tráfico HTTPS normal (qué IP y qué resolutores DNS ve el servidor), WebTransport y la combinación WebAuthn + dns-prefetch. Ábrelo con el proxy activado y compara el resultado con la dirección que esperas ver.
También es importante verificar la higiene básica — si la IP, DNS y la dirección WebRTC coinciden en tu conjunto de trabajo. Si antes no te habías ocupado de esto de manera sistemática, comienza con nuestro análisis: cómo verificar un proxy por fuga de DNS.
Conclusión práctica: la capa importa
La historia con WebKit es un caso particular de una regla general que vale la pena tener en mente al trabajar a través de un proxy, en cualquier plataforma.
- Proxy en el navegador ≠ proxy en el dispositivo. La configuración dentro de la aplicación cubre exactamente el tráfico que la aplicación envía. Los servicios del sistema, procesos en segundo plano, actualizaciones, conexiones push y, como se ha descubierto, el servicio de passkey integrado — todo esto sigue su propio camino.
- Las fugas no ocurren solo en lugares "conocidos". WebRTC ha estado en la mente de todos, y han aprendido a bloquearlo. Y el dns-prefetching y la verificación de WebAuthn son funciones de rendimiento y seguridad que nadie había considerado como un canal de desanonimización. Nuevas características de los navegadores crean regularmente nuevos caminos de elusión.
- La actualización de la plataforma puede romper tu protección en silencio. Aquí se ve literalmente por las fechas: el dns-prefetching "se activó" en iOS 26.0, WebTransport — en iOS 26.4. El usuario no cambió nada, y la superficie de fuga creció por sí sola.
¿Qué significa esto para el multi-cuenta y la automatización?
Para aquellos que manejan múltiples cuentas o recopilan datos, el riesgo aquí no es abstracto-privado, sino bastante financiero. Los sistemas antifraude de las plataformas comparan señales: si una sesión declara una IP, y la solicitud asociada proviene de otra dirección y de un resolutor doméstico, es un motivo claro para vincular cuentas entre sí o marcar la sesión como sospechosa.
Consecuencias prácticas:
- No manejes sesiones de multi-cuenta en navegadores móviles con modo proxy. Mientras la plataforma no cierre las brechas, la capa de aplicación en iOS es inherentemente poco confiable.
- Envuelve el tráfico a nivel de sistema. Si la tarea es un entorno móvil, es más sensato levantar un proxy a nivel de dispositivo o enrutar a través de un gateway separado, en lugar de confiar en la configuración dentro del navegador.
- Verifica la combinación después de cada gran actualización del sistema operativo y del navegador. Al menos una vez por trimestre. Inclúyelo en tu lista de verificación, y no "cuando algo salga mal".
- Desactiva lo que no uses. WebTransport y WebAuthn en un perfil de trabajo para parsing o SMM casi con seguridad no son necesarios — desactivarlos elimina dos canales de fuga de tres.
La calidad de la IP en sí misma sigue siendo una variable separada: incluso con una configuración hermética, una dirección de centro de datos se revela por ASN. Para escenarios donde es importante parecer un usuario normal, funcionan proxies residenciales, y para aplicaciones móviles y plataformas con el antifraude más estricto — proxies móviles con IP de operadores de telefonía real. Pero ninguna clase de proxy salvará si parte del tráfico físicamente va por otro lado — primero la hermeticidad, luego la calidad de la dirección.
Conclusión
Los tres errores de WebKit — dns prefetching, WebAuthn Related Origin Requests y WebTransport — han demostrado que "el proxy está activado" y "todo el tráfico pasa a través del proxy" son dos afirmaciones diferentes. En iOS, la brecha entre ellas resultó ser lo suficientemente amplia como para que una página web normal, sin una sola línea de JavaScript, pudiera conocer la verdadera dirección de un visitante del navegador Tor.
Mientras Apple prepara una solución, la única estrategia efectiva es verificar, y no suponer. Abre el stand de prueba, compara direcciones, desactiva APIs innecesarias. Y trata cada gran actualización del sistema operativo como un evento después del cual la configuración debe ser verificada nuevamente. La diferencia entre la privacidad y su ilusión a menudo consiste en una sola pregunta no formulada a tiempo: "¿es realmente todo el tráfico?". También es útil entender qué otras señales te delatan además de la dirección — sobre esto hemos escrito en el material sobre protección contra el fingerprinting del navegador.
```