Backdoors PHP en WordPress: detectarlos tras un hackeo

En pocas palabras: Detectá backdoors PHP buscando archivos .php dentro de /wp-content/uploads/, ejecutando wp core verify-checksums con WP-CLI para validar el core contra los checksums oficiales de WordPress.org, revisando usuarios administradores fantasma en la tabla wp_users y contrastando versiones de plugins contra la base de datos WPVulnerability.

Detectar backdoors PHP en WordPress después de un hackeo implica revisar cuatro frentes: archivos .php dentro de /wp-content/uploads/, usuarios administrador que nadie creó, patrones sospechosos en los logs del servidor y la integridad del core verificada con WP-CLI.

Un backdoor PHP es un archivo o fragmento de código que el atacante instala tras comprometer tu sitio para volver a entrar sin pasar por el login ni repetir el ataque original. Suele vivir en carpetas de subidas, plugins desactualizados o la base de datos, se comunica con parámetros ofuscados en base64 y con él el atacante ejecuta comandos remotos y crea administradores con permisos totales.

Ojo con un detalle: el malware visible es la parte menor del problema. El backdoor es la razón por la que tu «limpieza» dura dos días.

¿Cuáles son los indicadores iniciales de que tu WordPress tiene un backdoor?

Ponele que un lunes abrís el panel y aparece un post promoviendo pastillas en japonés que vos nunca escribiste. Nadie de tu equipo lo publicó. Ese es el momento de asumir que hay un backdoor, no de borrar el post y seguir con tu vida.

Las señales externas suelen aparecer antes que cualquier alerta técnica:

• Administradores desconocidos. Ordená la lista de usuarios por fecha de registro; cualquiera que no puedas explicar es sospechoso número uno.
• Contenido en idiomas que no manejás. Spam farmacéutico japonés o apuestas en ruso publicados en tu sitio indican acceso de escritura por alguien ajeno.
• Redirecciones intermitentes. Vos entrás y todo normal, pero desde mobile el visitante cae en otra página. El backdoor discrimina por user-agent.
• Avisos de Search Console. Google detecta páginas de spam inyectadas mucho antes que tu ojo.
• Actividad fuera de horario. Publicaciones o cambios de plugins registrados a las 4 de la mañana, cuando nadie de tu equipo trabaja.

No estás solo en esto. El Centro de Ciberseguridad de Castilla-La Mancha advirtió sobre un hackeo masivo en WordPress que expuso miles de webs con malware, y campañas similares se repiten durante todo 2026. La escala del problema hace que asumir «a mí no me van a hackear» sea mala estrategia.

¿Por qué la limpieza rápida no alcanza y el backdoor sobrevive?

Un hackeo de WordPress no termina cuando el atacante entra. Termina cuando dejó tres cosas: una webshell para ejecutar comandos, un usuario administrador de reserva y algún mecanismo de persistencia (una tarea programada, un archivo en mu-plugins, una opción en la base de datos). Si borrás solo la webshell, las otras dos piezas lo reconstruyen. Relacionado: limitar el movimiento lateral tras una intrusión.

El contexto de 2026 empeoró el panorama. En abril, LPB Digital relevó varios plugins infectados y TechRepublic cubrió la campaña de plugins con backdoor del mismo período. Entre las variantes que circularon este año se mencionan infecciones vía productos piratas asociados a BdThemes y la variante wp2shell, que crea un usuario administrador automáticamente al ejecutarse.

¿Y qué pasa cuando limpiás apurado y dejás alguna pieza viva? Exacto: en menos de 48 horas el usuario admin vuelve a aparecer y el ciclo recomienza.

¿Cómo detectar backdoors PHP en WordPress revisando la carpeta uploads?

La regla es simple: en /wp-content/uploads/ no debería existir ningún archivo .php. Esa carpeta existe para imágenes, PDFs y videos. WordPress jamás necesita ejecutar código desde ahí, así que cualquier .php que encuentres es malware hasta que pruebes lo contrario.

El problema es que los atacantes aprovechan la estructura por año y mes. Una webshell puede estar en /wp-content/uploads/2026/03/avatar.php mezclada entre tus fotos de marzo. Por eso el comando find es tu mejor amigo:

