La cadena de suministro del ecosistema WordPress ha vuelto a ser el escenario de un ataque devastador. Versiones maliciosas del plugin Admin Menu Editor Pro fueron distribuidas a más de 200 clientes después de que un atacante comprometiera el sitio web del mantenedor y publicara actualizaciones que creaban una cuenta de usuario oculta.
El resultado: al menos 1.500 sitios web infectados, una cifra que podría crecer a medida que avanza la investigación. Lo que hace especialmente alarmante este incidente es su mecánica: no se trató de un ataque a la infraestructura de WordPress ni a la tienda oficial de plugins, sino a la web del propio desarrollador, un eslabón que muchos usuarios consideran seguro por defecto.
El desarrollador Janis Elsts ha confirmado que un tercero no autorizado accedió a adminmenueditor.com el lunes y subió la versión 2.35 como actualización de la versión Pro del plugin. Esa actualización incluía un archivo includes/wp-user-consent.php que instalaba un web shell en los sitios afectados.
Luego de detectar la intrusión, Elsts eliminó la actualización maliciosa y publicó una versión limpia (la 2.36) el mismo día a las 19:00 UTC. Aunque el atacante aún tenía acceso al sitio web y comprometió también la nueva versión. Es un recordatorio brutal de que, una vez que un atacante obtiene acceso root a un servidor, la confianza en las actualizaciones se rompe por completo.
La cronología de un ataque en dos actos
El incidente se desarrolló en cuestión de horas, pero su impacto se extenderá durante meses. La versión maliciosa 2.35 estuvo disponible en el sitio web oficial desde aproximadamente las 06:00 hasta las 13:00 UTC.
En ese período, más de 230 clientes descargaron e instalaron la actualización en al menos 1.500 sitios. Muchos de ellos gestionan múltiples instalaciones de WordPress para sus propios clientes, lo que multiplicó el alcance del ataque.
Cuando Elsts detectó la intrusión y publicó la versión 2.36 como corrección, el atacante respondió comprometiendo también esa versión. El desarrollador, al comprender que el atacante tenía acceso a nivel de root al servidor, tomó la decisión de desconectar el sitio web por completo hasta poder restaurarlo con garantías.
El desarrollador ha señalado que varios cientos de clientes adicionales descargaron el plugin en la ventana temporal relevante y podrían haber sido afectados. La cifra exacta de víctimas es difícil de determinar porque no todos los clientes tienen habilitadas las actualizaciones automáticas ni registran las versiones que instalan.
Las señales de compromiso: cómo saber si tu sitio ha sido infectado
Elsts ha publicado una lista de indicadores que permiten a los administradores verificar si sus sitios han sido comprometidos. Cualquier instalación que haya utilizado las versiones 2.35 o 2.36 de Admin Menu Editor Pro debe revisar los siguientes elementos:
- La presencia del archivo
includes/wp-user-consent.phpen el directorio del plugin - Un nuevo directorio
/wp-content/object-cache/ - Un usuario que comience con
wp_en la tablawp_usersde la base de datos, que puede estar oculto en el panel de WordPress - Opciones con nombres como
wp_ocache*en la tablawp_options
La versión 2.34 se considera limpia, y la versión gratuita de Admin Menu Editor no parece estar afectada. Es una distinción importante: el ataque se dirigió específicamente a la versión premium, que se distribuye a través del sitio web del desarrollador y no a través del repositorio oficial de WordPress.org.
La solución de restaurar desde una copia de seguridad limpia
Elsts ha sido claro sobre cuál es la solución más fiable. Restaurar el sitio comprometido desde una copia de seguridad segura anterior al 14 de septiembre es la única forma de garantizar que no queden rastros del atacante.
Si eso no es posible, el desarrollador recomienda eliminar el plugin, el directorio /wp-content/object-cache/ y las entradas de base de datos mencionadas. Aunque esta solución es menos segura: un atacante con acceso root puede haber dejado otras puertas traseras que no se detecten con una simple limpieza.
La recomendación de restaurar desde una copia de seguridad no es trivial. Implica que los administradores tengan copias de seguridad recientes y verificadas, algo que no siempre ocurre. Y también implica que esas copias de seguridad no estén comprometidas, lo que añade una capa adicional de complejidad.
El contexto: la vulnerabilidad estructural de la cadena de suministro de WordPress
Este incidente no es un caso aislado. Los plugins de WordPress son uno de los vectores de ataque más utilizados por los ciberdelincuentes porque ofrecen un acceso privilegiado a millones de sitios web con un esfuerzo relativamente bajo.
La comunidad de WordPress ha sufrido ataques similares en el pasado, y la lección que se repite una y otra vez es la misma: la confianza en el código de terceros es un riesgo que debe gestionarse activamente.
El caso de Admin Menu Editor Pro es especialmente ilustrativo porque el ataque no explotó una vulnerabilidad en el código del plugin, sino en la infraestructura del desarrollador. El atacante no necesitó encontrar un fallo en el software; simplemente necesitó acceder al servidor desde el que se distribuye.
Es una vulnerabilidad estructural del modelo de distribución de plugins premium, que a menudo se alojan en servidores propios en lugar de en el repositorio central de WordPress.org.
¿Qué pueden hacer los administradores para protegerse?
La primera recomendación es revisar si el sitio ha instalado alguna de las versiones comprometidas. Si es así, restaurar desde una copia de seguridad limpia es la opción más segura.
La segunda es auditar los usuarios y las opciones de la base de datos para detectar cuentas o configuraciones no autorizadas. La tercera es revisar los registros de acceso al servidor en busca de actividad sospechosa.
Pero la lección más importante es estructural. Los administradores de WordPress deben asumir que cualquier plugin, incluso los que provienen de fuentes aparentemente legítimas, puede convertirse en un vector de ataque.
Mantener copias de seguridad frecuentes y verificadas, limitar los privilegios de los usuarios, monitorizar los cambios en los archivos del sistema y desconfiar de las actualizaciones que llegan fuera de los canales oficiales son prácticas esenciales para reducir el riesgo.
El incidente de Admin Menu Editor Pro también subraya la importancia de la transparencia y la respuesta rápida por parte de los desarrolladores.
Elsts detectó el ataque, notificó a los clientes, publicó indicadores de compromiso y tomó medidas drásticas para proteger a los usuarios. Es un ejemplo de cómo debería gestionarse una crisis de seguridad, aunque el daño ya esté hecho.
El futuro de la seguridad en el ecosistema WordPress
La seguridad de WordPress no es responsabilidad de una sola persona ni de una sola empresa. Es un ecosistema complejo en el que participan desarrolladores, administradores, empresas de hosting y millones de usuarios. Cada uno de ellos tiene un papel que desempeñar en la protección de la comunidad.
Para los desarrolladores, la lección es la importancia de proteger su infraestructura con la misma diligencia que su código. Para los administradores, la lección es la necesidad de verificar, respaldar y monitorizar. Para la comunidad en general, la lección es que la seguridad es un proceso continuo, no un producto que se instala y se olvida.
El ataque a Admin Menu Editor Pro no será el último. Los ciberdelincuentes seguirán buscando los eslabones más débiles de la cadena, y los plugins de WordPress seguirán siendo un objetivo atractivo. La única defensa real es la vigilancia constante, la preparación para responder y la asunción de que, en el mundo digital, la confianza sin verificación es una puerta abierta.
Descubre más desde CIBERED
Suscríbete y recibe las últimas entradas en tu correo electrónico.
