Durante la primavera de 2026 se destapó uno de los ataques más sofisticados que ha sufrido el ecosistema de plugins de WordPress en los últimos años, y aunque ya se ha resuelto, el caso deja lecciones muy útiles para cualquier empresa que gestione su web sobre este CMS. No fue un fallo de seguridad clásico ni un descuido de un desarrollador: fue un ataque a la cadena de suministro, es decir, al propio canal por el que confiamos en recibir actualizaciones legítimas.
Qué ha pasado exactamente
Un atacante adquirió, de forma totalmente legal, varios plugins ya existentes y con buena reputación a través de un mercado de compraventa de proyectos digitales. Una vez tuvo el control de esas cuentas de desarrollador, distribuyó código malicioso camuflado dentro de actualizaciones normales, publicadas desde el propio repositorio oficial de WordPress.org. En total se vieron afectados 31 plugins con más de 400.000 instalaciones activas conjuntas, entre ellos algunos bastante populares como Widget Logic, Countdown Timer Ultimate o Popup Maker. En paralelo, un plugin de galerías con cerca de 800.000 instalaciones sufrió un compromiso similar en las mismas fechas.
Un backdoor que esperó ocho meses para activarse
Lo más inquietante no fue la distribución del malware, sino su comportamiento: el código permaneció completamente inactivo durante unos ocho meses, sin generar ningún síntoma visible, hasta que se activó de forma coordinada en todos los sitios infectados en cuestión de un par de días. El archivo malicioso imitaba el nombre de un fichero legítimo de WordPress, y una vez activo inyectaba enlaces de spam SEO invisibles para quien administra la web, pero perfectamente indexables por Google — dañando tanto la reputación como el posicionamiento del sitio sin que el propietario lo notara.
Por qué esto es distinto a "una vulnerabilidad más"
Cuando pensamos en seguridad de WordPress solemos imaginar un fallo de código que hay que parchear a tiempo. Este caso es distinto: el atacante no explotó ningún error, sino la confianza que depositamos en que quien firma una actualización es quien dice ser. Es el mismo tipo de riesgo que ha afectado a librerías de otros lenguajes de programación en los últimos años, y confirma que revisar solo si "todo está actualizado" ya no es suficiente para dar por segura una web empresarial.
Qué puede hacer tu empresa esta misma semana
No hace falta ser una gran corporación con un equipo de ciberseguridad propio para reducir mucho este riesgo. Con una empresa mediana y un mantenimiento web decente ya se cubre la mayor parte:
Elimina lo que no usas: cada plugin instalado —lo uses o no— es una puerta de entrada potencial. Desinstala (no solo desactives) los que ya no aportan nada.
Activa las actualizaciones automáticas del núcleo de WordPress y revisa periódicamente qué plugins siguen manteniéndose activamente por sus autores.
Instala un firewall a nivel de aplicación (Wordfence o Patchstack son opciones habituales) que analice el comportamiento del código, no solo la lista de vulnerabilidades conocidas.
Revisa Google Search Console con regularidad: es, muchas veces, la primera señal de que algo raro está pasando en tu web, como en el caso que ya vimos con el soporte de versiones antiguas de PHP.
Haz copias de seguridad automáticas y fuera del propio servidor, para poder restaurar una versión limpia si algo falla.
En resumen
Este caso no debería generar alarma, sino un recordatorio práctico: en una web empresarial, el mantenimiento no consiste solo en instalar actualizaciones sin mirar, sino en tener a alguien revisando periódicamente qué plugins hay instalados, de dónde vienen y si siguen siendo necesarios. Para una empresa mediana en Barcelona, el Baix Llobregat o Madrid, delegar esa vigilancia en un servicio de mantenimiento profesional suele salir mucho más barato que gestionar las consecuencias de una infección después de que haya ocurrido.