find wp-content/uploads -name "*.php" -type f

Tardás diez segundos y te ahorrás una semana de dudas. Si querés afinar, agregá -newermt "2026-01-01" para ver solo archivos creados este año.

Una webshell típica pesa poco y dice poco. Tres o cuatro líneas con funciones como base64_decode(gzinflate(...)), eval($_POST['cmd']) o combinaciones de str_rot13. Nada legible a propósito: la ofuscación existe para pasar inadvertida tanto ante tu ojo como ante los escáneres básicos. Para más detalles técnicos, mirá reforzar las cabeceras de seguridad.

Subiendo un nivel, verificá la integridad del core:

wp core verify-checksums

Ese comando compara tus archivos contra los hashes oficiales y lista modificaciones, archivos extra y faltantes. Completalo con una revisada a wp-content/mu-plugins/ (todo lo que hay ahí se ejecuta siempre, lugar favorito para persistencia), al final de wp-config.php y al .htaccess. Como recuerdan en Ayuda WordPress sobre puertas traseras, el backdoor no siempre es un archivo exótico: a veces es una línea agregada a uno que ya existía.

¿Cómo auditar usuarios fantasma en la base de datos wp_users?

Arrancá con esta consulta en phpMyAdmin o por CLI:

SELECT ID, user_login, user_email, user_registered FROM wp_users ORDER BY user_registered DESC;

Cruzá cada fecha de registro con tu historial real. Un usuario creado a las 3:47 de un domingo, con un correo de dominio raro y rol administrador, no lo contrataste vos. Para confirmar el rol, mirá el campo wp_capabilities en la tabla wp_usermeta: si figura administrator en un usuario que no reconocés, tenés tu intruso.

Diferenciar un legítimo de uno creado por malware es cuestión de contexto: los legítimos tienen historial (posts publicados, comentarios moderados, sesiones coherentes), los fantasma suelen aparecer en frío, sin ninguna actividad previa, muchas veces minutos después del primer acceso malicioso que vas a encontrar en los logs. En ataques tipo wp2shell la creación del admin es automática, así que su fecha de registro casi calza con la del compromiso inicial.

Al eliminarlo, hacelo desde el panel de administración (con copia previa) y cerrá todas las sesiones activas después.

¿Qué buscás en los logs del servidor para reconstruir el ataque?

Abrís el access.log, filtrás por POST hacia uploads, aparece una petición a un .php que devuelve 200, abrís ese archivo, encontrás tres líneas con base64_decode envuelto en gzinflate, seguís el hilo hacia atrás y descubrís que el primer acceso fue hace cuatro meses, justo cuando instalaste ese tema pirata para probarlo. Esto se conecta con lo que analizamos en reducir la superficie de ataque de WordPress.

Ese recorrido es el análisis forense básico, y estos son los patrones que delatan al atacante:

• POST a .php dentro de uploads con respuesta 200. Es la conversación del atacante con su webshell. grep -E "POST.*uploads.*\.php" access.log y listo.
• Parámetros GET larguísimos o codificados. Cadenas que empiezan con eyJ (base64 de JSON) o query strings kilométricas indican datos pasados al shell.
• Probing masivo. Rachas de 404 contra nombres de plugins vulnerables seguidas de un 200: ahí encontraste el momento de la intrusión.
• Nombres casi idénticos a archivos reales. wp-conflg.php con ele en vez de i, class.wp.php, archivos que imitan el core.

El timestamp del primer evento anómalo vale oro: define tu punto de restauración. Todo backup posterior a esa fecha está contaminado.

¿Qué herramientas sirven para escanear backdoors en WordPress?

Ninguna herramienta sola alcanza. Cada una mira una capa distinta del problema, y la combinación es lo que te da cobertura real:

Leíste bien la columna de límites: el escáner que corre dentro del sitio comprometido depende de la salud del propio servidor. Si el atacante instaló algo a nivel de sistema, el escáner puede estar leyendo una versión «maquillada» de los archivos. Por eso conviene complementar con una descarga fresca de WordPress y un diff manual contra tu instalación.

