Backdoor en plugin WordPress activo 5 años: 70K sitios

Un backdoor dormante en el plugin Quick Page/Post Redirect estuvo activo durante cinco años antes de ser detectado. Según BleepingComputer, las versiones 5.2.1 y 5.2.2 del plugin fueron comprometidas alrededor de 2020-2021, afectando más de 70.000 instalaciones activas. WordPress.org cerró el plugin el 14 de abril de 2026 tras la denuncia del investigador Austin Ginder.

WordPress es un sistema de gestión de contenidos (CMS) de código abierto desarrollado por la Fundación WordPress, diseñado para crear y gestionar sitios web, blogs y tiendas en línea.

El Incidente: Backdoor en Quick Page/Post Redirect

Quick Page/Post Redirect Plugin es una herramienta de WordPress que permite crear redireccionamientos 301/302 desde el panel de administración sin tocar código ni archivos de servidor. Con más de 70.000 instalaciones activas al momento del cierre, era un plugin ampliamente utilizado para gestionar URLs cambiadas, migraciones de contenido y estructuras de sitios reestructurados.

El problema: alguien modificó las versiones 5.2.1 y 5.2.2 para incluir código malicioso. La versión comprometida que actuó como vector principal fue la 5.2.3, lanzada en marzo de 2021 desde el servidor anadnet.com/updates/ en vez del repositorio oficial de WordPress.org. Esa actualización falsa llegó a los sitios a través del mecanismo de actualización automática de WordPress, sin requerir ninguna acción del administrador.

El descubrimiento llegó en abril de 2026 cuando Austin Ginder, de Anchor Hosting, vio 12 sitios de su flota disparar alertas de seguridad de forma simultánea. Todos tenían el mismo plugin. Según el análisis de GBHackers, el backdoor había estado durmiendo durante años antes de activarse.

Cómo Funcionaba: Dos Mecanismos de Ataque

El malware tenía dos componentes independientes, y eso es lo que lo hace interesante desde el punto de vista técnico.

Componente pasivo: spam SEO invisible. El código inyectaba keywords de gambling, criptomonedas y farmacéuticas directamente en el HTML del sitio, pero solo cuando el visitante era Googlebot. Para cualquier humano que cargara la página, no había nada raro. El admin podía revisar el sitio decenas de veces y no ver nada. Solo con un simulador de Googlebot o revisando el HTML raw desde un crawler se podía detectar el contenido inyectado.

Componente activo: ejecución remota de código. Acá está el problema más grave. El plugin usaba la Plugin Update Checker Library pero la había configurado para apuntar a anadnet.com/updates/ en vez del repositorio oficial. En cada ejecución del cron de WordPress, el plugin consultaba ese servidor externo. Si el servidor respondía con una «actualización», el código se ejecutaba con permisos de autor de plugin, sin revisión ni aviso. El servidor C2 podía cambiar el payload en cualquier momento sin que nada en el WordPress del sitio lo registrara. Cubrimos ese tema en detalle en nuestra guía sobre reforzar la protección de tu sitio.

¿Alguien verificó cuántos sitios recibieron payloads activos desde ese servidor? Todavía no hay un número confirmado.

Impacto Real: 70.000 Sitios con la Guardia Baja

70.000 instalaciones activas. Eso no es un número menor. Y la distribución fue a través del mecanismo de actualización automática de WordPress, que la mayoría de los admins tienen activado precisamente para no tener que pensar en actualizaciones manuales.

La ironía es que actualizar automáticamente los plugins es una buena práctica de seguridad. Salvo cuando el mecanismo de actualización en sí está comprometido (spoiler: en este caso, exactamente eso pasó). Ponele que tenías el plugin en 50 sitios y todos con autoupdate activado. Los 50 recibieron la versión maliciosa sin que tocaras nada.

Lo que complica el análisis forense es que el backdoor llevaba años en producción. Cualquier sitio infectado pudo haber ejecutado código arbitrario en múltiples ocasiones sin dejar rastros obvios en los logs de WordPress estándar.

¿Está Mi Sitio Infectado? Señales Concretas de Compromiso

Si instalaste Quick Page/Post Redirect en cualquier momento entre 2021 y abril de 2026, asume que el sitio fue comprometido hasta que puedas demostrarlo de otra manera. Las señales a buscar: Para más detalles técnicos, consultá nuestra guía: Auditar la seguridad de tus plugins.

• Cambios en redirecciones: URLs que ahora apuntan a destinos que vos no configuraste, especialmente domains de gambling o farma.
• Spam en HTML invisible: Abrí el HTML fuente de tu homepage y buscá keywords como «casino», «bitcoin», «viagra», «pharmacy». Si aparecen en el código pero no en la pantalla, estás infectado.
• Tráfico anómalo en logs: Picos de visitas de bots no identificados, especialmente con user-agents genéricos.
• Archivos modificados recientemente: Revisá si los archivos del plugin tienen fechas de modificación que no coinciden con la instalación original.
• Cuentas admin nuevas: Un backdoor activo puede haber creado usuarios con privilegios que vos no generaste.

