Plugin WordPress con backdoor dormante 5 años

El plugin Quick Page/Post Redirect, con más de 70.000 instalaciones activas, fue comprometido en 2020 cuando nuevos propietarios inyectaron un backdoor en las versiones 5.2.1 y 5.2.2. El código malicioso permaneció activo durante casi cinco años, convirtiendo miles de sitios en servidores de spam SEO sin que sus administradores lo supieran.

WordPress es un sistema de gestión de contenidos (CMS) de código abierto desarrollado y mantenido por la Fundación WordPress, que permite crear y administrar sitios web, blogs y tiendas en línea sin requerir conocimientos avanzados de programación.

El incidente: cómo un plugin WordPress comprometido con backdoor durmió cinco años

Quick Page/Post Redirect Plugin es (o era) una herramienta para gestionar redirecciones en WordPress, con más de 70.000 instalaciones activas en el repositorio oficial. En 2020, el plugin cambió de propietario a través del proceso habitual de transferencia de WordPress.org. Lo que no fue habitual es lo que vino después.

Los nuevos dueños publicaron versiones 5.2.1 y 5.2.2 que incluían un mecanismo de auto-actualización apuntando a sus propios servidores, y código de inyección de contenido que operaba en segundo plano. Según el análisis publicado en abril de 2026 por Anchor Host, el descubrimiento llegó de forma casi accidental: una alerta de seguridad rutinaria sobre una versión específica del plugin en una flota de doce sitios.

El investigador corrió WP-CLI y obtuvo que todos reportaban versión 5.2.3. El problema: la versión 5.2.3 instalada no era la versión 5.2.3 de wordpress.org. Mismo número de versión. Archivo diferente. Hash diferente.

Cómo funcionaba el backdoor pasivo

Ponele que sos administrador de un sitio WordPress. Entrás, revisás el plugin, todo parece normal. El dashboard no muestra errores. Los visitantes logueados tampoco ven nada raro. Y mientras tanto, cada visitante no logueado que carga una página de tu sitio está viendo contenido que no pusiste vos.

Así de simple y así de invisible era el mecanismo. El backdoor agregaba una función hooked en the_content con prioridad -1 (antes que cualquier otro procesamiento del contenido). La función se llamaba filter_the_content_in_the_main_loop y operaba bajo condiciones muy específicas: solo en páginas individuales (is_single(), is_singular() o is_page()), solo cuando el visitante no estaba logueado, y solo en la query principal.

Cuando se cumplían esas condiciones, el plugin abría una conexión HTTP con timeout de 3 segundos hacia https://w.anadnet.com/bro/3/ seguido del nombre del servidor, y lo que devolvía ese endpoint se anteponía al contenido del post. El propósito era insertar links y texto optimizado para posicionamiento en buscadores, lo que en el negocio del spam SEO se llama «alquilar» acceso a sitios con autoridad.

¿Y por qué pasó desapercibido tanto tiempo? Exacto: porque cualquier admin que revisaba el sitio estaba logueado. El código tenía esa protección deliberada.

El método de detección: verificación de hash

El dato central de este caso es el hash. El archivo comprometido producía el MD5 ad717da18cf8a2b69899c0d7dafee05a. Cuando el investigador descargó todas las versiones disponibles del plugin en el SVN oficial de wordpress.org (desde 5.1.5 hasta 5.2.4) y corrió el mismo hash en cada una, ninguna coincidió.

Eso es lo que confirmó la manipulación: no una diferencia de comportamiento, sino una diferencia criptográfica entre lo instalado y lo publicado oficialmente.

Para verificar esto en tu instalación, el proceso es directo con WP-CLI:

• Identificar qué versión reporta WP-CLI para el plugin: wp plugin list
• Descargar esa versión desde el SVN de wordpress.org directamente
• Comparar el hash MD5 del archivo principal del plugin instalado contra la versión oficial descargada
• Si los hashes no coinciden, el archivo fue modificado

Wordfence también tiene detección de integridad de archivos en su scanner, aunque en este caso específico la detección dependía de tener firmas actualizadas para esa variante del backdoor.

Impacto real: 70.000 sitios como plataforma de spam SEO

El alcance es significativo. Con 70.000 instalaciones activas en el pico del plugin, y considerando que las versiones comprometidas circularon entre 2020 y al menos 2026, estamos hablando de un período de explotación de entre cuatro y cinco años. Durante ese tiempo, los operadores de anadnet.com tenían acceso garantizado para inyectar lo que quisieran en el contenido de esos sitios.