Sobre las firmas de ofuscación (base64_decode, gzinflate, str_rot13): aparecen en la mayoría de las muestras, pero el malware moderno usa variables variables ($$x) y ensamblado dinámico que escapan a cualquier grep simple. Otros servicios como Sucuri o MalCare apuntan a lo mismo desde ángulos parecidos; no existe un benchmark independiente que corone a uno sobre el resto, así que tomá cualquier comparativa de fabricantes con pinzas. Ya lo cubrimos antes en blindar los accesos con llaves y segundo factor.

¿Cómo eliminar el backdoor sin que el sitio se reinfecte?

El error fatal está documentado en todas las guías serias de limpieza, incluida la de Una i Desarrollador Web sobre sitios hackeados: borrar el malware sin cerrar el vector de entrada termina en reinfección en torno a las 48 horas. El orden correcto es este:

1. Guardá evidencia forense. Copia completa de archivos y dump de la base de datos antes de tocar nada. Sin eso, no vas a poder reconstruir cómo entraron.
2. Identificá el vector. Cruzá el timestamp del primer archivo malicioso con los logs: instalación de un plugin, contraseña SFTP filtrada, tema pirateado, hosting compartido comprometido.
3. Cerrá la puerta. Actualizá o eliminá el plugin vulnerable, rotá todas las contraseñas (WordPress, SFTP, base de datos) y regenerá claves SSH.
4. Borrá los artefactos. Webshells, usuarios fantasma, tareas programadas maliciosas, modificaciones en .htaccess y mu-plugins.
5. Reinstalá el core limpio. Descarga oficial más verificación con checksums.
6. Vigilá siete días. Logs e integridad diaria; si reaparece cualquier artefacto, el vector sigue abierto.

El estudio de caso publicado en el repositorio de wnstify sobre un caso real de backdoor ilustra bien el ciclo: mientras quedó un canal de entrada vivo, cada limpieza duró días. Cuando cerró el vector, el problema terminó. La secuencia importa más que la velocidad.

¿Qué hardening aplicás después de la limpieza?

Limpiar sin endurecer es dejar la puerta con el pestillo roto. Esta es la lista mínima post-limpieza:

• Rotá las sales de wp-config.php. Regenerar AUTH_KEY y compañía invalida todas las cookies y sesiones existentes, incluidas las del atacante.
• Activá 2FA en cuentas críticas. El admin principal y cualquier cuenta que publique contenido, mínimo.
• Limitá intentos de login. Bloqueo temporal tras cinco fallos mata el brute force automatizado.
• Desactivá el editor de archivos. define('DISALLOW_FILE_EDIT', true); evita que un acceso al panel se convierta en edición de código.
• Alertá sobre nuevos administradores. Una notificación automática ante cada alta de admin te avisa del backdoor el día uno, no el mes dos.
• Mantené backups fuera del servidor. Si el backup vive en el mismo hosting comprometido, el atacante lo cifra o lo borra. Revisá si tu proveedor (por ejemplo, los planes de donweb.com) incluye respaldos externos automáticos.

Si usás Wordfence, asegurate de que el firewall esté en modo habilitado y no en aprendizaje: el modo aprendizaje registra amenazas pero no las bloquea, detalle que mucha gente pasa por alto.

Los errores más comunes al limpiar un WordPress hackeado

