WebKit filtra la IP y el DNS reales pese a los proxies y a iCloud Private Relay
Foto: WebKit project (logo) / LGPL
Una fuga de IP y DNS en WebKit anula la privacidad que se supone que aportan los navegadores con proxy en iOS. Los investigadores de Mysk publicaron el 4 de agosto de 2026 hallazgos que muestran que tres funciones distintas de WebKit abren conexiones directamente desde el dispositivo, ignorando el proxy que el navegador tenía configurado. Esos mismos tres caminos también escapan del iCloud Private Relay de Apple.
Aquí no hay ningún exploit remoto. Una página no necesita romper nada: se limita a usar funciones corrientes de la plataforma web y a mirar desde dónde llega el tráfico.
Las tres funciones que rodean el proxy
| Función | Qué se escapa | Presente desde |
|---|---|---|
| DNS prefetch | Resolutores DNS reales y el nombre de host consultado | iOS 26.0, septiembre de 2025 |
| WebAuthn related origin requests | Dirección IP real del dispositivo | iOS 18.0, septiembre de 2024 |
| WebTransport | Dirección IP real del dispositivo | iOS 26.4, marzo de 2026 |
DNS prefetch es una optimización de velocidad. Una página avisa de que pronto necesitará un nombre de host y el motor lo resuelve por adelantado. En iOS esa resolución va por la ruta DNS normal del dispositivo y no por el proxy. Un sitio puede poner un nombre de host único para cada visitante en esa pista y luego leer las consultas cuando llegan a su propio servidor de nombres autoritativo, directamente desde la red real del visitante.
WebAuthn related origin requests se filtra de otra manera. WebKit entrega la ceremonia de passkey al servicio de credenciales del sistema operativo, y es ese servicio el que descarga por su cuenta el archivo /.well-known/webauthn del sitio. La petición sale del sistema y no del navegador, de modo que la configuración de proxy del navegador nunca entra en juego.
WebTransport es el más directo de los tres. Crear uno abre una conexión QUIC desde el dispositivo hasta el destino, sin ningún proxy en medio.
Por qué iCloud Private Relay no te salva aquí
A Private Relay se le describe a menudo como un VPN para Safari. No lo es. Hace pasar el tráfico de páginas de Safari por dos saltos para que ninguna parte vea a la vez quién eres y qué pediste. Esa protección cubre la ruta habitual de carga de una página, y las tres fugas viven fuera de ella. Cuando el servicio de credenciales del sistema o un socket QUIC salen por su cuenta, Private Relay simplemente no está en el circuito.
El mismo razonamiento explica por qué el problema es peor en el iPhone que en cualquier otro sitio. Las reglas de la App Store exigen que todo navegador de iOS use WebKit, así que un navegador centrado en la privacidad no puede sustituir el motor por otro que encamine bien estas rutas. Los navegadores basados en Tor para iOS heredan la fuga por construcción, y lo mismo le ocurre a cualquier aplicación que levante su anonimato sobre un proxy interno.
Qué se está arreglando de momento
Las mitigaciones llegan por ahora de los desarrolladores de aplicaciones y no del motor. Psylo publicó la versión 1.3.1: elimina de las páginas las pistas dns-prefetch y desactiva por defecto WebTransport y WebAuthn, que quedan como interruptores opcionales. Es un rodeo en la capa de la aplicación: cada navegador afectado tiene que darse cuenta del problema y desactivar funciones útiles una por una. No hay declaración pública de Apple ni cambio anunciado en WebKit que aborde las tres rutas a la vez.
Por qué un túnel del sistema no se ve afectado
Lo que importa aquí es en qué nivel se aplica la privacidad. Un proxy configurado dentro de un navegador solo cubre el tráfico que ese navegador decide enviarle, así que todo lo que abra otro componente del sistema pasa de largo. Un túnel completo, en cambio, lo aplica la pila de red del sistema operativo: cada paquete de cada proceso sale por la misma interfaz, venga de la carga de una página, de un servicio de credenciales o de un socket QUIC en crudo. Por eso los VPN de túnel completo quedan intactos ante las tres fugas y los proxys dentro del navegador no, y es un recordatorio útil de que la privacidad a nivel de navegador y la privacidad a nivel de red resuelven problemas distintos.
Para quien hoy se apoya en un navegador con proxy, los pasos son pequeños pero reales: actualizar la aplicación si su desarrollador ya ha publicado una mitigación, dejar de tratar Private Relay como una herramienta de anonimato y comprobar qué expone realmente tu navegador en lugar de fiarte del indicador de la interfaz.
