El plugin Quick Page/Post Redirect, instalado en más de 70.000 sitios WordPress, tenía un backdoor oculto desde 2021: las versiones 5.2.1 y 5.2.2 incluían un mecanismo de auto-actualización que apuntaba a un servidor externo, permitiendo inyectar código arbitrario sin pasar por los controles de WordPress.org. Lo descubrió Austin Ginder, fundador de Anchor, después de que 12 sitios de su flota dispararon alertas de seguridad en abril de 2026.
En 30 segundos
- El plugin Quick Page/Post Redirect (70.000+ instalaciones) tenía un backdoor pasivo activo desde marzo de 2021, introducido vía servidor externo en la versión 5.2.3.
- Las versiones 5.2.1 y 5.2.2, lanzadas entre 2020 y 2021, incluían un auto-actualizador oculto que apuntaba a un dominio de terceros fuera del control de WordPress.org.
- WordPress.org removió el plugin temporalmente el 29 de abril de 2026, pendiente de revisión.
- No está confirmado si fue el propio autor del plugin quien introdujo el backdoor o si fue comprometido por un tercero.
- Remover el plugin no alcanza: el backdoor puede haber modificado wp-config.php y otros archivos del sitio.
WordPress es un sistema de gestión de contenidos (CMS) de código abierto desarrollado por la Fundación WordPress para crear y administrar sitios web. Fue lanzado en 2003 y, según datos de 2026, alimenta más del 40% de los sitios web en todo el mundo.
El Descubrimiento: Quick Page/Post Redirect y el Backdoor de 5 Años
Quick Page/Post Redirect es un plugin utilitario básico: te permite crear redirecciones para posts, páginas y URLs personalizadas sin tocar código. El tipo de herramienta que instalás una vez, configurás, y te olvidás. Y ahí está exactamente el problema.
Austin Ginder, fundador del proveedor de hosting WordPress Anchor, encontró el backdoor de la manera más incómoda posible: 12 sitios de su flota dispararon alertas de seguridad al mismo tiempo. Empezó a investigar y lo que encontró fue un mecanismo malicioso que había estado dormido en producción durante años, esperando instrucciones.
El plugin tenía más de 70.000 instalaciones activas al momento del descubrimiento. Para ponerlo en contexto: eso significa 70.000 sitios potencialmente expuestos a inyección de código arbitrario, sin que nadie se enterara de nada.
Cómo Funcionaba el Mecanismo Malicioso
La historia técnica arranca en 2020-2021, con las versiones 5.2.1 y 5.2.2 del plugin. Según el análisis publicado por BleepingComputer el 29 de abril de 2026, esas versiones incluían un mecanismo de auto-actualización oculto que apuntaba a un dominio de terceros, completamente por fuera del control de WordPress.org.
En febrero de 2021, ese auto-actualizador fue removido de las versiones posteriores del plugin que se subieron al repositorio oficial. Pero antes de que los revisores de código pudieran analizar qué había pasado, en marzo de 2021 los sitios que todavía corrían las versiones 5.2.1 y 5.2.2 recibieron silenciosamente una build alterada de la versión 5.2.3 desde ese servidor externo. Esa build introdujo el backdoor pasivo.
El detalle que cierra el círculo: el build distribuido desde el servidor externo tenía un hash diferente al del mismo número de versión en WordPress.org. Silencioso, dormido, con un hash distinto que nadie estaba mirando. (Si eso no te parece un ataque bien pensado, no sé qué te parecería.)
Impacto Real en los Sitios Infectados
Un backdoor pasivo no hace nada visible por defecto. Espera. Escucha. Recibe instrucciones cuando el atacante decide activarlo.
En el caso de Quick Page/Post Redirect, el vector de impacto incluía inyección de código arbitrario en el sitio, modificación de wp-config.php, comunicación con servidores de comando y control (C2), y potencial para spam SEO o redirecciones maliciosas que afecten el posicionamiento del sitio. Lo que confirma el análisis de Wordfence es que el atacante usó Ethereum smart contracts como infraestructura C2 resiliente, un método que hace mucho más difícil bloquear las comunicaciones porque no depende de un dominio fijo que se pueda dar de baja.
¿Y qué pasó con los 70.000 sitios? Todavía no hay una cifra confirmada de cuántos fueron realmente comprometidos. Que el backdoor estuviera presente no implica necesariamente que se haya activado en todos los casos.
Historial de Vulnerabilidades del Plugin: Esto Venía de Antes
El backdoor no apareció de la nada en un plugin impecable. Quick Page/Post Redirect tenía un historial documentado de problemas de seguridad antes de este incidente.
| Vulnerabilidad | Versiones afectadas | Tipo |
|---|---|---|
| CSRF (Cross-Site Request Forgery) | Anteriores a 5.2.4 | Alta |
| XSS (Cross-Site Scripting) | Anteriores a 5.2.4 | Media/Alta |
| Open Redirect | 5.0.3 – 5.2.3 | Media |
| Security Bypass | 5.0.3 – 5.2.3 | Media |
| Privilege Escalation | Versiones tempranas | Alta |
| Backdoor pasivo (C2) | 5.2.1 – 5.2.3 (build externa) | Crítica |
Documentado en WPScan, Patchstack y Acunetix, este plugin tenía problemas de CSRF y XSS en versiones anteriores a 5.2.4 que nunca generaron el revuelo que merecían. El backdoor es la capa final de una historia que ya venía floja.
La Decisión de WordPress.org: Remoción Temporal
El 29 de abril de 2026, WordPress.org bajó temporalmente el plugin del directorio oficial, pendiente de una revisión de seguridad. La incertidumbre que queda sobre la mesa es importante: no se sabe si el autor original del plugin introdujo el backdoor intencionalmente o si su cuenta o su servidor de actualizaciones fue comprometido por un tercero.
Eso importa porque cambia el análisis de responsabilidad, pero no cambia lo que tenés que hacer si usás el plugin: revisá tu sitio de todas formas.
Contexto Más Amplio: El Ataque de Cadena de Suministro de 30 Plugins en 2026
Este incidente no existe en el vacío. En abril de 2026, TechCrunch reportó que un actor conocido como «Kris» adquirió 30 plugins WordPress del portafolio «Essential Plugin» y plantó backdoors en todos ellos. El código malicioso fue agregado en agosto de 2025 y permaneció completamente dormido hasta el 5 de abril de 2026, cuando se activó de forma coordinada.
Subís el plugin, lo instalás porque tiene miles de instalaciones y buenas reseñas, lo dejás activo durante meses, y en algún momento entre que se activó el payload y que vos lo revisaste, alguien ya tuvo acceso a tu sitio. Ese es el modelo de ataque de cadena de suministro aplicado a WordPress: paciencia, escala, y el factor «nadie mira los plugins viejos».
Este caso de Quick Page/Post Redirect tiene similitudes estructurales: código malicioso que lleva meses o años presente, activación diferida, y una base de usuarios que confía en que WordPress.org ya hizo el control de calidad. (Spoiler: no pueden revisar todo.)
Qué Está Confirmado y Qué No
| Estado | Detalle |
|---|---|
| Confirmado | Versiones 5.2.1 y 5.2.2 incluían auto-actualizador externo |
| Confirmado | Build alterada de 5.2.3 distribuida desde servidor externo en marzo 2021 |
| Confirmado | WordPress.org removió el plugin el 29/04/2026 |
| Confirmado | 70.000+ sitios tenían el plugin instalado |
| Confirmado | Uso de Ethereum smart contracts como infraestructura C2 |
| No confirmado | Si el autor del plugin fue responsable o víctima |
| No confirmado | Cantidad exacta de sitios efectivamente comprometidos |
| No confirmado | Si el backdoor fue activado en todos los sitios o selectivamente |
Cómo Detectar y Remover el Backdoor Correctamente
Primero lo primero: desinstalar el plugin no es suficiente. Si el backdoor ya modificó wp-config.php o inyectó código en otros archivos del sitio, esos cambios persisten aunque elimines el plugin.
El proceso correcto es este:
- Escaneá con Wordfence o Sucuri: Ambas tienen firmas para detectar backdoors conocidos. Un escaneo completo de archivos va a detectar modificaciones no autorizadas en el núcleo de WordPress y plugins.
- Revisá wp-config.php manualmente: Abrí el archivo y buscá código que no hayas puesto vos. Cualquier cosa que no sean las constantes de base de datos y los salts de seguridad merece revisión.
- Verificá usuarios administradores: En el panel de WordPress, revisá Usuarios > Todos los usuarios y confirmá que todos los admin son legítimos. Un backdoor típicamente crea un usuario oculto o eleva permisos.
- Comparé hashes de archivos del core: WordPress.org publica los hashes de cada versión. Si un archivo del core de WordPress tiene un hash diferente, fue modificado.
- Revisá logs del servidor: Buscá requests POST inusuales o conexiones a dominios desconocidos en los logs de acceso de los últimos 3-4 años.
Si el sitio es crítico para tu negocio, considerá restaurar desde un backup anterior a marzo de 2021 y volver a configurar desde cero. Tedioso, sí. Pero es lo único que garantiza que no queda rastro.
Los que tienen su WordPress alojado en un proveedor con soporte especializado en seguridad, como donweb.com con su infraestructura de hosting gestionado, pueden solicitar un análisis de archivos al equipo de soporte antes de hacer una limpieza manual.
Errores Comunes al Manejar Este Tipo de Incidente
Error 1: Creer que desinstalar el plugin limpia el sitio. El backdoor ya hizo su trabajo antes de que lo elimines. Los archivos modificados siguen ahí. Tenés que escanear y limpiar el sistema de archivos completo, no solo remover el plugin.
Error 2: Asumir que «yo no tengo nada importante en mi sitio» te protege. Los backdoors en sitios de bajo tráfico se usan frecuentemente para spam SEO, distribución de malware a visitantes, o como nodo de una botnet. No necesitás tener una tienda online para ser un objetivo valioso.
Error 3: Actualizar el plugin a la versión limpia sin limpiar el backdoor previo. Si la versión 5.2.3 instalada en tu sitio vino del servidor externo (no de WordPress.org), actualizar a 5.2.5 o la versión que corresponda no elimina el código ya inyectado. El escaneo va primero, la actualización después.
Preguntas Frecuentes
¿Qué es un backdoor en WordPress y cómo afecta mi sitio?
Un backdoor es código malicioso oculto en un plugin, tema o archivo del core que permite a un atacante ejecutar comandos en tu sitio sin autenticación normal. En el caso de Quick Page/Post Redirect, el backdoor podía recibir instrucciones vía Ethereum smart contracts e inyectar código arbitrario, modificar wp-config.php, o redirigir tráfico sin que el dueño del sitio se enterara.
¿Cómo sé si el plugin Quick Page/Post Redirect está infectado en mi sitio?
Las versiones comprometidas son la 5.2.1, 5.2.2 y la build alterada de la 5.2.3 distribuida desde el servidor externo. Para confirmarlo, compará el hash de los archivos del plugin con los publicados en WordPress.org. Un escaneo con Wordfence también detecta la firma del backdoor. Acá el dato clave: si tenés o tuviste instalada alguna de esas versiones entre 2021 y hoy, asumí que el sitio fue comprometido hasta que un escaneo diga lo contrario.
¿Cuántos sitios WordPress fueron afectados por este backdoor?
El plugin tenía más de 70.000 instalaciones activas al momento del descubrimiento, según el reporte de Austin Ginder publicado el 29 de abril de 2026. No hay una cifra confirmada de cuántos de esos sitios recibieron la build maliciosa del servidor externo, ni cuántos tuvieron el backdoor activado. Los 12 sitios iniciales detectados por Ginder en su flota de Anchor fueron el punto de partida de la investigación.
¿Cómo remover un backdoor de WordPress de forma completa?
El proceso requiere: escanear el sitio completo con Wordfence o Sucuri, revisar manualmente wp-config.php, verificar que no haya usuarios admin no autorizados, y comparar los hashes de los archivos del core con los de WordPress.org. Si encontrás código inyectado, eliminalo y cambiá todas las contraseñas y salts de seguridad. En casos críticos, restaurar desde un backup limpio es la opción más segura.
¿Qué versiones del plugin Quick Page/Post Redirect tienen el backdoor?
Las versiones 5.2.1 y 5.2.2 incluían el auto-actualizador malicioso. La versión 5.2.3 distribuida desde el servidor externo (no la de WordPress.org, con hash diferente) introdujo el backdoor pasivo en marzo de 2021. Las versiones anteriores a 5.2.4 también tenían vulnerabilidades CSRF y XSS documentadas por separado. WordPress.org removió el plugin completo el 29 de abril de 2026 hasta nueva revisión.
Conclusión
Este incidente confirma algo que los que trabajamos en seguridad WordPress repetimos hace años: los plugins «de utilidad» que nadie revisa son un vector de ataque subestimado. Quick Page/Post Redirect no es un plugin glamoroso de seguridad ni un pagebuilder con millones de instalaciones. Es exactamente el tipo de plugin que instalás, configurás y olvidás, y que por eso mismo nadie actualiza ni monitorea.
El backdoor estuvo dormido desde 2021 hasta 2026. Cinco años. En ese tiempo, pasó por revisiones automáticas, actualizaciones de WordPress, auditorías de seguridad de terceros, y nadie lo levantó porque el hash estaba en el build externo, no en el oficial.
Si tenés o tuviste este plugin instalado, el paso uno es escanear ahora. El paso dos es revisar wp-config.php y los logs. El paso tres es asumir que si el escáner no encuentra nada, igual vale la pena cambiar credenciales. En seguridad, la ausencia de evidencia no es evidencia de ausencia.
Fuentes
- BleepingComputer – Popular WordPress redirect plugin hid dormant backdoor for years (29/04/2026)
- Anchor – Someone bought 30 WordPress plugins and planted a backdoor in all of them
- Wordfence Threat Intelligence – Quick Page/Post Redirect Plugin vulnerabilities
- TechCrunch – Someone planted backdoors in dozens of WordPress plugins (14/04/2026)
- WPScan – Quick Page/Post Redirect Plugin vulnerability database