Un día cero en diciembre, munición de serie en agosto

El 12 de diciembre de 2025, Apple corrigió un fallo de WebKit con una de esas frases que se leen por encima: sabía de un informe según el cual podía haber sido explotado «en un ataque extremadamente sofisticado contra personas concretas». Traducción práctica para una pyme: esto es espionaje caro y no va contigo. Doscientos cincuenta y ocho días después, ese mismo fallo se le servía a cualquiera que abriese la web de una empresa gasista con un iPhone sin actualizar.

El 4 de noviembre, la firma francesa Sekoia publicó el análisis de esa campaña. Tres cadenas de exploits —dos contra iOS y una contra Android— servidas desde webs legítimas durante una semana de finales de agosto de 2026. Y una frase en medio del informe: «Las tres cadenas de exploits se apoyan por completo en vulnerabilidades conocidas y ya parcheadas. Ninguna contiene días cero ni funciona contra dispositivos completamente actualizados. Cada fallo fue resuelto por su fabricante antes de que empezara esta campaña.»

De todo esto nos quedamos con la columna que no aparece en ningún titular: cuántos días llevaba publicado el parche de cada pieza cuando se disparó. Y con el aparato por el que entraba todo, que era el teléfono y no el servidor: la única parte del parque que en la mayoría de empresas no tiene inventario, ni ventana de actualización, ni dueño.

Siete días dentro de la web de otro

Lo que cuesta digerir de esta campaña es cómo llegó. Entre el 27 de agosto y el 3 de septiembre de 2026, el atacante metió código en el fichero de un servicio ucraniano de analítica web, Plerdy, que cargan miles de páginas. El añadido cabe en cinco líneas: al terminar de cargar la página, crear una etiqueta script, apuntarla a un dominio ajeno y colgarla del documento. Eso es todo. El resto lo hacía el navegador del visitante, obedeciendo.

Durante esa semana, según Sekoia, quedaron expuestos cientos de sitios —entre ellos páginas de ejército, fuerzas especiales y material militar—, además de webs comprometidas una a una: una gasista ucraniana, una asociación sectorial de la industria química estadounidense, un partido político europeo de extrema derecha y un sitio militar búlgaro. Y dos dominios falsos que hacían de espejo de sitios reales. Nadie descargó un adjunto. Nadie hizo clic en un correo raro. La gente abrió una página que llevaba años visitando.

El perímetro de tu web no es tu código. Es la lista de dominios a los que tus páginas le dicen al navegador del visitante que se puede fiar. Analítica, mapas, chat, fuentes tipográficas, el píxel de la campaña que montó alguien en 2019. De esto ya escribimos a cuenta de otra cosa, cuando contamos que tu inventario no tiene una línea para Brotli: el problema llega cuando esa lista no existe en ningún sitio.

La edad de cada pieza

Esta tabla la hemos montado nosotros cruzando las cadenas que describe Sekoia con las fechas de los avisos de cada fabricante. La última columna son días naturales hasta el 27 de agosto de 2026, el día que arrancó la campaña.

Faltan tres piezas de la cadena larga de iOS —CVE-2025-14174, CVE-2025-43510 y CVE-2025-43520— que también estaban corregidas: la primera es de WebKit y salió el mismo 12 de diciembre; las dos del núcleo se arreglaron antes, el 5 de noviembre de 2025 en iOS 18.7.2 —295 días—, aunque Apple no añadió sus entradas a esa página hasta el 12 de diciembre. Y sobran cuatro más: el kit llevaba dentro dos fallos de 2024 como código muerto, inalcanzable —Sekoia dice que probablemente de una versión anterior de la herramienta— y dos vías alternativas que no se llegaban a usar. Un exploit con deuda técnica. De dónde viene esa deuda lo cuenta el propio informe dos apartados más abajo.

La fila de Qualcomm merece una nota, porque es la que peor se traduce a una acción. El boletín del fabricante es del 2 de junio de 2025 —y ahí Qualcomm ya escribía que había indicios de Google TAG de explotación «limitada y dirigida», o sea que también empezó siendo un día cero—, pero el parche de un controlador gráfico no llega al teléfono cuando Qualcomm lo publica: llega cuando el fabricante del aparato lo integra y lo distribuye, si lo hace. Ya lo contamos con otra capa del mismo problema: el parche de Android no llega al módem. Si se cuenta desde el boletín de Android de agosto de 2025, que es cuando SecurityWeek lo sitúa, salen unos 387 días en vez de 451. Sigue siendo más de un año. La fila de Chrome tiene el mismo problema al revés y lo decimos antes de que nos lo digan: el 12 de marzo es la fecha del canal de escritorio, y la cadena ataca Chrome en Android; no hemos podido fijar con fuente primaria el día exacto del canal de Android, así que los 168 son nuestra cuenta sobre la fecha de escritorio. Y hay una tercera: el salto de PAC de la cadena larga se corrigió el 11 de febrero en iOS 26.3, y no hemos encontrado página de Apple que fije cuándo llegó ese arreglo a la rama 18.x. Si no llegó, para un iPhone en 18.5 el parche no estaba en su rama y los 197 días no son comparables con el resto.

