El 7 de mayo de 2026, investigadores de XLab en Qianxin empezaron a detectar algo preocupante: cientos de sitios web legítimos — universidades, medios, empresas de IA — estaban sirviendo JavaScript malicioso a sus visitantes. No era un ataque de fuerza bruta ni un zero-day recién descubierto. Era una vulnerabilidad de inyección SQL en Ghost CMS, CVE-2026-26980, que Ghost había parcheado el 19 de febrero. Tres meses antes.
Si gestionas webs con CMS — WordPress, Ghost, lo que sea — esto debería ponerte los pelos de punta. No porque Ghost sea especialmente inseguro, sino porque el caso demuestra algo que llevo años viendo en el sector: el cuello de botella no es el parche, es la aplicación del parche.
La vulnerabilidad es grave. CVSS 9.4, inyección SQL ciega sin autenticación en la Content API de Ghost, versiones 3.24.0 a 6.19.0. Un atacante puede extraer el contenido completo de la base de datos, incluidas las Admin API keys, sin credenciales. Con esas claves, modifica artículos en bloque e inyecta código JavaScript en cada página. Según el informe de XLab, para el 17 de mayo ya habían confirmado más de 700 dominios envenenados.
Entre los afectados aparecen nombres que cualquier usuario confiaría: Harvard, Oxford, DuckDuckGo, Auburn University. Sitios que un estudiante, un investigador o un cliente visitaría sin pensarlo dos veces. Y ahí está el truco: los atacantes no necesitan hackear a Harvard directamente. Solo necesitan que alguien no actualizara Ghost desde febrero.
Lo que me choca no es la gravedad técnica — eso ya lo sabemos — sino la cronología. Ghost publicó el parche el 19 de febrero. El timestamp de compilación de un DLL usado en los ataques apunta al 16 de febrero, tres días antes del anuncio oficial. Los investigadores de la Cloud Security Alliance documentan que la vulnerabilidad fue descubierta mediante análisis asistido por IA, lo que acorta aún más la ventana entre descubrimiento y explotación masiva. Los atacantes no esperaron a que saliera en los titulares: esperaron a que saliera el parche y contaron con que nadie lo instalaría.
Y acertaron.
El vector final es un ataque ClickFix, una técnica de ingeniería social que ya lleva tiempo circulando. El JavaScript inyectado muestra una página falsa de verificación Cloudflare. El usuario ve un captcha que no funciona, recibe instrucciones para pulsar Windows+R, pegar un comando y pulsar Enter. En la práctica, ejecuta PowerShell o mshta y descarga malware. El sitio comprometido no infecta directamente: convence al visitante de que se infecte solo. Brutal en su simplicidad.
Según Security Affairs, al menos dos grupos de amenaza compiten por implantar sus propios payloads en los mismos sitios ya comprometidos. Es decir: no solo hay 700 víctimas, hay actores peleándose por ellas. Eso te dice todo lo que necesitas saber sobre la urgencia real del parche versus la urgencia percibida por quien mantiene esos servidores.
Ahora, si usas WordPress y te estás frotando las manos pensando que esto no va contigo, para. Ghost no es WordPress, pero el patrón es idéntico. Plugin desactualizado, tema sin mantener, versión de PHP obsoleta, backup que nadie prueba. La diferencia es que Ghost tiene un parque instalado más pequeño — unas 100.000 webs activas según distintas fuentes — y aun así más de 700 confirmadas comprometidas representan una proporción que no debería existir tres meses después del parche.
¿Por qué pasa esto? En mi experiencia, tres razones se repiten.
Primera: el CMS no es el negocio. Si tienes una web corporativa, un blog de producto o un portal universitario, actualizar Ghost (o WordPress, o lo que sea) compite con funcionalidades, campañas y plazos de entrega. El parche de seguridad no genera ingresos visibles. Se pospone.
Segunda: la ilusión del hosting gestionado. Muchos creen que si pagan un VPS o un PaaS, alguien actualiza el software de aplicación. No. El proveedor actualiza el sistema operativo, quizá el runtime. Tu Ghost, tu WordPress, tu stack entero: tuyo. Si no tienes un proceso de actualización documentado, no tienes proceso.
Tercera: la comunicación del vendor. Ghost publicó el aviso de seguridad, sí. Pero ¿cuántos administradores de esos 700 sitios lo leyeron? ¿Cuántos tienen alertas configuradas en GitHub Advisory o en un canal RSS de seguridad? La industria asume que todo el mundo sigue GHSA-2026-26980 en tiempo real. No es así.
Lo irónico es que Ghost, como plataforma, se vende precisamente como alternativa ligera y moderna a WordPress. Menos plugins, menos superficie de ataque, stack Node.js limpio. Y técnicamente, el argumento tiene sentido: una vulnerabilidad crítica en la API es un fallo puntual, no un ecosistema de 60.000 plugins abandonados. Pero un CMS minimalista con parche disponible desde febrero y 700 sitios comprometidos en mayo demuestra que la simplicidad del código no sustituye la disciplina operativa.
Si tienes Ghost, la checklist es corta: actualiza a la versión 6.19.1 o superior ya, rota todas las Admin API keys, revisa el contenido publicado buscando scripts inyectados al final de artículos, y audita los logs de acceso a la Admin API desde febrero. Si tienes WordPress u otro CMS, la checklist es la misma con otros números de versión.
Y si eres visitante de webs — lo somos todos — fíjate en algo: una página de verificación Cloudflare que te pide abrir el cuadro Ejecutar de Windows no es Cloudflare. Nunca lo ha sido. Pero cuando viene incrustada en ox.ac.uk o en el blog de una empresa de ciberseguridad que olvidó parchear, la diferencia entre legítimo y falso se desdibuja.
Lo que más me preocupa de este caso no es Ghost en sí. Es que confirma un modelo de ataque cada vez más rentable: explotar parches ya publicados en instalaciones que nadie mantiene, usar dominios de confianza como vector de entrega, y dejar que la víctima ejecute el payload. No necesitas un zero-day caro si tienes tres meses de ventana y 100.000 posibles objetivos.
¿Cuánto tiempo lleva tu último CMS sin actualizar, y tienes claro quién es responsable de instalar el parche cuando salga el siguiente CVE crítico?