¿Sigues en iOS 16? Hackers usan un fallo de Safari de 2024 en iPhones antiguos
El 4 de noviembre de 2026, la agencia estadounidense de ciberseguridad y seguridad de infraestructuras (CISA) añadió CVE-2024-27834, una vulnerabilidad de Apple WebKit, a su catálogo de vulnerabilidades explotadas conocidas. Las agencias federales de EE. UU. tienen hasta el 18 de noviembre de 2026 para aplicar el parche. CISA lista el producto afectado como Apple "Multiple Products".
La vulnerabilidad es de 2024. Apple la corrigió el 13 de mayo de 2024 en iOS 17.5 y Safari 17.5, y en iOS 16.7.8 para los modelos más antiguos iPhone 8, iPhone 8 Plus e iPhone X. Vuelve a las noticias porque los atacantes siguen usándola contra teléfonos que nunca instalaron esa actualización. El parche lleva más de dos años disponible. Los teléfonos afectados son los que dejaron de actualizarse antes de mayo de 2024.
Resumen rápido antes de los detalles:
- Si tu iPhone 8, 8 Plus o X ejecuta iOS 16.7.8 o posterior, esta cadena de ataque concreta no funciona en él.
- Si se quedó en iOS 16.7.7 o anterior, estás expuesto y deberías actualizar hoy mismo.
- Si usas una versión antigua de Chrome en Android, también te aplica un ataque relacionado. Chrome 146 o posterior lo corrige.
Qué añadió CISA el 4 de noviembre y por qué vuelve un fallo de 2024
El fallo está en WebKit, el motor de navegador que hay detrás de Safari y de la mayoría de los navegadores del iPhone. Permite que un atacante que ya tiene acceso de lectura y escritura a la memoria eluda Pointer Authentication, una defensa del iPhone. Apple atribuye el hallazgo a Manfred Paul, en colaboración con la Zero Day Initiative de Trend Micro. Puedes leer las notas originales del parche de Apple para iOS 17.5 y para iOS 16.7.8.
La campaña que motivó la inclusión en el catálogo de CISA fue documentada por Sekoia, una empresa de seguridad francesa, en un informe publicado el mismo día. En las siguientes secciones explicamos lo que hizo.
Qué teléfonos están en riesgo
Las cadenas de ataque documentadas por Sekoia se dividen según el dispositivo y la versión de software. La cadena para iPhone construida en torno a CVE-2024-27834 solo funciona en teléfonos que se quedaron en iOS 16.7.7 o anterior, porque Apple corrigió ese fallo en iOS 16.7.8 en mayo de 2024. Una segunda cadena para iPhone apunta a iOS 18.5, y una tercera apunta a Chrome en Android, concretamente las versiones 139 a 145.
| Dispositivo | Qué atacaban los atacantes | Qué lo soluciona |
|---|---|---|
| iPhone 8, 8 Plus o X | Cadena A: dos fallos de WebKit que roban las cookies del navegador, lo que puede dar a un atacante acceso a tus cuentas con sesión iniciada. Funciona solo en iOS 16.7.7 o anterior. | iOS 16.7.8 o posterior. La versión más reciente de iOS 16 es iOS 16.7.16, del 11 de mayo de 2026. |
| iPhone XS, XS Max o XR | Cadena B, dirigida a iOS 18.5: un kit de exploits que Sekoia llama DarkSword, que toma mensajes, correo, datos de WhatsApp y Telegram, contraseñas del Llavero, historial de Safari, contactos, fotos, ubicación, datos de Salud y contraseñas de Wi-Fi. | El iOS más reciente que el teléfono ofrezca, iOS 18.7.11 a fecha del 26 de octubre de 2026. |
| iPhone 11 o posterior | Cadena B en iOS 18.5, como arriba. | iOS 27.2, publicado el 26 de octubre de 2026. |
| Teléfono Android con Chrome | Cadena C: un fallo de Chrome, CVE-2026-3910, más un fallo en el driver gráfico de Qualcomm. Toma las cookies de Chrome, inicios de sesión guardados, historial y ajustes de Wi-Fi. | Chrome 146 o posterior, y las actualizaciones actuales del sistema Android. |
Hay una advertencia para el iPhone 8, 8 Plus y X. Estos teléfonos reciben correcciones ocasionales en iOS 16, no todas. Un iPhone con iOS 16.7.16 completamente actualizado rompe la cadena A, pero puede seguir teniendo otros errores de WebKit que las versiones más nuevas de iOS corrigieron. Eso limita para qué deberían usarse estos teléfonos, algo que abordamos más abajo.
Cómo una visita a un sitio web se convirtió en un ataque
El método se llama watering hole. En lugar de enviar a los objetivos un enlace o un mensaje, los atacantes insertan código en sitios web que esos objetivos probablemente visiten. Navegas a un sitio de confianza, y el sitio te sirve el exploit.
Sekoia documentó qué sitios estaban involucrados en esta campaña. No eran sitios de noticias. La lista incluía páginas legítimas comprometidas: una empresa ucraniana de producción de gas, una asociación comercial estadounidense de la industria química, un partido político checo y un sitio búlgaro relacionado con el ejército. También había dos dominios imitadores, uno que copiaba el sitio del aniversario estadounidense America250 y otro que imitaba un hotel de lujo de Londres. Un script ucraniano de analítica web comprometido, Plerdy, estuvo presente en miles de sitios web, en su mayoría ucranianos, del 27 de agosto al 3 de septiembre de 2026. Los países afectados fueron Estados Unidos, Ucrania, la República Checa y Bulgaria, además del Reino Unido a través del hotel imitado.
Dos detalles importan especialmente para quien lea esto en un teléfono:
- No hizo falta ningún toque. Según Sekoia, los exploits se sirvieron sin interacción del usuario. Con cargar la página bastaba.
- Nada quedó en el teléfono tras un reinicio. No hubo persistencia.
Sekoia vincula la campaña con confianza moderada a alta a APT29, un grupo que, según señala la empresa, está ampliamente relacionado con el servicio de inteligencia exterior de Rusia. Más allá de la atribución, la lección práctica es la misma de nuestro artículo de 2018 sobre Safari y WebKit: un navegador con los parches al día es la diferencia entre una página hostil y una inofensiva. La propia conclusión de Sekoia es que un usuario con un sistema operativo actualizado está a salvo de estos ataques, ya que el proveedor corrigió todas las vulnerabilidades antes de que comenzara la campaña.
¿Es seguro un iPhone 8 o un iPhone X una vez actualizado?
En su mayor parte, sí. La cadena A necesita dos fallos que funcionen juntos. Uno de ellos, CVE-2024-27834, se corrigió en iOS 16.7.8 el 13 de mayo de 2024, según las notas de Apple. Así que un teléfono con iOS 16.7.8 o posterior, incluido el actual iOS 16.7.16, rompe esa cadena. El ataque no funciona en él.
El límite está en el otro fallo de la cadena, CVE-2025-43529. Las notas de Apple incluyen una corrección para él en iOS 18 e iOS 26, pero ninguna para iOS 16. Un iPhone 8 o X totalmente actualizado bloquea esta campaña, pero puede seguir teniendo otros fallos de WebKit que los iPhone más recientes ya no tienen. iOS 16 recibe correcciones ocasionales, no todas, y la distancia entre él y el iOS actual crece con el tiempo.
Lo que esto significa en la práctica:
- Un teléfono con iOS 16.7.7 o anterior está expuesto a la cadena A. Actualiza hoy mismo a iOS 16.7.16: en Ajustes, luego General y luego Actualización de software.
- Un teléfono con iOS 16.7.16 está a salvo de esta campaña, pero no debe considerarse completamente parcheado. Resérvalo para llamadas, mensajes y navegación, y pasa las cuentas bancarias y de trabajo a un teléfono más reciente.
- Un teléfono que ya no recibe ninguna actualización debería retirarse. Irá acumulando fallos del navegador sin corregir.
La versión actual de iOS 16, la 16.7.16, llegó el 11 de mayo de 2026, según las notas de la versión de Apple.
¿Qué hay de los teléfonos Android y de Chrome?
La tercera cadena apunta a Android, no a iOS. Combina CVE-2026-3910, un fallo de Chrome, con CVE-2025-27038, un fallo de un controlador gráfico de Qualcomm. Según Sekoia, roba las cookies de Chrome, los inicios de sesión guardados, el historial de navegación y los ajustes de Wi-Fi.
El fallo de Chrome se corrigió el 12 de marzo de 2026 en Chrome 146, tanto en escritorio como en Android. Google indicó en su momento que ya había un exploit en circulación. Eso significa que aquí rige la misma regla: los teléfonos afectados son los que ejecutan Chrome 139 a 145, versiones que dejaron de recibir actualizaciones antes de marzo de 2026.
En Android importan dos actualizaciones separadas, y no llegan juntas:
- El navegador: abre la Play Store, busca Chrome y toca Actualizar. Puedes comprobar la versión instalada en los ajustes de Chrome, en Acerca de Chrome. Necesitas la versión 146 o posterior.
- El sistema operativo: el fallo del controlador de Qualcomm se corrige mediante las actualizaciones del sistema Android, en Ajustes, y luego en Sistema o Actualización de software. Un Chrome actualizado sobre un sistema Android sin parchear sigue arrastrando la segunda mitad de la cadena.
Que el parche del controlador llegue a un teléfono concreto depende de que su fabricante envíe actualizaciones del sistema. Un teléfono que no recibe ninguna debería retirarse, igual que un iPhone antiguo. El riesgo se concentra en teléfonos cuyos dueños nunca instalan las actualizaciones que sí reciben, que es justo el patrón de las tres cadenas de esta campaña. Si tu Chrome lleva meses anclado en la versión 145 o inferior, tómalo como un aviso para buscar actualizaciones hoy mismo.
Qué deberías hacer hoy
Las correcciones son actualizaciones ordinarias, y cada fallo de esta campaña fue parcheado por el fabricante antes de que empezaran los ataques.
- En un iPhone, ve a Ajustes, luego a General y después a Actualización de software, e instala lo que aparezca. Los dueños de un iPhone 8, 8 Plus o X deberían quedarse en iOS 16.7.16 o posterior.
- En Android, abre la Play Store, busca Chrome y toca Actualizar. Comprueba el resultado en los ajustes de Chrome, en la sección Acerca de Chrome. Necesitas la versión 146 o posterior.
- Instala las actualizaciones del sistema Android por separado, en Ajustes y luego en Sistema o Actualización de software. La actualización del navegador por sí sola no cierra toda la cadena.
- Si tu teléfono ya no recibe ninguna actualización, deja de usarlo para banca, cuentas de trabajo y compras. Pasa esas cuentas a un dispositivo que sí reciba parches.
- Si usas un iPhone 8, 8 Plus o X para algo sensible, empieza a planear su reemplazo. Arreglos ocasionales no equivalen a soporte completo.
- Sekoia no encontró persistencia, así que nada queda en el teléfono tras un reinicio, pero las cookies ya capturadas siguen capturadas; si un teléfono sin parchear puede haber cargado una de estas páginas, cierra todas las sesiones de tus cuentas importantes y vuelve a iniciar sesión.
Nada de esto es un consejo nuevo. Es la misma rutina que describimos en nuestro artículo de 2014 sobre un fallo SSL de Apple: buscar actualizaciones, instalarlas y repetir. Nuestro centro de seguridad móvil reúne más de estos básicos en un solo lugar.
¿Puede una VPN protegerte de un exploit de navegador?
No. Una VPN cifra el tráfico entre tu dispositivo y el servidor VPN y oculta tu dirección IP ante los sitios que visitas. Te protege en el Wi-Fi público, algo que tratamos en nuestro artículo sobre el Wi-Fi público. No parchea Safari ni Chrome, y no inspecciona las páginas que cargas.
Los exploits de esta campaña llegaron a través del propio navegador. Si una página comprometida sirve un exploit, ese exploit llega dentro del túnel cifrado igual que el resto de la página. La VPN ve un flujo de tráfico cifrado hacia un servidor; no tiene forma de distinguir una página hostil de una inofensiva. El cifrado protege los datos en tránsito, no el código que tu navegador ejecuta una vez que llegan.
Donde una VPN sí ayuda es en el resto de tu uso del móvil. En el Wi-Fi de un hotel, un aeropuerto o una cafetería, mantiene tu tráfico alejado de cualquier otra persona en esa red. Es lo que se describe en nuestro artículo sobre el Wi-Fi público. Es un problema distinto del que explota esta campaña.
Las dos capas hacen trabajos diferentes. Las actualizaciones cierran los fallos de los que dependen los exploits de navegador. Una VPN protege tu tráfico en redes que no controlas. Una VPN es una capa, y las actualizaciones son la otra.
Sobre el autor
Mesa de noticias de Le VPN
Le VPN Research Team es la mesa de noticias del blog de Le VPN. El equipo sigue en tiempo real los cortes de internet, la censura, las nuevas leyes de privacidad y los incidentes de ciberseguridad, y los convierte en artículos claros y con fuentes verificables. Cada artículo se elabora a partir de fuentes primarias, se contrasta con ellas y se revisa según las normas editoriales de Le VPN antes de publicarse.
Artículos de Le VPN Research Team →