Abrir la página es la descarga

Un lector objetó a una nota de seguridad que publicamos, y la objeción era buena — lo bastante como para merecer una respuesta extensa, porque creemos que la mayoría de las personas técnicamente competentes sigue sosteniendo la misma creencia:

En 2015 era una regla razonable. Hoy es falsa. Cargar una página web basta por completo para tomar el control de un iPhone y, a fecha de 2026, esto ya no es algo al alcance únicamente de presupuestos estatales.

Abrir la página es la descarga

El modelo mental que hay que sustituir es la palabra «descarga». Cargar una página ya es descargar y ejecutar. El navegador obtiene un programa escrito por un desconocido — JavaScript — y lo ejecuta. Después analiza imágenes, fuentes, vídeo y hojas de estilo suministradas por ese mismo desconocido, en decodificadores escritos en C++. Todo ocurre dentro de un espacio aislado, y ese aislamiento es lo único que hay entre esa página y tu dispositivo.

El aislamiento no es un muro. Es una suposición: que hoy WebKit y el núcleo no contienen ningún fallo alcanzable y explotable. WebKit son millones de líneas de C++, y Apple publica varias veces al año correcciones de fallos de WebKit marcados como explotados activamente.

«Hay que descargar un .exe para infectarse» es pensamiento heredado de Windows. En iOS no puedes ejecutar en absoluto un archivo ejecutable descargado — y precisamente por eso una cadena completa de Safari al núcleo ha valido históricamente siete cifras. Que no exista la instalación lateral no elimina la puerta principal. Convierte al navegador en la puerta principal.

El precedente tiene diez años

Nada de esto es nuevo. Tres puntos bien documentados de la curva:

Lo que cambió en 2026 no es la capacidad. Es la distribución.

2026: la capacidad se puso en alquiler

En marzo, el Google Threat Intelligence Group — junto con iVerify y Lookout — publicó el análisis de un kit de explotación de cadena completa para iOS rastreado como DarkSword. Alcanzaba de iOS 18.4 a 18.7, encadenaba seis vulnerabilidades — tres de ellas de día cero en su momento — y llevaba en uso desde al menos noviembre de 2025.

Dos detalles de ese informe importan más que el número de vulnerabilidades.

El primero es la lista de operadores. La actividad en Turquía se vinculó a un proveedor turco de software de vigilancia; se observó a otro cliente de ese mismo proveedor empleando la misma cadena contra usuarios malasios en enero; y un grupo distinto, presuntamente de espionaje, ejecutó ataques de abrevadero contra usuarios ucranianos — plantando la cadena en sitios que las víctimas visitan por iniciativa propia. Una cadena de explotación, muchas manos sin relación entre sí. Eso es una relación de proveedor, no una operación a medida.

El segundo: los investigadores hallaron indicios de que el desarrollo o la personalización de la cadena pudo contar con asistencia de IA. Se le dé el peso que se le dé a ese hallazgo concreto, lo que importa aquí es la dirección que señala: la barrera de entrada está bajando, y capacidades reservadas a un puñado de proveedores se están difundiendo hacia fuera.

Y entonces se abarató

El 1 de septiembre, Socket publicó una investigación sobre la versión de consumo masivo de esa misma tendencia — y esta no es espionaje en absoluto. Es robo.

Trece paquetes maliciosos de temas de Composer se publicaron en Packagist, bajo varios espacios de nombres. Sitios vietnamitas de streaming de películas y cómics los instalaron con composer require, lo que troyanizó silenciosamente los recursos de front-end de esos sitios. A partir de ahí, todo visitante recibía JavaScript inyectado.

Ese script bifurcaba:

• La mayoría de los visitantes móviles acababan en una cadena de fraude publicitario y redirección a apuestas. Ruidosa, rentable, nada llamativa.
• Los visitantes con iPhone sin actualizar recibían en cambio una cadena de explotación de WebKit al núcleo, y se les instalaba software espía.