El modelo de negocio detrás es conocido en el ecosistema de blackhat SEO: se compran plugins con base de instalaciones grandes, se agrega código de inyección, y se «alquila» ese acceso a clientes que quieren posicionar páginas usando la autoridad de dominio de otros. Los sitios afectados no solo veían deterioro en sus rankings (por el contenido spam que Google eventualmente detecta), sino que también servían como vector para los clientes de ese esquema.

La gravedad extra viene de que el mecanismo era adaptable: el endpoint w.anadnet.com/bro/3/ podía devolver cualquier cosa. Hoy spam SEO, mañana links a malware.

Qué está confirmado y qué no

Cómo detectar si tu sitio WordPress está comprometido

Si tenés Quick Page/Post Redirect instalado, o lo tuviste instalado en algún momento entre 2020 y 2026, estos son los pasos concretos:

Verificación de versión del plugin

Comparar la versión instalada contra la que figura en wordpress.org no alcanza: el número de versión puede coincidir con el oficial pero el archivo ser diferente. El chequeo que importa es el hash. Descargá la versión correspondiente desde plugins.svn.wordpress.org/quick-pagepost-redirect-plugin/tags/ y comparás archivo por archivo.

Búsqueda de funciones sospechosas en el código

Si tenés acceso SSH, buscá la función específica en los archivos del plugin:

• grep -r "filter_the_content_in_the_main_loop" wp-content/plugins/
• grep -r "anadnet.com" wp-content/
• grep -r "w.anadnet" wp-content/

Si alguno de esos comandos devuelve resultados, tenés el backdoor activo.

Revisión de comportamiento en modo no logueado

Cerrá sesión en WordPress (o usá una ventana de incógnito) y navegá las páginas de tu sitio. Si el source HTML contiene links o texto que no pusiste vos en el contenido del post, es señal de inyección activa. También podés revisar los logs del servidor buscando requests salientes hacia dominios de terceros generados por PHP.

Guía de limpieza y remediación

La remediación es directa, aunque necesita atención en cada paso.

Primero: desactivar y eliminar completamente el plugin. No actualizar, eliminar. Si wordpress.org tiene una versión limpia del plugin disponible (lo cual depende de si el plugin fue removido del repositorio o no), podés reinstalarlo desde cero. Al momento del descubrimiento en 2026, Wordfence tenía documentado el plugin en su base de inteligencia de amenazas.

Segundo: verificar que no quedó código residual. El backdoor podría haber sido usado para depositar archivos adicionales o modificar wp-config.php. Revisá esos archivos manualmente, comparando wp-config.php contra el template estándar de WordPress.

Tercero: si tu sitio estuvo expuesto durante meses o años, revisá si Google indexó contenido spam en tus páginas. Podés usar Search Console para ver qué URLs están indexadas y si hay contenido que no reconocés. También es momento de solicitar una re-indexación después de limpiar.

Cuarto: si tu hosting es compartido y usás una plataforma como donweb.com, verificá si tienen algún escáner de malware a nivel de servidor que pueda confirmar que los archivos maliciosos fueron eliminados.

Lecciones: por qué los plugins siguen siendo vulnerables

Este caso expone una grieta estructural en el ecosistema de WordPress que no tiene solución fácil: el proceso de transferencia de propiedad de plugins no tiene revisión de seguridad obligatoria. Cuando un desarrollador transfiere un plugin a nuevos dueños, wordpress.org confía en que los nuevos propietarios van a mantener los estándares. No hay auditoría automática del código que publican.

El problema se amplifica porque según reportes de Patchstack, este esquema no se limitó a Quick Page/Post Redirect: más de 30 plugins asociados a un grupo relacionado con EssentialPlugin presentaron comportamientos similares. Misma táctica, distinta cara.

La firma de código obligatoria (que WordPress no implementa en su ecosistema de plugins) resolvería esto parcialmente: cada release estaría firmado por el desarrollador y cualquier modificación sería detectable. Pero hoy no existe. Lo que existe es la verificación de hash manual, que casi nadie hace.

El mecanismo de auto-update sin validación agrava todo. Si el plugin puede actualizar silenciosamente desde cualquier endpoint que el desarrollador defina, los nuevos dueños pueden entregar código arbitrario a todas las instalaciones existentes sin que aparezca como «actualización» en el dashboard de WordPress.

Errores comunes al manejar este tipo de incidente

Confiar en que el número de versión valida el archivo

El error central de este caso es asumir que «versión 5.2.3» instalada es lo mismo que «versión 5.2.3» en wordpress.org. No lo es. El número de versión lo define el código del plugin. Nada impide que un archivo comprometido reporte el mismo número que la versión oficial. Solo el hash del archivo es un indicador confiable.