La herramienta más directa para esto es Wordfence Security: su escaneo compara los archivos de los plugins contra las versiones oficiales del repositorio y marca cualquier diferencia. Si el plugin ya fue removido de WordPress.org, Wordfence igual puede detectar archivos sospechosos si están en el directorio de plugins.

Pasos Concretos para Eliminar la Infección

No alcanza con desactivar el plugin. La desactivación deja los archivos en el servidor. Seguí este orden:

• 1. Desinstalar completamente desde Plugins > Plugin instalados > Eliminar. Verificá que la carpeta wp-content/plugins/quick-pagepost-redirect-plugin/ ya no exista vía FTP o panel de hosting.
• 2. Correr escaneo completo con Wordfence o Sucuri Security. Buscá archivos modificados, código ofuscado (base64_decode, eval) y conexiones a dominios externos no autorizados.
• 3. Auditar usuarios admin: Usuarios > Todos los usuarios. Filtrá por rol «Administrador». Cualquier cuenta que no reconozcas, eliminala y cambiá las credenciales de todas las cuentas legítimas.
• 4. Revisar archivos modificados en los últimos 6 meses: Via FTP, ordenar por fecha de modificación. Si hay archivos PHP en wp-content que cambiaron en fechas que no te explican, son sospechosos.
• 5. Cambiar todas las credenciales: Contraseña de WP, FTP, base de datos, hosting. Si el backdoor activo estuvo funcionando, tiene que asumir que cualquiera de estas pudo haber sido exfiltrada.
• 6. Reemplazar los redireccionamientos con una alternativa: el plugin nativo de redireccionamientos de WordPress (desde versión 6.x incluye funcionalidad básica), o configurar redirects directamente en el .htaccess o nginx.conf.

Si tu sitio está en un hosting con panel cPanel o Plesk, algunas versiones incluyen un escáner de malware integrado. No reemplaza a Wordfence, pero sirve como capa adicional.

Herramientas de Auditoría para Detectar Backdoors en Plugins

Para verificación manual: comparar los hashes MD5 de los archivos del plugin con los de la versión limpia descargada directamente de WordPress.org. Cualquier diferencia en un archivo PHP es una señal de alerta que hay que investigar antes de descartar.

Cadena de Suministro de Plugins: Un Problema Estructural de 2026

Este caso no es un accidente aislado. Según WPPoland, en abril de 2026 ya van cuatro backdoors inyectados a plugins de WordPress en un solo mes. El patrón se repite: alguien compra plugins con base instalada en Flippa u otras plataformas de compraventa, inyecta el backdoor, espera meses para no levantar sospechas, y activa el payload cuando considera que el volumen de sitios infectados es suficiente.

El problema estructural es que WordPress.org confía implícitamente en los autores una vez que el plugin está publicado. No hay code-signing obligatorio. No hay 2FA obligatorio para cuentas de desarrollador. No hay revisión automática de cambios de propiedad cuando un plugin se transfiere a un nuevo dueño. El proceso de revisión inicial puede ser riguroso; después de la publicación, el author tiene la llave del repositorio. Sobre eso hablamos en elegir plugins verificados y confiables.

Otros incidentes confirmados en 2026: el caso «Essential Plugin» donde alguien compró 31 plugins y les inyectó backdoors en bloque, y una vulnerabilidad de SQL injection en el plugin Ally que afectó 400.000 sitios. La cadena de suministro es el vector de ataque del momento contra WordPress.

Lo que no queda claro: si WordPress.org va a implementar revisión de transferencias de propiedad como medida preventiva. El equipo de seguridad no confirmó cambios al proceso hasta la fecha de publicación de este artículo.

Mejores Prácticas para No Volver a Pasar por Esto

Algunos ajustes que reducen la superficie de ataque sin agregar demasiada fricción al workflow:

• Auditá el directorio de plugins cada trimestre: Plugins sin actualización en más de 6 meses son candidatos a reemplazar. Un plugin abandonado no recibe parches de seguridad.
• Revisá changelogs antes de actualizar: No automáticamente para todos. Para plugins críticos (SEO, seguridad, ecommerce), leé qué cambió antes de aplicar la actualización.
• Principio de mínimo plugin: Cada plugin que instalás es una superficie de ataque. Si una funcionalidad la podés hacer con código custom en un plugin hijo, hacelo ahí en vez de instalar un plugin de terceros.
• Para redireccionamientos específicamente: WordPress desde la versión 6.x incluye funcionalidad básica de redirects. Para casos más complejos, configurar directamente en .htaccess (Apache) o en los bloques de configuración de nginx es más seguro que depender de un plugin.
• Backups antes de actualizar: Si el backup existe, podés revertir. Si no existe, no podés. Con donweb.com los planes de hosting incluyen backups automáticos, pero igual tené tu propio backup local antes de actualizaciones masivas.
• WAF a nivel de servidor: Un firewall de aplicaciones web puede bloquear requests maliciosas antes de que lleguen a WordPress, incluso si el plugin está comprometido.

Errores Comunes Ante Este Tipo de Incidente

