Backdoors en WordPress: cómo encontrarlos y eliminarlos

Un backdoor en WordPress es una entrada oculta que le da a un atacante acceso permanente al sitio sin usar credenciales legítimas. Para detectar y eliminar backdoors WordPress hay que revisar archivos PHP fuera de lugar, cuentas admin desconocidas en la base de datos y modificaciones en wp-config.php. Sin una limpieza completa, la reinfección llega en días.

Un backdoor en WordPress es código malicioso que abre un canal de acceso secreto al sitio, completamente independiente de las credenciales normales. Puede estar escondido en archivos PHP de plugins, temas, el directorio /uploads/ o directamente en wp-config.php. Una vez instalado, el atacante puede volver cuando quiera aunque vos cambies todas las contraseñas del sitio.

¿Qué es un backdoor en WordPress y cómo funciona?

Un backdoor, o puerta trasera, es código que un atacante instala en tu WordPress para mantener acceso al sistema después de haber entrado por primera vez. No desaparece con el cambio de contraseña. No desaparece desinstalando el plugin comprometido. Persiste en el servidor hasta que encontrás el archivo específico y lo eliminás de raíz.

Hay tres tipos principales que hay que conocer:

• Backdoor PHP. Un archivo .php disfrazado de archivo legítimo, a veces con nombre parecido a wp-config.php o functions.php, que ejecuta comandos remotos. El patrón más frecuente combina eval() con base64_decode() para ofuscar el código y evitar detección.
• Usuarios fantasma. El atacante crea cuentas de administrador directamente en la base de datos, sin pasar por el panel de WordPress. Algunas cuentas no aparecen en la lista de usuarios del panel (sí existen en la tabla wp_users).
• Cron maliciosos. Tareas programadas en wp_cron que ejecutan código en horarios regulares para enviar spam, descargar más malware o exfiltrar datos.

Lo que hace peligroso a un backdoor no es el acceso inicial sino la persistencia. El atacante puede entrar una vez, instalar el backdoor y volver en silencio semanas después para robar datos de clientes, usar el servidor como relay de spam o infectar a otros sitios del mismo hosting compartido.

7 síntomas que indican que tu WordPress tiene un backdoor

Ponele que abrís el panel un martes y hay un admin llamado «support_wp2026» que no creaste vos. O que un cliente te escribe porque al entrar desde Google lo redirige a una farmacia online. Esos son los síntomas obvios. Los otros son más silenciosos:

• Admin desconocido en el panel. Aparece una cuenta de administrador que no reconocés. A veces el nombre parece legítimo: «admin», «wordpress_support», «backup_user».
• Archivos PHP en /wp-content/uploads/. Esta carpeta no debería tener archivos PHP ejecutables. Si los hay, son sospechosos sin excepciones.
• Contenido spam en tus páginas. Google Search Console te avisa de páginas con contenido farmacéutico o de apuestas que vos nunca publicaste.
• Redirecciones inesperadas. Los visitantes que llegan desde Google son enviados a otros sitios, especialmente desde dispositivos móviles.
• Reinfecciones repetidas. Limpiás el sitio, volvés a estar infectado en días. Señal clara de que no encontraste el backdoor original, solo sus efectos.
• Picos de CPU sin causa aparente. El servidor trabaja más de lo normal porque alguien está ejecutando procesos en tu nombre.
• Cloaking activo. Este es el más difícil de ver en 2026: el malware muestra el sitio normal a usuarios comunes pero envía contenido spam a los bots de Google. Se detecta comparando el cache de Google de tu URL con lo que ves vos directamente.

¿Qué significa reinfectarse varias veces? Exacto, nunca limpiaste el backdoor real, solo los archivos que dejó visibles. Sobre eso hablamos en herramientas especializadas para eliminar malware.

3 frentes de búsqueda: archivos, usuarios y tráfico anómalo

La detección efectiva requiere revisar tres capas distintas. Si mirás solo una, te quedás con la mitad del problema.

Frente 1: archivos PHP fuera de lugar

Los directorios que más hay que revisar son /wp-content/uploads/, /wp-includes/ y la raíz del sitio. Ninguno de estos debería tener archivos PHP que no sean parte del core de WordPress.

Por SSH podés buscar archivos modificados recientemente con:

find /ruta/wordpress/ -name "*.php" -newer wp-config.php -ls