Revisar el sitio solo desde una sesión de administrador

Si revisás tu sitio logueado, no ves lo que ve el 99% de tus visitantes. Este backdoor específicamente excluía a usuarios logueados. Cualquier revisión de seguridad tiene que incluir una revisión en modo no autenticado: ventana de incógnito, o directamente curl desde la terminal.

Actualizar el plugin en vez de eliminarlo y reinstalar desde cero

Si el mecanismo de auto-update del plugin estaba comprometido, actualizar a través de ese mismo canal no garantiza nada. La única actualización confiable es descargar directamente desde wordpress.org, verificar el hash contra el SVN oficial, y reinstalar manualmente.

Asumir que Wordfence o el escáner de turno lo hubieran detectado antes

Los escáneres de malware buscan firmas conocidas. Un backdoor diseñado para pasar desapercibido, que usa conexiones HTTP con timeout corto y que no genera errores visibles, puede circular durante años antes de que algún investigador lo documente y los escáneres actualicen sus firmas. En este caso, así pasó.

Preguntas Frecuentes

¿Qué pasó exactamente con el plugin Quick Page/Post Redirect?

En 2020 el plugin cambió de propietario a través del sistema de transferencia de WordPress.org. Los nuevos dueños publicaron versiones 5.2.1 y 5.2.2 con código malicioso que conectaba con servidores externos para inyectar contenido spam en páginas visitadas por usuarios no logueados. El backdoor operó durante al menos cinco años antes de ser documentado públicamente en abril de 2026.

¿Cómo sé si mi sitio WordPress fue infectado con el backdoor de anadnet?

Buscá referencias a anadnet.com o la función filter_the_content_in_the_main_loop en los archivos del plugin usando grep desde SSH. También podés comparar el hash MD5 del archivo principal del plugin instalado contra la versión equivalente descargada directamente del SVN de wordpress.org: si los hashes no coinciden, el archivo fue modificado.

¿Cómo detectar archivos de plugin manipulados en WordPress?

La forma más confiable es la verificación de hash: descargás la versión oficial del plugin desde el repositorio SVN de wordpress.org y comparás el MD5 o SHA256 de cada archivo contra los archivos instalados. WP-CLI tiene comandos para esto (wp plugin verify-checksums), aunque su efectividad depende de que wordpress.org tenga los checksums registrados para esa versión exacta.

¿Cuántos sitios WordPress fueron afectados por el backdoor dormante?

El plugin tenía más de 70.000 instalaciones activas en su pico. No hay una cifra pública confirmada de cuántos sitios tuvieron la versión comprometida específicamente, pero dado que las versiones afectadas fueron distribuidas como actualizaciones normales a través del sistema de WordPress, el alcance potencial es alto. El período de exposición cubre al menos desde 2020 hasta 2026.

¿Qué hacer si la versión de mi plugin difiere de la de wordpress.org?

Tratalo como un incidente de seguridad confirmado. Desactivá y eliminá el plugin inmediatamente. Buscá archivos adicionales que el backdoor pudo haber depositado, y revisá wp-config.php y los archivos de WordPress core contra sus checksums oficiales. Después de limpiar, revisá en Google Search Console si hay URLs indexadas con contenido que no reconocés.

Conclusión

Este caso no es una historia de un plugin oscuro que nadie usaba. Son 70.000 instalaciones, un vector de ataque que operó en silencio durante cinco años, y una brecha arquitectónica del ecosistema de plugins de WordPress que sigue sin solución sistémica.

Lo que cambió con este descubrimiento es la conciencia de que la verificación de versión no alcanza: necesitás verificación de integridad de archivos. El número que dice WP-CLI o el dashboard de WordPress no significa nada si el archivo en el disco es diferente al que publicó el desarrollador en wordpress.org.

Si administrás sitios WordPress, el paso inmediato es correr wp plugin verify-checksums --all y revisar los resultados. Si encontrás discrepancias en Quick Page/Post Redirect o en cualquier otro plugin, tratalo como un compromiso activo hasta que puedas verificar lo contrario con hashes.

Fuentes

• Anchor Host – Análisis técnico del backdoor en Quick Page/Post Redirect (abril 2026)
• BleepingComputer – Popular WordPress redirect plugin hid dormant backdoor for years
• Patchstack – WordPress redirect hack: análisis del esquema anadnet
• Wordfence Threat Intel – Quick Page/Post Redirect Plugin vulnerabilities
• WPScan – Quick Page/Post Redirect Plugin security data