La cadena entraba por dos fallos de WebKit y terminaba en lectura y escritura del núcleo. Fíjate en qué son: N-days, no días cero. Ambos ya eran públicos y ya estaban corregidos. Todo el modelo de negocio es la distancia entre el momento en que Apple publica una corrección y el momento en que una persona concreta la instala. Este kit no ataca iPhones. Ataca iPhones que llevan tiempo sin actualizarse — lo que, en un dispositivo que alguien trata como un electrodoméstico, es una población enorme.

Lo que nos lleva a una oferta de VPS gratuito

El 31 de agosto se registró un dominio. El 1 de septiembre ya se estaba distribuyendo.

El señuelo está bien elegido para su público: un proveedor de nube anuncia una beta cerrada, con instancias VPS gratuitas — hasta tres años — para los primeros 5.000 registros. Se propagó por comunidades de VPS, administración de sistemas y blockchain mediante invitación por correo y, con más eficacia, mediante enlaces de referido.

El mecanismo de referidos es la parte en la que un defensor debería detenerse. No se limita a distribuir el enlace; recluta a los propios miembros consolidados de la comunidad para distribuirlo, envuelto en su reputación, porque a cambio obtienen un periodo gratuito más largo. El mensaje no llega de un desconocido. Llega de alguien cuyo historial de publicaciones llevas años leyendo. Al menos una persona que había compartido un enlace de referido publicó después una retractación para advertir a los demás.

Comportamiento descrito de la página:

Al parecer, una respuesta promocional insistía en que el enlace de reserva «hay que abrirlo en el móvil». Ninguna página real de reserva de VPS tiene motivo para exigir eso. Un kit de explotación exclusivamente móvil tiene todos los motivos.

Qué podemos confirmar y qué no

Queremos ser precisos sobre el estatus probatorio, porque estos tres casos no están al mismo nivel de confirmación y sería deshonesto presentarlos como si lo estuvieran.

DarkSword y la campaña de Packagist son investigación publicada por proveedores. Investigadores con nombre, CVE identificadas, detalle técnico reproducible, publicación bajo responsabilidad organizativa. Trátalas como establecidas.

La campaña del VPS gratuito procede de la comunidad. Que la campaña existe está bien corroborado: la promoción está documentada en varios hilos, la fecha de registro del dominio es verificable y un participante retiró públicamente su propia publicación de referido. Eso basta y sobra para actuar de forma defensiva.

Las afirmaciones técnicas profundas — la cadena concreta, las etapas exactas — proceden de un análisis anónimo sin identificadores CVE publicados ni hashes de muestras, elaborado en un solo día. Eso es alcanzable si quien lo firma reconoció un kit conocido; sería notable que hubiera hecho ingeniería inversa de una cadena inédita en una noche. La investigación de Socket mencionada arriba es lo que hace creíble el informe, y no al revés: misma franja de versiones, mismo inventario de datos robados, mismo móvil cripto, misma arquitectura de tomar huella y luego cargar. Un kit N-day alquilado, apuntado a quienes llevan un año sin actualizar, tiene exactamente este aspecto.

Nuestra posición: lo bastante creíble para defenderse, no lo bastante confirmado para citarlo como hecho. Si eso cambia, actualizaremos este artículo en el sitio, como hemos hecho con avisos anteriores.

«Cero clics» es el término equivocado, y la verdad no es mucho mejor

El informe comunitario lo titula como ataque de cero clics. No lo es, y conviene mantener limpia la distinción, porque cambia qué es lo que te protege.

Cero clics significa ninguna acción del usuario en absoluto — llega un mensaje y el dispositivo queda comprometido antes de que se abra nada. Esto requiere que abras un enlace. En la taxonomía habitual es un ataque de un clic, de abrevadero o por simple visita.

La distinción importa por una razón práctica: frente a una cadena de un clic, la disciplina con los enlaces te protege de verdad. Frente a una cadena de cero clics auténtica no lo hace, y solo sirven el nivel de parcheo y el modo de aislamiento.

Pero no te consueles demasiado. «Un clic» significa aquí abrir un enlace que te envió alguien en quien confías. No hay segundo aviso, ni barra de descarga, ni diálogo de instalación, ni solicitud de permisos. Abrirlo es todo el recorrido del usuario. El término es incorrecto; la diferencia práctica para la víctima es un toque.