• Restaurar un backup viejo sin rotar credenciales. El backup anterior a la infección parece la salida fácil, pero si no cambiaste contraseñas ni cerraste la vulnerabilidad, restauraste también el problema. Rotá todo antes de levantar cualquier cosa.
• Delegarle toda la detección al escáner del panel. El plugin de seguridad no ve el cron del sistema operativo, ni procesos del servidor, ni opciones alteradas silenciosamente en la base de datos. Complementá con revisión manual de logs y filesystem.
• Buscar solo «eval(» en el código. El malware de 2026 usa str_rot13, variables variables, hex y carga remota de payloads. Tu grep va a encontrar la mitad. Buscá el conjunto completo de funciones y desconfiá de todo archivo PHP con fechas recientes en carpetas estáticas.
• Borrar sin copia previa. Eliminás el archivo sospechoso, desaparece la evidencia, y la próxima vez que te rompan el sitio arrancás de cero. Primero copiá, después borrá.

Qué está confirmado y qué no

Para cerrar, separamos lo verificable de lo que todavía está en el aire:

• Confirmado: campañas de plugins maliciosos con backdoor reportadas en abril de 2026 por medios especializados, y un hackeo masivo con miles de sitios afectados advertido por el centro de ciberseguridad regional.
• Confirmado: la metodología de detección (find, grep, checksums, auditoría de wp_users, logs) es procedimiento estándar documentado por múltiples guías técnicas independientes.
• Confirmado: el patrón de reinfección rápida cuando el vector queda abierto aparece de forma consistente en estudios de caso y guías de limpieza.
• Pendiente: cifras únicas y consolidadas de sitios afectados por campaña; las estimaciones varían según la fuente y el alcance que considere cada una.
• Pendiente: atribución concreta de las campañas de 2026 a grupos específicos; las investigaciones siguen abiertas.

Preguntas Frecuentes

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

Buscá archivos .php en /wp-content/uploads/ con el comando find y revisá usuarios administradores con fechas de registro inexplicables. Sumá señales como posts en idiomas raros, redirecciones móviles y avisos de Search Console. Si dos o más coinciden, tratá el sitio como comprometido y empezá el proceso forense.

¿En qué carpetas y archivos se esconden los backdoors de WordPress?

Los lugares favoritos son /wp-content/uploads/ (aprovechando la estructura por año y mes), wp-content/mu-plugins/, la raíz del tema activo, wp-config.php y .htaccess. También hay persistencia en la base de datos, especialmente en la tabla wp_options. Revisar solo una de estas ubicaciones garantiza dejar piezas vivas.

¿Sirve el escáner gratuito de Wordfence o necesito la versión premium?

La versión gratuita funciona como primera pasada: compara archivos contra el repositorio oficial y aplica firmas conocidas, con menor frecuencia de escaneo. La premium agrega revisiones más frecuentes y firmas actualizadas en tiempo real. Ninguna de las dos ve el cron del servidor ni reemplaza la lectura manual de logs.

¿Me conviene reinstalar WordPress desde cero o limpiar los archivos infectados?

Si tenés un backup previo a la infección y verificado, reinstalar el core limpio y migrar el contenido suele ser más seguro que cazar archivos uno por uno. La limpieza quirúrgica solo cierra cuando identificaste el vector y todos los artefactos. Frente a la duda, reinstalación más auditoría completa de base de datos gana.

¿Por qué mi sitio se reinfecta días después de limpiarlo?

Quedó un mecanismo de persistencia activo: un usuario administrador residual, una tarea programada o el propio vector de entrada sin parchar. El script del atacante vuelve a soltar la webshell con solo esperar. Cerrá el vector, rotá las sales de wp-config.php y revisá las tareas programadas para cortar el ciclo definitivamente.

Conclusión

Lo que cambió en 2026 es la escala: campañas distribuidas vía plugins maliciosos y compromisos masivos convirtieron la revisión forense en rutina obligatoria para cualquier administrador de WordPress, no en tarea de emergencia. Lo que no cambió es la mecánica: el backdoor sobrevive porque es una arquitectura de persistencia, no un archivo suelto.

Si sacás una sola idea de acá, que sea esta: detectar es un proceso de cuatro frentes (uploads, wp_users, logs, checksums) y eliminar sin cerrar el vector es tiempo perdido. Abrí una terminal hoy, corré el find sobre tu carpeta de uploads y verificá tus checksums. Diez segundos de prevención valen más que una semana de limpieza.

Fuentes

• Centro de Ciberseguridad de Castilla-La Mancha – Alerta institucional sobre hackeo masivo en WordPress con miles de webs afectadas.
• TechRepublic – Cobertura de la campaña de plugins maliciosos con backdoor de abril de 2026.
• LPB Digital – Relevamiento de plugins de WordPress infectados durante abril de 2026.
• Ayuda WordPress – Guía sobre puertas traseras en WordPress y sus mecanismos de persistencia.
• Estudio de caso de wnstify en GitHub – Documentación de un caso real de backdoor con ciclo completo de reinfección.