Lo que paraba la cadena vieja era un punto decimal

La cadena corta apunta a iOS 16.7 y, según el informe, debería funcionar de la 16.0 a la 17.4 —«should work», escribe Sekoia; es su estimación, no una matriz probada—. No es casualidad que el techo caiga justo ahí: su segunda pieza, el salto de Pointer Authentication, la corrigió Apple en la 17.5. Y la ficha de ese fallo trae un detalle que está en la lista de versiones corregidas y casi nadie abre: también se arregló en iOS 16.7.8, el 13 de mayo de 2024, dentro de la propia rama 16.

Conviene ser exactos con para quién existe esa versión, porque es lo que sostiene el argumento: Apple publicó iOS 16.7.8 solo para iPhone 8, 8 Plus, iPhone X, iPad de 5.ª generación y los dos primeros iPad Pro, es decir, para los aparatos que no pueden subir a iOS 17. A un iPhone 11 aparcado en la 16.7 no se le ofrece la 16.7.8: se le ofrece la 17.5, que corrige lo mismo. En los dos casos el arreglo estaba a un botón de distancia y no hacía falta cambiar de teléfono.

Y la rama no se quedó en 2024. Apple publicó iOS 16.7.16 el 11 de mayo de 2026 para esos mismos modelos: 108 días antes de que empezara la campaña. Un teléfono que marcaba «16.7» a secas iba ocho actualizaciones por detrás de una rama que seguía viva tres meses antes del ataque. El 4 de noviembre, CISA metió ese salto de PAC en su catálogo de fallos explotados y dio a las agencias federales hasta el 18 de noviembre para arreglarlo; la pieza de entrada, CVE-2025-43529, ya estaba en el mismo catálogo con plazo del 5 de enero de 2026, ocho meses antes de la campaña.

Hay un detalle del informe que juega en contra de los propios atacantes y que conviene no esconder: el servidor que servía esta cadena filtraba por «iOS 16.7 / 16.7.10». La 16.7.10 es de agosto de 2024 y ya lleva dentro el arreglo del salto de PAC. Sekoia lo lee como lo mismo que el código muerto: operadores reutilizando exploits sin tocar el filtro. Es decir, parte de los disparos iban contra versiones donde uno de los dos eslabones ya estaba roto.

Este es el reverso del post que publicamos hace unas horas sobre parchear y seguir expuesto. Allí el fabricante dijo que había arreglado algo y no lo había arreglado: actualizar no servía de nada y no era culpa de nadie del lado del cliente. En la cadena corta de hoy pasa lo contrario. El parche existía, era gratuito, estaba en la rama correcta y funcionaba. La decisión fue nuestra. En la cadena larga, la contra iOS 18.5, no podemos decir lo mismo: mientras no sepamos cuándo llegó el arreglo del salto de PAC a la rama 18.x, hay que dejar abierta la posibilidad de que esos usuarios no tuvieran botón que pulsar.

El kit comprueba que eres un móvil antes de disparar

Antes de servir nada, el código perfila el aparato. Según Sekoia, tres campos pueden cancelar la entrega si sus valores no cuadran: el ancho y el alto de pantalla —descarta dimensiones imposibles para un teléfono, del tipo 99999— y navigator.maxTouchPoints a cero, que es como se delata un ordenador de sobremesa. En Android, además, solo dispara a Chrome de la versión 139 a la 145, saltándose la 143 por un motivo que el propio informe reconoce no saber. Y si detecta el identificador SM-S938B, un modelo concreto de teléfono, se detiene.

La conclusión operativa: la campaña se saltaba deliberadamente los equipos que sí están dentro de tu política de parcheo y apuntaba a los que no. La razón es que el teléfono es donde nadie mira la versión. Un portátil corporativo se actualiza porque hay una herramienta que lo obliga; un teléfono se actualiza cuando su usuario decide que ya está bien de posponer.

Y lo que se llevaban no era poco. En la cadena larga de iOS, según recoge SecurityWeek del informe: mensajes, correos, mensajes de voz, credenciales, tokens, contactos, llamadas, calendario, cookies e historial del navegador, fotos y contenido de iCloud Drive. En Android: cookies, información de cuenta, contraseñas, historial de navegación y claves de wifi. Si ese teléfono abre el correo de la empresa, acabas de perder la sesión de un buzón y, con las cookies, posiblemente el segundo factor de esa sesión.

De dónde salía el kit

El informe lo dice sin ceremonia, y es la parte que más cambia la lectura. Una de las cadenas de iOS es DarkSword, un kit que Sekoia describe como desarrollado presuntamente por un proveedor comercial de vigilancia, y la muestra servida en esta campaña «aprovecha el mismo RCE (CVE-2025-43529) que el disponible en el kit de exploits filtrado DarkSword». Filtrado de forma literal: el código completo apareció en un repositorio público de GitHub el 22 y 23 de marzo de 2026, 157 días antes de que arrancara la campaña, y quienes lo examinaron entonces dejaron escrito que era HTML y JavaScript, material que cualquiera puede copiar y servir desde un servidor propio en cuestión de horas.