¿Está Android a salvo de esto?

De esta cadena, sí. De esta clase de ataque, no.

Esta cadena se construye con fallos de WebKit y JavaScriptCore, un controlador de núcleo IOKit de iOS y desplazamientos específicos por compilación para modelos concretos de iPhone. Nada de eso existe en Android. Ambas campañas lo confirman por comportamiento: en el caso de Packagist, el script inyectado comprobaba la plataforma y enviaba a los visitantes de Android al banner de fraude publicitario; en el del VPS gratuito, los visitantes de Android y de escritorio solo obtienen el formulario de phishing.

Esta clase es otra cosa. Chrome, V8 y Android WebView son el mismo tipo de artefacto que WebKit: motores C++ enormes que analizan entradas hostiles. Google ha corregido cinco días cero de Chrome explotados activamente durante 2026, uno de los cuales permitía a un atacante remoto ejecutar código dentro del aislamiento del navegador con solo una página HTML manipulada. Es el mismo primer paso que dan las cadenas de iOS.

Los cinco son CVE-2026-2441, CVE-2026-3909, CVE-2026-3910, CVE-2026-5281 y CVE-2026-11645. El último es una lectura y escritura fuera de límites en V8.

También hay cadenas documentadas por simple visita en Android, entre ellas una que combinaba un día cero de Chrome, una elusión del aislamiento de GPU de Chrome exclusiva de Android y una elevación de privilegios en la GPU Mali, entregada mediante un enlace por SMS.

En qué se diferencia Android realmente

Tres diferencias reales, y no todas apuntan en la misma dirección.

Qué te protege de verdad

Para las dos campañas de iOS documentadas, el nivel de parcheo es decisivo, y hay una trampa en los números de versión:

Más allá del parcheo, el consejo estructural: no guardes el material de semilla de tu cartera en el dispositivo con el que abres enlaces. Las cargas finales de ambas campañas fueron a por el llavero y las aplicaciones de cartera. Una cartera de hardware o un dispositivo dedicado convierten una pérdida total en una molestia.

Y trata «ábrelo en el móvil» como una anomalía. A una página de registro legítima le da igual qué dispositivo uses. A un kit de explotación exclusivamente móvil le importa muchísimo.

Si la abriste

Da por hecho el compromiso en lugar de confiar en que no, y en este orden:

• Mueve primero los fondos. Si había aplicaciones de cartera instaladas en ese dispositivo, considera divulgadas las frases semilla. Transfiere los activos a una cartera cuyas claves se hayan generado en otro sitio. No te limites a cambiar un código — la semilla es la cuenta.
• Después actualiza y reinicia. Instala la versión actual de iOS. Muchos de estos implantes no sobreviven a un reinicio; actualizar y reiniciar cierra el agujero y a la vez elimina una etapa no persistente.
• Rota lo que hubiera en el llavero. Contraseñas guardadas, credenciales de Wi-Fi, cookies de sesión. Cierra todas las sesiones en todas partes y luego cambia las contraseñas desde otro dispositivo.
• Revisa en tus cuentas lo añadido, no solo los inicios de sesión. Nuevos métodos de doble factor, nuevas direcciones de recuperación, nuevas claves de API, nuevos dispositivos autorizados. Las cookies exfiltradas se usan para añadir una vía de regreso duradera.

Etapas de la cadena, según lo informado

Reconstruidas a partir del análisis publicado por Socket sobre la campaña de Packagist. Los límites entre etapas importan para el triaje: cada una deja un rastro distinto, y solo la última es persistente.

Dos hechos que un defensor debería llevarse de esta forma. Primero, solo la etapa 1 alcanza a todos los visitantes: un sitio que sirve el inyector es peligroso para toda su audiencia aunque casi nadie llegue a la etapa 4. Segundo, la condición de entrada es en ambos casos un fallo ya corregido, así que la exposición depende del retraso en actualizar, no del comportamiento del usuario.

Matriz de exposición

Triaje de un dispositivo que crees afectado