Error 1: Solo desactivar el plugin en vez de eliminarlo. Desactivar deja todos los archivos en el servidor. El código malicioso puede seguir ejecutándose si hay hooks registrados, o simplemente quedar disponible para reactivación. La única acción válida es eliminar completamente.

Error 2: Escanear con un solo plugin de seguridad y asumir que eso alcanza. Wordfence y Sucuri usan bases de datos de malware diferentes. Un scan con uno puede pasar por alto algo que el otro detecta. Para un incidente confirmado, corré los dos. Esto se conecta con lo que analizamos en implementar un firewall WAF robusto.

Error 3: Cambiar la contraseña de WordPress pero no la de la base de datos ni FTP. Si el backdoor activo estuvo ejecutando código arbitrario en tu servidor, podría haber exfiltrado credenciales de wp-config.php, que incluye usuario y contraseña de MySQL. Cambiar solo la contraseña del panel WP no alcanza.

Error 4: No revisar logs de Google Search Console. El spam SEO inyectado por el backdoor puede haber generado penalizaciones de Google. Entrá a GSC y revisá si hay páginas indexadas con contenido que no generaste, o si recibiste mensajes de «contenido hackeado».

Una situación muy parecida ocurrió con The Quick Page/Post Redirect plugin had a backdoor added fiv, donde contamos toda la historia.

Preguntas Frecuentes

¿Qué es el plugin Quick Page/Post Redirect y por qué fue comprometido?

Quick Page/Post Redirect Plugin es una herramienta de WordPress que gestiona redireccionamientos 301 y 302 desde el panel de administración. Tenía más de 70.000 instalaciones activas cuando fue cerrado por WordPress.org el 14 de abril de 2026. Fue comprometido porque un actor malicioso modificó las versiones 5.2.1 y 5.2.2 para incluir código que ejecutaba payloads desde un servidor externo (anadnet.com) y spam SEO invisible dirigido a Googlebot.

¿Cómo sé si mi sitio WordPress está infectado por este backdoor?

Las señales más claras son: redireccionamientos que apuntan a sitios de gambling o farma que vos no configuraste, keywords de spam en el HTML fuente de tu sitio (visible solo en el código, no en pantalla), y cuentas de administrador que no reconocés. Para verificación técnica, corré un escaneo con Wordfence Security y compará los hashes de los archivos del plugin con la versión oficial.

¿Qué debo hacer si tenía este plugin instalado?

Desinstalar completamente el plugin (no solo desactivarlo), correr un escaneo completo de malware con Wordfence o Sucuri, auditar los usuarios con rol administrador, revisar archivos PHP modificados en los últimos 6 meses, y cambiar todas las credenciales: WordPress, FTP y base de datos. Si el backdoor activo estuvo operando, las credenciales almacenadas en wp-config.php pueden estar comprometidas.

¿Cómo detectar malware inyectado en plugins de WordPress?

Wordfence Security compara los archivos instalados contra las versiones del repositorio oficial y marca cualquier diferencia. Sucuri Security monitorea la integridad de archivos y puede detectar cambios no autorizados. Para verificación manual, comparar hashes MD5 de los archivos PHP del plugin contra los de una descarga limpia desde WordPress.org. También vale revisar el HTML fuente del sitio buscando código ofuscado o base64.

¿Qué vulnerabilidades tienen los plugins de redireccionamiento?

Los plugins de redireccionamiento son blancos atractivos porque tienen acceso a la lógica de navegación del sitio y suelen instalarse en sitios de tamaño mediano y grande con mucho tráfico. Las vulnerabilidades más comunes son: inyección de URLs maliciosas, acceso no autorizado a la tabla de redirects via REST API, y en este caso, el mecanismo de actualización automática apuntando a un servidor externo controlado por el atacante. Para casos simples, una alternativa más segura es configurar redirects directamente en .htaccess.

Conclusión

Este incidente con el backdoor en Quick Page/Post Redirect confirma algo que en el ecosistema WordPress se sabe pero muchas veces se ignora: la seguridad de un sitio depende de la integridad de cada autor de plugin que alguna vez tuvo acceso al repositorio, no solo de la revisión inicial de WordPress.org. El sistema confía en los autores después de la publicación, y esa confianza puede ser comprada en Flippa por quien tenga el presupuesto.

Si tenés este plugin instalado, actuá ahora. Si no lo tenés, igual es un buen momento para hacer una auditoría de los plugins activos: cuáles tienen actualizaciones recientes, quién los mantiene, y si realmente los necesitás o si la funcionalidad se puede cubrir con menos dependencias externas. Cada plugin que eliminás es una superficie de ataque que desaparece.

Fuentes

• BleepingComputer — Popular WordPress redirect plugin hid dormant backdoor for years
• Wordfence Threat Intelligence — Quick Page/Post Redirect Plugin vulnerability
• GBHackers — Backdoored WordPress plugin abuses remote update checker
• WPPoland — WordPress plugin supply chain 2026: cuatro backdoors en un mes
• CyberSecurityNews — WordPress plugin hacked