Caso real: limpié una infección WordPress causada por WPMU DEV Dashboard

Detecté archivos y directorios sospechosos en dos instalaciones WordPress que estaban bajo mi mantenimiento.

La prioridad no fue encontrar una explicación perfecta en ese primer momento. Primero tenía que contener la incidencia, recuperar el servicio y eliminar el componente vulnerable que había permitido el compromiso.

Detecté indicadores de compromiso

Las dos webs presentaban un patrón parecido: directorios extraños en la raíz y archivos compatibles con una infección web.

No empecé atribuyendo el incidente a una vulnerabilidad concreta. Un archivo malicioso confirma un compromiso, pero no responde automáticamente cómo entró el atacante ni qué mecanismo podía seguir activo.

Revisé los plugins presentes y encontré wpmudev-updates, el plugin WPMU DEV Dashboard, instalado en ambas webs.

No atribuí la instalación del plugin a una persona concreta. Había varias cuentas con permisos de administración y el origen de esa decisión no era relevante para contener la incidencia. Lo relevante era que el componente vulnerable estaba presente en las dos instalaciones afectadas.

Confirmé el vector de compromiso

Durante la revisión confirmé que el incidente estaba relacionado con CVE-2026-15459, una vulnerabilidad de autenticación en WPMU DEV Dashboard hasta la versión 5.0.0.

El escenario afectado era concreto: instalaciones que no estaban conectadas a WPMU DEV Hub y podían tener vacía la clave API utilizada por el mecanismo de autenticación remota. En esas condiciones, un atacante no autenticado podía invocar acciones privilegiadas, incluida la instalación y activación de un plugin desde una URL controlada por el atacante.[1][2]

Ese comportamiento explicaba los indicadores que había encontrado. La vulnerabilidad permitió el compromiso y dejó la instalación expuesta a la incorporación de código ejecutable desde fuera.

Contuve la incidencia antes de cerrar la investigación

Restauré copias de seguridad anteriores a la detección de la infección. Mi objetivo era retirar rápidamente los directorios creados por el atacante, las posibles webshells y cualquier modificación introducida en plugins o temas.

Después eliminé completamente el directorio del plugin:

wp-content/plugins/wpmudev-updates

No lo desactivé simplemente. El componente vulnerable había formado parte del vector de compromiso, así que lo retiré por completo antes de continuar con la recuperación y la revisión de persistencia.

A continuación actualicé todos los componentes que podían actualizarse con la versión de PHP disponible.

La restauración resolvió la urgencia, no toda la revisión forense

Tras restaurar, las webs volvieron a estar operativas. A continuación completé una revisión de integridad para comprobar que no quedaran mecanismos de persistencia.

Ejecuté en cada instalación:

wp core verify-checksums
wp plugin verify-checksums --all
wp user list --role=administrator

También revisé manualmente:

• PHP dentro de wp-content/uploads.
• MU plugins y drop-ins.
• wp-config.php, .htaccess y archivos de configuración PHP.
• Tareas WP-Cron y cron del sistema.
• Opciones de base de datos, payloads ofuscados y referencias residuales a WPMU DEV.
• Logs disponibles en torno al momento de la infección.

Completé la revisión en las dos instalaciones por separado. La restauración resolvió la urgencia; estas comprobaciones me permitieron confirmar que no quedaba persistencia identificada antes de cerrar la intervención.

Detecté una segunda limitación: PHP 7.4

La suscripción seguía trabajando con PHP 7.4 porque uno o varios componentes fallaban al probar una versión más reciente.

Eso introducía deuda técnica. Aunque hubiera aplicado todas las actualizaciones compatibles, la limitación de PHP dificultaba mantener otros componentes en versiones actuales a medio plazo.

No forcé un cambio de PHP en producción mientras estaba respondiendo a una infección. Primero necesitaba identificar qué plugin o tema fallaba, reproducir el error en un entorno de pruebas y decidir si convenía actualizarlo, sustituirlo o adaptarlo.

Migrar PHP sin acotar antes el problema podía resolver una vulnerabilidad y generar una caída del servicio.

Roté accesos y activé vigilancia posterior

Una vez contenida la incidencia, roté:

• Contraseñas de las cuentas administradoras de WordPress.
• Salts de WordPress.
• Credenciales FTP o SFTP.
• Acceso a la suscripción de hosting.
• Credenciales de base de datos cuando correspondiese.
• Claves SMTP, API y otros secretos almacenados en WordPress.

También incorporé monitorización posterior, revisé los resultados de escaneo y controlé la creación de archivos nuevos.

Si un archivo malicioso vuelve después de una limpieza, el problema ya no es solo qué archivo borrar. Hay que averiguar qué lo está escribiendo, desde dónde se ejecuta y qué permisos conserva.

Como parte de ese proceso reinicié PHP-FPM —o el servicio PHP equivalente— y vacié OPcache. OPcache no recrea por sí mismo un archivo eliminado, pero puede conservar bytecode en memoria y dificultar la validación de que la limpieza ya es efectiva.

Lo que pude concluir y lo que no

Pude concluir que las instalaciones estaban comprometidas mediante la explotación de CVE-2026-15459 en WPMU DEV Dashboard. Contuve el incidente con restauraciones previas, eliminación del plugin y actualizaciones disponibles.

No atribuí quién instaló el plugin ni cómo llegó a estar presente. Había varias cuentas con permisos administrativos y esa atribución no era necesaria para la respuesta técnica. El foco fue eliminar el componente vulnerable, recuperar las instalaciones y comprobar que no quedara persistencia.

La lección de este caso fue sencilla: un plugin vulnerable puede comprometer una web. Tras contener el incidente, la limpieza debe incluir una revisión posterior que confirme que no queda persistencia.

En WP Seguridad realizo desinfecciones y revisiones de integridad de WordPress para localizar archivos, accesos y mecanismos de persistencia antes de dar un incidente por cerrado. El mantenimiento de seguridad WordPress ayuda después a reducir el tiempo de exposición ante componentes vulnerables, cambios inesperados y deuda técnica acumulada.

Fuentes

[1] CVE-2026-15459: WPMU DEV Dashboard ≤ 5.0.0.

[2] INCIBE-CERT: CVE-2026-15459.