Eso lista todos los PHP modificados después de wp-config.php. Si aparece algo en /uploads/, ahí está el problema (ningún archivo PHP debería estar ahí). También revisá wp-config.php línea por línea comparando con wp-config-sample.php del repositorio oficial. Cualquier bloque de código que no sea configuración de base de datos o claves de seguridad es sospechoso.

Frente 2: usuarios fantasma en la base de datos

Algunos backdoors crean cuentas de administrador directamente en wp_users, sin que aparezcan en el panel. Para verlos todos:

SELECT * FROM wp_users;
SELECT * FROM wp_usermeta WHERE meta_key='wp_capabilities' AND meta_value LIKE '%administrator%';

Si aparece una cuenta que no está en tu panel de WordPress, la encontraste.

Frente 3: tráfico anómalo en los logs del servidor

Revisá los logs de acceso buscando POST requests a archivos en /uploads/. Un archivo en esa carpeta que recibe peticiones POST no tiene nada que hacer ahí. También buscá parámetros GET extremadamente largos o en base64 (empiezan con «eyJ» o tienen caracteres mezclados sin sentido aparente), ya que algunos backdoors reciben comandos codificados de esa forma. Esto se conecta con lo que analizamos en las mejores soluciones de protección.

Herramientas de escaneo: Sucuri, Wordfence y análisis manual por SSH

Acá es donde mucha gente se confunde, y entiendo por qué: la diferencia entre las herramientas no es obvia hasta que la necesitás (spoiler: la necesitás justo cuando más importa).

El punto clave: Sucuri SiteCheck, la herramienta gratuita online, solo analiza lo que ve un navegador. Un backdoor que no se expone en el frontend no lo va a detectar. Según la guía oficial de Sucuri, para limpieza real necesitás el plugin instalado en el servidor o acceso SSH directo.

Wordfence tiene una base de firmas de malware conocido y, según sus propios datos, detecta el 94% de los archivos infectados con malware ya catalogado. El problema son los backdoors nuevos o personalizados que no están en la base todavía.

