Durante años repetimos el mismo consejo: "mantén todo actualizado". Sigue siendo correcto, pero en octubre de 2026 dos casos mostraron su lado incómodo. Un plugin SEO de WordPress y una herramienta de línea de comandos de un proveedor de nube se distribuyeron con malware desde sus canales oficiales. Quienes actualizaron rápido fueron justamente los afectados.
Esto es un ataque a la cadena de suministro de software: en lugar de atacar a cada empresa por separado, el atacante compromete a un proveedor de software y deja que la actualización legítima haga el resto. Una sola intrusión le da acceso a miles de sitios o equipos a la vez, y además lo hace con la confianza que el usuario ya tiene en ese proveedor.
Caso 1: Rank Math PRO, el plugin oficial con backdoor
Rank Math es uno de los plugins SEO más usados en WordPress. Según el aviso oficial del fabricante, la versión PRO 3.0.123 descargada entre el 15 de octubre de 2026 a las 20:02 UTC y el 16 de octubre a las 07:12 UTC contenía malware capaz de comprometer el sitio si el plugin se activaba. En hora de Lima, la ventana fue del 15 de octubre a las 15:02 al 16 de octubre a las 02:12. La versión gratuita de WordPress.org no se vio afectada y el fabricante publicó la versión limpia 3.0.124.
Lo relevante para cualquier empresa es lo que hacía el malware, según el propio aviso:
- Creaba cuentas de administrador ocultas con nombres que empezaban por
wpsupport_. - Dejaba archivos backdoor en
mu-plugins, en carpetas de otros plugins y temas, e incluso un falso archivo del núcleo de WordPress. - Agregaba tareas programadas y reglas en
.htaccesspara volver a instalarse aunque se borraran sus archivos. - Se comunicaba con un dominio externo (
rank1cdn.com).
Según BleepingComputer y SecurityWeek, el código también podía robar credenciales de AWS, Cloudflare, Google Cloud, Azure y llaves SSH. Por eso el fabricante pide algo que pocos esperan leer en un aviso de un plugin: si se activó esa versión, hay que tratar el sitio como comprometido y restaurarlo desde un respaldo anterior al incidente.
Caso 2: el CLI de OVHcloud, alterado directamente en GitHub
El segundo caso afectó a desarrolladores y administradores de sistemas. Según BleepingComputer, un atacante tomó control de la cuenta de GitHub de un desarrollador con acceso al repositorio del CLI de OVHcloud y modificó las versiones 0.11.0 a 0.15.0 para incluir un infostealer, un programa que busca y roba secretos guardados en el disco. Las versiones alteradas estuvieron disponibles el 19 de octubre durante poco más de hora y media, hasta que un cliente lo reportó.
Dos detalles del caso enseñan mucho:
- Los pipelines de CI/CD no se tocaron. Las pruebas unitarias, las pruebas funcionales y el escaneo de vulnerabilidades siguieron funcionando normalmente. El atacante subió binarios compilados por su cuenta, directamente como archivos de la release.
- La protección existía, pero estaba desactivada. GitHub ofrece una opción para que las releases publicadas no se puedan modificar (release immutability). No estaba activa, así que una cuenta con permisos suficientes pudo reemplazar los archivos. OVHcloud la activó después del incidente.
La recomendación oficial es actualizar a la versión 0.16.0 y, si se ejecutó una versión afectada, considerar comprometidos todos los secretos de ese equipo y cambiarlos. Los investigadores de OpenSourceMalware además vinculan el ataque con GlassWorm, una campaña que viene afectando a extensiones de VSCode, paquetes de npm y repositorios de GitHub, y señalan que la cuenta usada llevaba más de medio año comprometida.
Si instalaste una versión comprometida: qué hacer
Tomando como base los pasos del aviso de Rank Math, que sirven como guía para casi cualquier compromiso de este tipo:
- Confirmar la exposición: qué versión se instaló, cuándo y si llegó a activarse o ejecutarse.
- Restaurar desde un respaldo limpio, anterior al inicio del incidente. Si no hay respaldo, la limpieza manual debe empezar por cortar el mecanismo que reinstala el malware, porque si no los archivos vuelven a aparecer.
- Buscar cuentas de administrador desconocidas y eliminarlas.
- Revisar tareas programadas, archivos
.htaccessy carpetas donde no debería haber código, comouploads/. - Rotar todas las credenciales: contraseñas de WordPress, base de datos, claves y salts de
wp-config.php, llaves de API, accesos al hosting, FTP/SFTP y SSH. Esto se hace aunque se haya restaurado un respaldo, porque el atacante pudo copiarlas antes. - Vigilar las conexiones salientes durante los días siguientes y confirmar que los archivos eliminados no reaparecen.
Prevención: actualizar con criterio, no a ciegas
La solución no es dejar de actualizar: una vulnerabilidad sin parchear sigue siendo un riesgo mayor. Lo que cambia es la forma de hacerlo.
| Control | Para qué sirve | Cómo aplicarlo |
|---|---|---|
| Inventario | Saber rápido si un aviso te afecta. | Lista de plugins, temas, librerías y herramientas instaladas, con versión y responsable. |
| Ventana de espera | Evitar ser de los primeros en instalar una versión maliciosa. | Esperar unos días antes de llevar a producción actualizaciones que no sean de seguridad urgente. |
| Entorno de pruebas | Detectar comportamientos extraños antes de que lleguen a producción. | Probar las actualizaciones primero en una copia del sitio o sistema. |
| Versiones y hashes fijos | Garantizar que se instala exactamente lo que se revisó. | Fijar versiones en los proyectos y verificar los hashes de los paquetes descargados. |
| Mínimo privilegio | Limitar lo que puede hacer el malware si entra. | El servidor web no debe poder escribir donde no lo necesita ni tener llaves de nube a mano. |
| Monitoreo de salida | Ver cuando un servidor empieza a hablar con un destino desconocido. | Registrar y alertar sobre conexiones salientes nuevas desde servidores web y equipos de desarrollo. |
| Cuentas de desarrolladores | Evitar el escenario de OVHcloud. | MFA obligatorio en GitHub y similares, releases inmutables y revisión periódica de quién tiene permisos de publicación. |
Los respaldos: probarlos antes de necesitarlos
En el caso de Rank Math, la opción recomendada era restaurar un respaldo anterior al 15 de octubre. Muchas empresas descubren en ese momento que su respaldo no sirve: está en el mismo servidor comprometido, solo incluye los archivos y no la base de datos, o nadie sabe cuánto tarda la restauración. Tres reglas básicas:
- Guardar los respaldos fuera del servidor, en un lugar al que el sitio no pueda escribir ni borrar.
- Conservar varios días de historial, no solo la copia de anoche. Un compromiso puede pasar desapercibido por días.
- Hacer una restauración real de prueba y medir cuánto tiempo toma. Un respaldo que nunca se restauró es una suposición, no un plan.
Lo que vemos desde el NOC
En los dos casos hay una señal en común que el monitoreo puede detectar: el equipo comprometido empieza a conectarse a un destino nuevo. Un servidor web que de pronto contacta un dominio que nunca había visitado, o una laptop de desarrollo que envía datos fuera de horario, son alertas que vale la pena revisar en minutos y no en semanas. El monitoreo no evita que se instale una versión maliciosa, pero sí acorta el tiempo entre la infección y la respuesta, y en este tipo de incidentes ese tiempo define cuántos secretos llega a llevarse el atacante.
Cómo puede ayudar GESITEC
- GST Escudo: auditoría de seguridad de sitios WordPress, pentesting y apoyo en la respuesta a incidentes cuando se sospecha de un compromiso.
- GESITEC Technology: mantenimiento web con entorno de pruebas, actualizaciones controladas y respaldos verificados, y monitoreo continuo con GST Vigía.
- GST Guía: gobierno de TI y gestión de proveedores de software, incluyendo inventario de dependencias y criterios para aprobar nuevas herramientas.
Conclusión
Rank Math PRO y el CLI de OVHcloud muestran que la confianza en un proveedor ya no basta como control de seguridad. Actualizar sigue siendo necesario, pero hay que saber qué se instala, probarlo antes de llevarlo a producción, limitar lo que cada sistema puede hacer y tener respaldos que funcionen de verdad. Cuando la actualización es el ataque, lo que marca la diferencia es haberse preparado antes.