Este orden difiere deliberadamente del consejo dirigido a los lectores. El blog le dice al propietario que actualice y reinicie de inmediato, lo cual es correcto cuando el objetivo es detener la hemorragia. Si el objetivo es establecer si el dispositivo fue comprometido, un reinicio destruye las pruebas: varias de estas etapas no son persistentes y solo existen en estado volátil.

• Decide primero qué quieres: recuperación o prueba. Normalmente no se puede tener ambas. Si hay fondos en riesgo, elige la recuperación y asume la pérdida de pruebas.
• Si eliges prueba: captura antes de reiniciar. Un sysdiagnose tomado antes del reinicio conserva mucho más que uno tomado después. Los fallos repetidos del proceso WebContent o de GPU en torno a la hora de la visita son el rastro con más probabilidad de sobrevivir.
• Trata el material de la cartera como divulgado, no como en riesgo. La etapa 5 va directamente a por él. La rotación de claves no es opcional y no se sustituye parcheando.
• Audita las adiciones, no los accesos. Las cookies exfiltradas sirven para dar de alta una segunda vía duradera: nuevos factores MFA, direcciones de recuperación, claves de API, dispositivos autorizados. Un historial de inicios de sesión limpio no prueba nada.
• Revisa la red, no solo el teléfono. Las contraseñas de Wi-Fi estaban en el alcance. Un terminal comprometido implica credenciales expuestas de cada red que hubiera guardado.

Valoración, y qué la cambiaría

Declaramos la confianza de forma explícita, porque estos tres casos no están igual de establecidos, y un aviso que difumina eso vale menos que uno que no lo hace.

Qué elevaría la valoración baja: un hash de muestra publicado, un segundo análisis independiente, o la confirmación de un proveedor que nombre las mismas CVE. Qué la rebajaría: que el señuelo resulte ser una página corriente de phishing de credenciales, sin carga condicionada a la versión — esa es la hipótesis nula, y nada de lo que hemos visto por nosotros mismos la descarta.

No disponemos de ninguna muestra de la campaña del VPS gratuito. Todo lo que este aviso dice sobre ella es de segunda mano. Lo hacemos constar en lugar de dejar que la oferta permanente de este sitio de compartir cargas útiles sugiera lo contrario.

Cronología

Verificarlo tú mismo

Si quieres comprobar ese comportamiento de bifurcación en lugar de fiarte de la palabra de nadie, hazlo desde una máquina que no sea el objetivo: descarga el script de la página desde Linux con un User-Agent de iPhone y el foro de la comunidad como Referer, y compáralo con lo que recibe un User-Agent de escritorio. Servir la carga según el User-Agent es lo habitual en estos kits, y a un User-Agent de escritorio es muy probable que le llegue JavaScript limpio.

No lo hagas desde un teléfono, ni desde un dispositivo que contenga material de carteras. El encubrimiento corta por los dos lados: que un escáner declare limpio un sitio de phishing activo es el resultado esperado, no uno tranquilizador.

Indicadores

event.polarnode[.]vip          host señuelo, registrado el 2026-08-31
CVE-2025-31277                 WebKit, corregida en iOS 18.6
CVE-2025-43529                 WebKit, corregida en iOS 18.7.3 / 26.2
AppleM2ScalerCSCDriver         cliente de usuario IOKit usado para alcanzar el núcleo
Espacios de nombres Packagist: vsmov, vsphim, haiau009, chilltvcms, ophimcms

Por qué en este artículo no hay ningún enlace

Todas las direcciones hostiles que publicamos están escritas de forma neutralizada y ninguna es un enlace funcional. Un nombre de host de phishing representado como ancla activa convierte un artículo en una redirección, le presta a la campaña una fracción de nuestra reputación y le pide a un buscador que asocie ambas cosas. Nuestra cadena de publicación lo impone: un host que aparece neutralizado en cualquier punto de un artículo no puede llevar un enlace activo en ningún otro punto del mismo.

La investigación de proveedores citada aquí se encuentra fácilmente por su nombre. Preferimos que llegues a ella por una búsqueda que hayas hecho tú a que lo hagas por un enlace que hayamos puesto nosotros.