El análisis manual por SSH usando grep para buscar patrones como eval(, base64_decode(, system(, exec( y shell_exec( es el único método que encuentra backdoors genuinamente nuevos. Es lento, requiere saber lo que estás mirando, pero no tiene falsos negativos por desactualización.

Paso a paso: cómo eliminar un backdoor sin reinfección

El error más común es eliminar el archivo malicioso y dar el tema por cerrado. Si no cerrás el vector de entrada original, volvés a estar infectado en 48 horas.

Subís el proceso de limpieza, lo seguís al pie de la letra, pensás que está resuelto, y tres días después el sitio vuelve a enviar spam porque el atacante todavía tiene acceso por otra vía que no encontraste, porque no cambiaste la contraseña del SFTP, porque dejaste un plugin viejo con vulnerabilidad conocida, o porque wp-config.php tiene código que todavía no revisaste.

El proceso completo, en orden:

• Modo mantenimiento activo. Cortá el acceso público durante la limpieza para no dejar el sitio a medio limpiar expuesto.
• Cambiar TODAS las contraseñas. WordPress (todos los usuarios), hosting, SFTP, base de datos y los emails asociados a esas cuentas. Los atacantes a veces controlan el email para resetear contraseñas.
• Backup del estado actual. Sí, infectado. Si necesitás comparar archivos después, lo vas a necesitar.
• Scan completo con Wordfence o plugin Sucuri. Anotá todos los archivos marcados.
• Eliminar plugins y temas sospechosos del servidor. No los desactivés: la desactivación en el panel no borra los archivos del disco.
• Reemplazar archivos del core de WordPress. Descargá la versión oficial desde wordpress.org y sobreescribí los archivos directamente. No actualices: reemplazá. Es distinto.
• Limpiar wp_users de administradores desconocidos. Usá la query SQL del frente 2 para identificarlos y eliminarlos.
• Revisar wp-config.php línea a línea. Cualquier código que no sea configuración pertenece ahí.
• Revisar .htaccess. Los atacantes agregan redirecciones ahí que sobreviven a la limpieza del resto.
• Revisar tabla wp_options. Buscá option_name con valores de código PHP o URLs externas que no reconocés.
• Generar nuevas claves de seguridad en wp-config.php. Las claves viejas pueden seguir validando sesiones abiertas del atacante.

Si limpiaste y volviste a reinfectarte, no empezaste desde el principio. Volvé al paso 2. Tema relacionado: seguridad específica para tiendas online.

El ataque de supply chain de 2026: backdoors en 31 plugins comprados en Flippa

Este caso merece atención aparte porque cambió cómo hay que pensar en la seguridad de los plugins.

Un actor malicioso compró el portafolio «EssentialPlugin» en el marketplace Flippa, que incluía 31 plugins legítimos con base de usuarios real. En vez de actuar de inmediato, inyectó un backdoor de deserialización PHP dentro de wp-config.php y esperó 8 meses en silencio. El 5 de abril de 2026 activó el código, comprometiendo entre 20.000 y 60.000 sitios. Según reportes del sector, WordPress.org cerró los plugins el 7 de abril.

Acá viene el punto crítico: el cierre del repositorio no limpiaba el código ya instalado en wp-config.php. Eso requería intervención manual de cada administrador de sitio. Los plugins se cerraron pero el daño en los servidores ya estaba hecho.

Lo que hace a este ataque particularmente sofisticado es el mecanismo de comando y control: usó smart contracts de Ethereum para recibir instrucciones. No hay dominio para bloquear porque la blockchain no se puede censurar de esa forma.

¿La lección práctica? Antes de instalar o mantener un plugin, revisá su historial: ¿cambió de dueño recientemente? ¿Tuvo actualizaciones con changelog vago como «mejoras de rendimiento» sin detalles? Esas son señales. Un plugin con 10.000 instalaciones y cinco estrellas puede ser un vector de ataque si el dueño lo vendió a alguien con otras intenciones.

Podés leer más sobre este tipo de ataques en nuestro análisis del ataque de supply chain a plugins WordPress en 2026.

Prevención: configuración segura y auditoría regular

Mejor que limpiar es no tener que limpiar.

• Actualizaciones al día sin excepción. La mayoría de los backdoors entran por vulnerabilidades conocidas en plugins desactualizados. No hay vuelta a eso.
• 2FA en todas las cuentas admin. Un atacante con tu contraseña no puede entrar si necesita el segundo factor. Los plugins de autenticación como Google Authenticator o WP 2FA son opciones directas.
• Permisos de archivos correctos. 644 para archivos, 755 para directorios. Si tu servidor tiene archivos con 777, los estás dejando expuestos a escritura.
• Monitoreo de integridad de archivos. Sucuri y Wordfence tienen alertas que avisan cuando un archivo del core cambia. Si no hiciste una actualización vos mismo, no debería cambiar.
• Auditoría semanal de wp_users. Toma dos minutos y puede ahorrarte días de limpieza.
• Deshabilitar la edición de archivos desde el panel. Agregá define('DISALLOW_FILE_EDIT', true); en wp-config.php. Si un atacante llega al panel, no puede tocar el código de plugins o temas.
• Acceso SFTP/SSH limitado por IP. Solo las IPs que necesitan acceso deberían conectarse. Si tu hosting lo permite, configurá IP allowlisting.

Ojo con los hostings compartidos donde otros sitios del mismo servidor están infectados: pueden reinfectar el tuyo aunque hayas limpiado perfectamente. donweb.com ofrece planes con aislamiento entre cuentas que reducen ese riesgo de infecciones cruzadas.

Errores comunes al limpiar un WordPress infectado

Error 1: limpiar sin cambiar las contraseñas primero

Si el atacante tiene tus credenciales de SFTP o de base de datos, puede volver a subir el backdoor aunque hayas eliminado todos los archivos maliciosos. El cambio de contraseñas va antes de cualquier limpieza, no después.

Error 2: desactivar plugins en vez de eliminarlos

Desactivar un plugin desde el panel de WordPress no borra sus archivos del servidor. Si el backdoor está en la carpeta del plugin, sigue ahí aunque el plugin aparezca como «inactivo». Hay que eliminar la carpeta completa vía SFTP o desde el administrador de archivos del hosting. Más contexto en herramientas avanzadas de detección de intrusos.

Error 3: confiar solo en Sucuri SiteCheck como confirmación de limpieza

Sucuri SiteCheck puede marcar tu sitio como «limpio» y aun así tener un backdoor PHP en el servidor que no se expone al frontend. Es una herramienta útil para un primer vistazo, no para certificar que la limpieza está completa. La confirmación real viene del acceso SSH y la revisión directa de archivos.

Error 4: ignorar wp-config.php durante la limpieza

El ataque de EssentialPlugin de 2026 inyectó el backdoor precisamente en wp-config.php porque mucha gente no lo revisa durante la limpieza. Es el archivo más crítico de la instalación y uno de los primeros que hay que revisar línea a línea, no asumir que está intacto.

Preguntas Frecuentes

¿Cómo sé si mi sitio WordPress tiene un backdoor?

Los indicios más claros son: cuentas de administrador que no creaste vos, archivos PHP en /wp-content/uploads/, notificaciones de Google Search Console sobre malware, y redireccionamientos que solo ocurren cuando un visitante llega desde un buscador. Si el sitio fue infectado antes y se reinfectó después de limpiar, hay un backdoor que no encontraste. Instalá Wordfence y ejecutá un scan completo desde Herramientas > Wordfence > Scan.

¿Dónde busco archivos maliciosos en WordPress?

Los lugares prioritarios son /wp-content/uploads/ (no debería tener PHP), /wp-includes/ (solo archivos del core), la raíz del sitio (ningún archivo desconocido), y el directorio de temas activos (functions.php es un blanco frecuente). Por SSH, el comando find . -name "*.php" -newer wp-config.php lista todos los PHP modificados recientemente. Complementá con grep -r "eval(base64_decode" . para buscar el patrón de ofuscación más común.

¿Qué hacer si descubro un backdoor en WordPress?

Primero, no borrés solo el archivo malicioso y des el tema por cerrado. El proceso completo requiere poner el sitio en mantenimiento, cambiar todas las contraseñas (WordPress, hosting, SFTP, base de datos), reemplazar los archivos del core de WordPress desde el repositorio oficial, revisar wp-config.php y .htaccess línea a línea, limpiar usuarios desconocidos de la base de datos, y generar nuevas claves de seguridad en wp-config.php. Según guías de limpieza especializadas, saltear alguno de estos pasos es la causa principal de reinfecciones.

¿Por qué aparecen usuarios admin que no creé?

Un backdoor activo puede crear cuentas de administrador directamente en la tabla wp_users de la base de datos, sin pasar por el panel de WordPress. Algunas de esas cuentas están configuradas para no aparecer en la lista de usuarios del panel, pero existen en la base. Verificá con una query SQL directa: SELECT * FROM wp_users;. Si aparecen cuentas que no reconocés, eliminá tanto la entrada en wp_users como en wp_usermeta para ese ID de usuario.

¿Cómo evitar reinfecciones por backdoor?

La reinfección ocurre por cuatro razones: no se encontró el backdoor original, no se cambió el vector de entrada (contraseña de SFTP, plugin vulnerable), el hosting compartido tiene otros sitios infectados que contaminan el tuyo, o no se implementaron controles posteriores. Después de limpiar: activá el monitoreo de integridad de archivos en Sucuri o Wordfence, configurá alertas de nuevos usuarios administradores, mantenés todos los plugins actualizados y hacés una auditoría manual de wp_users una vez por semana.

Conclusión

El ataque de supply chain de abril de 2026 cambió algo concreto: ya no alcanza con confiar en los plugins del repositorio oficial de WordPress. Un plugin legítimo con años de historia puede volverse un vector de ataque si cambia de dueño.

Detectar y eliminar backdoors WordPress sigue el mismo proceso de siempre, tres frentes simultáneos: archivos PHP fuera de lugar, usuarios fantasma en la base de datos y tráfico anómalo en los logs. Lo que cambió es que ahora hay que agregar un cuarto: revisar el historial de ownership de cada plugin que tenés instalado.

Si tu sitio estuvo comprometido en algún momento de 2026 y tenías plugins del portafolio EssentialPlugin, revisá wp-config.php aunque el repositorio ya los haya cerrado. El cierre del plugin no limpia lo que ya está en tu servidor.

Fuentes

• Sucuri — Guía oficial para limpiar un WordPress hackeado
• Ecosistema Startup — 31 plugins WordPress con backdoor: qué hacer en 2026
• Sitios Hispanos — Cómo encontrar un backdoor en un sitio WordPress hackeado
• AyudaWP — Puertas traseras en WordPress
• Seguridad en WordPress — Ataque supply chain: plugins infectados 2026