Eso tira abajo la conclusión cómoda, que era la nuestra hasta leer el informe entero: que un servicio de inteligencia con presupuesto decidió no gastar sus días cero. Lo que pasó salió más barato todavía. Recogió del suelo un arma que llevaba cinco meses tirada. Y explica de una vez el código muerto, el filtro que apunta a versiones ya parcheadas y todo lo que parece descuido: son las marcas de usar la herramienta de otro.

Hace dos semanas contamos las cinco puertas de SafePay, ninguna de 2026, un ransomware que entraba por fallos viejos. La tentación es decir que esto juega en otra liga. Juega menos de lo que parece: la misma economía de munición reciclada, con la diferencia de que aquí el arma empezó siendo cara. Lo que ha bajado es el precio del equipamiento, y lo ha bajado hasta cero en cinco meses.

Las dos listas que casi nadie tiene

De todo esto salen dos entregables, y ninguno es comprar nada. En el puesto de trabajo gestionado esto es trabajo de una tarde, y la primera vez casi siempre aparece algo que nadie esperaba.

Antes de que esto se cuente mal

Cuatro acotaciones.

Si quieres empezar por algún sitio, empieza por la lista de teléfonos y sus versiones. No cuesta dinero y casi siempre devuelve el mismo resultado: hay tres o cuatro aparatos muy por detrás, y todos pertenecen a gente que viaja mucho. Si prefieres que la hagamos nosotros, escríbenos.

La frase que nos llevamos no es «actualiza el móvil». Es que un día cero tiene dos vidas. La primera dura semanas y se gasta contra gente con nombre y apellidos. La segunda empieza el día que sale el parche, dura exactamente lo que tú tardes en ponerlo, y se alarga cada vez que el arma cambia de manos y baja de precio.

Fuentes. Consultadas el 5 de noviembre de 2026. La campaña, las tres cadenas y sus CVE, las fechas del compromiso de Plerdy (27 de agosto a 3 de septiembre de 2026), el código inyectado, los sitios comprometidos y los dos dominios falsos, los filtros de pantalla, maxTouchPoints, versiones de Chrome y modelo excluido, el código muerto y la atribución con «confianza moderada a alta» son del informe de Sekoia «Poisoned Source: APT29 watering holes targets mobile devices with n-day exploits», publicado el 4 de noviembre de 2026. El detalle de lo que roba la carga de iOS y la ubicación del parche de Qualcomm en el boletín de Android de agosto de 2025 son de la cobertura de SecurityWeek. Las fechas y versiones de los parches de Apple, de sus propias páginas de contenido de seguridad: CVE-2024-27834 corregida el 13 de mayo de 2024 en Safari 17.5, iOS y iPadOS 17.5, iOS y iPadOS 16.7.8, macOS Sonoma 14.5, tvOS 17.5 y watchOS 10.5 (CVSS 5,5, crédito a Manfred Paul con la Zero Day Initiative de Trend Micro); CVE-2025-43529 y CVE-2025-14174 el 12 de diciembre de 2025, ambas de WebKit, en iOS y iPadOS 18.7.3 y 26.2, con la nota de Apple, que citamos abreviada en el texto y completa aquí: «Apple is aware of a report that this issue may have been exploited in an extremely sophisticated attack against specific targeted individuals on versions of iOS before iOS 26»; CVE-2025-43510 y CVE-2025-43520, del núcleo, en la página de iOS y iPadOS 18.7.2, con entradas añadidas el 12 de diciembre de 2025. CVE-2026-20700, parcheada el 11 de febrero de 2026. CVE-2026-3910, del motor V8, en la actualización del canal estable de Chrome del 12 de marzo de 2026 (versiones 146.0.7680.75 y .76). CVE-2025-27038, del controlador Adreno, en el boletín de seguridad de Qualcomm del 2 de junio de 2025, que ya hablaba de indicios de Google TAG de explotación limitada y dirigida. El alta de CVE-2024-27834 en el catálogo KEV de CISA el 4 de noviembre de 2026, con plazo federal el 18. La fuga pública de DarkSword en GitHub los días 22 y 23 de marzo de 2026, y la descripción del material como HTML y JavaScript reutilizable en cuestión de horas, son de la cobertura de TechCrunch del 23 de marzo de 2026; la identificación del kit y su vínculo con esta campaña, del propio informe de Sekoia. La existencia y la fecha de iOS y iPadOS 16.7.16, del 11 de mayo de 2026, y la lista de modelos a los que se ofrece esa rama son de la página de Apple correspondiente. Las cuentas de días son nuestras, calculadas sobre esas fechas hasta el 27 de agosto de 2026. Lo que no hemos podido verificar y por eso queda dicho en el texto: la fecha exacta del canal de Chrome para Android (tomamos la de escritorio) y la fecha en que el arreglo de CVE-2026-20700 llegó, si llegó, a la rama iOS 18.x. La lectura de que iOS 16.7.8 rompía la cadena corta es nuestra, y está marcada como tal en el texto; el criterio sobre inventario de dispositivos, políticas de acceso y dominios de terceros sale de nuestro propio trabajo y no lo respalda ninguna de esas fuentes.