Alerta de seguridad en WordPress el backdoor oculto del plugin Quick Page/Post Redirect que aún amenaza a miles de sitios

Un backdoor implantado hace años en el plugin Quick Page/Post Redirect —instalado en decenas de miles de sitios WordPress— convierte una utilidad aparentemente inocua en una puerta de entrada para inyección de código arbitrario y operaciones de spam SEO. El investigador Austin Ginder, fundador del hosting Anchor, detectó la campaña tras varias alertas en su plataforma y documentó cómo versiones oficiales antiguas del plugin contenían un mecanismo oculto de autoactualización que consultaba un servidor externo, permitiendo reemplazar o inyectar código fuera del control del repositorio oficial.

La amenaza combina dos vectores peligrosos: una actualización "silente" desde un servidor ajeno a WordPress.org y un backdoor que se activa sólo para usuarios desconectados, lo que dificulta su detección por administradores. Según el análisis, las versiones 5.2.1 y 5.2.2 incluían la lógica maliciosa que apuntaba a anadnet[.]com; en marzo de 2021 se sirvió desde esa infraestructura una build 5.2.3 manipulada con un hash distinto al de la misma versión en WordPress.org, y esa build añadió código hookeado a the_content para inyectar payloads orientados a SEO spam.

El riesgo real no es sólo el spam visible: el mecanismo de autoactualización remota permitía ejecutar código arbitrario bajo demanda. Aunque hoy ese subdominio de control no esté resolviendo para todas las instalaciones, esa "puerta" sigue presente en los sitios afectados y puede reactivarse si el actor detrás del dominio la vuelve a habilitar o si la infraestructura cambia de manos. WordPress.org ha retirado temporalmente el plugin del directorio para su revisión, pero mientras haya instalaciones con la actualización apuntando al servidor externo el riesgo permanece.

Si administras un WordPress, la primera medida inmediata es comprobar si tienes instalado Quick Page/Post Redirect y qué versión corre. Si tu instalación está en las versiones comprometidas (5.2.1 o 5.2.2) o en una copia que pudiera haberse actualizado desde ese servidor externo, desinstala el plugin y no confíes en copias locales anteriores sin verificarlas. Reemplazarlo por una versión limpia directamente desde WordPress.org cuando esté publicada (se apuntó a la 5.2.4 como arreglo) es la acción recomendada, pero no la única: la presencia de un auto-update malicioso requiere una limpieza completa y verificación de integridad del sitio.

Además de desinstalar y reinstalar desde una fuente verificada, es imprescindible auditar archivos del sitio en busca de puertas traseras. Revisa archivos modificados recientemente, compara hashes con el repositorio oficial cuando sea posible, busca llamadas salientes hacia anadnet o subdominios relacionados en el código y en los logs HTTP, y elimina cualquier archivo o crontab sospechoso. Rota credenciales administrativas, cambia claves API que hubieran podido almacenarse en el sitio y revisa usuarios administrativos para detectar cuentas no autorizadas.

No confíes únicamente en la desaparición del C2: toma medidas defensivas a nivel de red y hosting bloqueando dominios y subdominios maliciosos (por ejemplo en el firewall o hosts del servidor) y activa un WAF o reglas de bloqueo en tu proveedor. Ejecuta escaneos con herramientas especializadas para WordPress y considera pedir a tu hosting un análisis forense si detectas signos de compromiso. Para comenzar con escaneos y limpieza puedes consultar recursos públicos de proveedores de seguridad especializados en WordPress, como Wordfence https://www.wordfence.com/ o informes y guía del propio descubridor en Anchor https://anchor.host/the-plugin-author-was-the-supply-chain-attacker/.

Este incidente subraya una lección mayor sobre la cadena de suministro de plugins: la confianza en el repositorio oficial no elimina el riesgo de modificaciones ocultas si existe un mecanismo de actualización fuera del ecosistema controlado. Los mantenedores de plugins deben evitar cualquier auto-updater que dependa de servidores externos no verificados y los equipos de revisión necesitan herramientas y procesos que detecten manifiestos de actualización remotos y diferencias de hash entre builds idénticas.

Para desarrolladores y administradores avanzados, es recomendable instrumentar una política de control de integridad (file integrity monitoring), bloquear funciones PHP peligrosas cuando no sean necesarias, y auditar dependencias de terceros de forma periódica. Para responsables de negocios y editores, la sugerencia es priorizar plugins mantenidos activamente con buena reputación, revisar historial de cambios y, en entornos críticos, evaluar el uso de repositorios internos o soluciones de pago con garantías comerciales y soporte técnico.

La vulnerabilidad en Quick Page/Post Redirect es un recordatorio de que un plugin pequeño puede convertirse en un multiplicador de riesgo a gran escala. Actúa rápido: identifica instalaciones afectadas, realiza una limpieza exhaustiva o restaura desde copias limpias, bloquea la infraestructura maliciosa y fortalece controles para evitar que un incidente parecido vuelva a ocurrir. Para más contexto sobre cómo manejar compromisos de plugins y medidas de respuesta, la página oficial de plugins de WordPress puede servir como punto de partida: https://wordpress.org/plugins/.