Un backdoor PHP en WordPress es código malicioso que los atacantes dejan embebido en archivos del servidor para mantener acceso remoto, incluso después de que cambiás contraseñas o eliminás plugins infectados. En 2026, los backdoors PHP siguen siendo el método de persistencia más común en sitios WordPress hackeados, y el error más frecuente es creer que el problema está resuelto cuando en realidad apenas se tapó la superficie.
En 30 segundos
- Los backdoors PHP sobreviven a cambios de contraseña y reinstalaciones parciales porque viven en archivos del servidor, no en la base de credenciales
- Las ubicaciones favoritas son wp-content/uploads/, wp-includes/, mu-plugins/ y el functions.php del tema activo
- Los patrones más comunes son eval(base64_decode()), eval(gzinflate()) y llamadas a system() o shell_exec()
- Wordfence detecta la mayoría; los backdoors muy ofuscados requieren revisión manual con grep o comparación contra el core limpio de WordPress
- La limpieza completa implica reemplazar wp-core vía FTP, auditar plugins y themes, revisar la base de datos y cambiar todas las credenciales
¿Qué es un backdoor PHP en WordPress y cómo funciona?
Un backdoor PHP en WordPress es una función o archivo malicioso que le permite al atacante ejecutar comandos remotos en el servidor, subir archivos arbitrarios o crear cuentas de administrador, sin necesidad de usar las credenciales normales del sitio. A diferencia del malware diseñado para robar datos de una sola vez, el backdoor garantiza acceso futuro al servidor independientemente de lo que haga el administrador legítimo del sitio.
Ponele que limpiás tu WordPress, eliminás el plugin comprometido y cambiás la clave de administrador. Dos semanas después volvés a tener spam en tus páginas o tus visitantes ven redirects raros. Eso es un backdoor activo: el atacante nunca perdió el acceso real al servidor.
La mecánica es directa. El atacante sube o inyecta un archivo PHP (o un fragmento dentro de un archivo legítimo) que acepta parámetros por POST o GET. Cuando hace una petición HTTP a esa URL con el parámetro correcto, puede ejecutar cualquier comando en el servidor, listar archivos, crear usuarios o instalar más malware. Todo desde un browser, sin necesidad de autenticarse en WordPress.
Lo que hace difícil detectarlos es la ofuscación: el código real está codificado en base64, comprimido con gzip, rotado con str_rot13, o repartido en fragmentos que se ensamblan en runtime. El archivo a primera vista parece basura o texto sin sentido. Y suelen tener nombres que imitan archivos legítimos: wp-feed.php, wp-tmp.php, class-backup.php (sí, con guión y todo para parecer código de WordPress). Esto se conecta con lo que analizamos en parchear las vulnerabilidades antes de explotarlas.
¿Dónde se ocultan los backdoors en WordPress?
Los hackers no ponen los backdoors en lugares obvios. Los esconden donde un administrador promedio no mira.
- wp-content/uploads/: La carpeta de subidas es la favorita. PHP no debería ejecutarse ahí, pero en muchos servidores lo hace. Los atacantes suben archivos PHP camuflados como imágenes (image.php.jpg o directamente archivos .php con nombre aleatorio). Si tenés PHP ejecutable en uploads/, cualquier archivo que llegue ahí es un vector de ataque potencial.
- wp-includes/: Archivos nuevos en esta carpeta son siempre sospechosos. WordPress no agrega PHP a wp-includes/ entre versiones, así que un wp-class-compat.php o wp-feed2.php que no reconocés no debería estar ahí.
- functions.php del tema activo: El lugar más común para inyección de código. Un atacante que comprometió el acceso al tema mete el backdoor al final del archivo, mezclado con funciones legítimas. Nadie mira el final del functions.php.
- mu-plugins/: Los must-use plugins se cargan automáticamente sin aparecer en el panel de administración. Un backdoor en mu-plugins/ es casi invisible para el admin y sobrevive incluso si desactivás todos los plugins desde el panel de WordPress.
- wp-config.php: No suele ser el archivo principal infectado, pero agregan código al inicio o al final. Si ves PHP antes de
¿El patrón más frecuente? El backdoor en uploads/ porque muchos sitios no tienen la regla de servidor que bloquea ejecución de PHP en esa carpeta. Es la primera que prueban los scripts automatizados de ataque.
Patrones de código malicioso que debés reconocer
No hace falta ser experto en PHP para identificar un backdoor. Hay combinaciones de funciones que aparecen una y otra vez, y que no tienen ningún uso legítimo en un WordPress estándar.
eval(base64_decode())
El clásico. eval(base64_decode('...')) toma una cadena codificada en base64, la decodifica y la ejecuta como PHP. Según el análisis de WPHackedHelp sobre este tipo de ataque, esta combinación aparece en una porción enorme del malware detectado en WordPress. La función eval() ejecuta cualquier string como código PHP, y base64 oculta el contenido real para que no sea legible a simple vista.
Si ves eval( en cualquier archivo de tu WordPress, es una señal de alarma. No existe uso legítimo de eval() en themes y plugins bien escritos.
eval(gzinflate(base64_decode()))
Una capa más de ofuscación: el código real está comprimido con gzip y luego codificado en base64. Cuando se ejecuta, decodifica la base64, descomprime el gzip y evalúa el PHP resultante. Esta cadena hace que los escáneres simples basados en firmas no lo detecten, porque la «firma» del malware nunca aparece en texto plano. Lo explicamos a fondo en firewall adicional en la puerta principal.
system(), shell_exec() y passthru()
Estas funciones ejecutan comandos del sistema operativo directamente desde PHP. Un backdoor que acepta un parámetro $_GET['cmd'] y lo pasa a system() es una web shell completa. El atacante puede ejecutar cualquier comando Linux desde el browser, borrar archivos, instalar software, exfiltrar datos, agregar más backdoors. Subirás el archivo al servidor, verificás que funciona con un comando inocente como id, y de ahí en más tenés control total del sistema sin tocar WordPress.
El código ofuscado más simple que implementa esto ocupa dos líneas. Eso solo.
str_rot13 y preg_replace con /e
str_rot13 rota los caracteres 13 posiciones en el alfabeto, otra capa de ofuscación. La función preg_replace con el modificador /e (deprecada en PHP 7 pero aún funcional en instalaciones antiguas) evalúa el reemplazo como código PHP. Menos comunes hoy, pero los encontrás en sitios con PHP desactualizado o en ataques que apuntan a instalaciones legacy.
Cómo detectar backdoors: métodos manuales vs herramientas automatizadas
Lo ideal es combinar ambos enfoques. Las herramientas automatizan lo grueso; la revisión manual confirma los casos dudosos.
Herramientas automatizadas
- Wordfence (plugin gratuito y premium): Compara todos los archivos del core, plugins y themes contra un repositorio de firmas conocidas y detecta archivos modificados. La versión gratuita tiene firmas con 30 días de retraso respecto al premium. Para un sitio ya comprometido, ese delay importa.
- MalCare: Escaneo profundo vía servidor con detección basada en comportamiento, no solo en firmas. Detecta backdoors muy ofuscados que Wordfence puede perder. El plan básico incluye limpieza automática a USD 99/año.
- Sucuri SiteCheck: Escáner externo gratuito que analiza el HTML visible del sitio. Detecta malware que se sirve al visitante, pero no ve los backdoors PHP que sólo responden a requests específicos con parámetros concretos.
Métodos manuales
Con acceso SSH podés buscar directamente. Dos comandos esenciales:
Archivos PHP modificados en los últimos 7 días:
find /ruta/wordpress -name "*.php" -mtime -7
Patrones de backdoor en archivos PHP:
grep -rl "eval(base64_decode" /ruta/wordpress --include="*.php"
grep -rl "shell_exec\|system\|passthru" /ruta/wordpress --include="*.php"
También podés descargar la misma versión de WordPress que tenés instalada desde wordpress.org y comparar archivo por archivo contra tu instalación. Cualquier archivo en wp-admin/ o wp-includes/ que no esté en la descarga oficial es sospechoso por definición. Tema relacionado: alternativas de protección más fuertes.
| Método | Detecta backdoors conocidos | Detecta ofuscación avanzada | Requiere SSH | Costo |
|---|---|---|---|---|
| Wordfence (gratis) | Sí, con 30 días de delay | Parcial | No | Gratuito |
| Wordfence (premium) | Sí, en tiempo real | Buena cobertura | No | USD 119/año |
| MalCare | Sí | Buena (basado en comportamiento) | No | USD 99/año |
| grep manual | Los que conocés | Sí, si sabés qué buscar | Sí | Gratuito |
| Comparación con core limpio | Sí (archivos modificados) | Sí | Sí (FTP o SSH) | Gratuito |

¿Cómo encontrar y eliminar usuarios admin fantasma?
Un usuario administrador creado por el atacante es tan peligroso como un backdoor en un archivo. Le da acceso completo a WordPress y, si no lo eliminás, puede reinstalar el malware desde el panel en cualquier momento. Es el mecanismo de persistencia más fácil de implementar y el que más se pasa por alto en limpiezas rápidas.
- Revisá wp-admin → Usuarios → Administradores: Cualquier cuenta que no reconocés (admin2, support, administrator, o nombres con caracteres aleatorios como xm94ko) es sospechosa. Fijate en la fecha de registro: si es reciente y no la creaste vos, hay que eliminarla.
- Verificá la base de datos directamente: Si sospechás que la instalación está comprometida a un nivel más profundo, accedé a phpMyAdmin o por MySQL y ejecutá:
SELECT user_login, user_email, user_registered FROM wp_users;. Cualquier cuenta con email de dominio sospechoso o nombre que no reconocés, fuera. - Auditá wp_usermeta: Después de eliminar el usuario de wp_users, verificá que no quedaron entradas huérfanas en wp_usermeta con ese user_id. En algunas configuraciones pueden reactivar capacidades de la cuenta.
¿Y si el atacante ocultó el usuario de la lista de wp-admin? Pasa. Algunos backdoors modifican las queries de WordPress para que ciertos user_id no aparezcan en la interfaz. La base de datos directa es la única verificación confiable en ese caso.
Pasos para limpiar backdoors de WordPress: eliminar y restaurar
Hacerlo mal significa que el sitio se reinfecta en días. El procedimiento completo:
- Paso 1: Descargá WordPress limpio. Desde wordpress.org, bajá la misma versión que tenés instalada. Esto da los archivos de referencia para wp-admin/ y wp-includes/.
- Paso 2: Reemplazá wp-admin/ y wp-includes/ vía FTP. Borrá esas carpetas del servidor y subí las versiones limpias. Estos directorios no deben tener ningún archivo personalizado tuyo, así que el reemplazo total es seguro.
- Paso 3: Auditá cada plugin y tema. Los plugins del repositorio oficial: borrálos y reinstalalos desde WordPress.org. Para plugins premium o de terceros, comparálos con la copia original. Si no tenés la copia original, reemplazarlos es la opción conservadora.
- Paso 4: Limpiá wp-content/uploads/. Eliminá todos los archivos .php de la carpeta de subidas. No hay razón legítima para que haya PHP en uploads/.
- Paso 5: Auditá la base de datos. Revisá wp_options buscando código PHP serializado sospechoso (eval, base64) en campos como option_value. También revisá wp_posts: a veces el malware se inyecta en contenido de posts como shortcodes que ejecutan PHP.
- Paso 6: Cambiá todas las credenciales. Contraseña de WordPress admin, base de datos (en wp-config.php), FTP y cPanel. Si el servidor también fue comprometido, avisá al soporte del hosting.
- Paso 7: Verificá con un escaneo completo. Después de la limpieza, Wordfence o MalCare para confirmar que no quedan archivos infectados. Un escaneo limpio no es garantía absoluta, pero es la mejor verificación automatizada disponible.
Si tenés un backup previo al hackeo y podés identificar cuándo ocurrió el compromiso, restaurar el backup es más confiable que limpiar manualmente (a condición de entender cómo entró el atacante y tapar esa brecha antes de restaurar, porque si no volvés a estar en la misma situación pero con el sitio «limpio» solo por un rato).
Qué está confirmado y qué no
| Afirmación | Estado | Fuente |
|---|---|---|
| Los backdoors en uploads/ son un vector activo en 2026 | Confirmado | Wordfence, Sucuri |
| eval(base64_decode) es el patrón de ofuscación más común | Confirmado | WPHackedHelp, MalCare |
| Los mu-plugins son un vector de persistencia menos detectado que otros | Confirmado | Sucuri blog, investigación forense 2025 |
| Los escáneres gratuitos detectan el 100% de los backdoors | Falso | Los backdoors muy ofuscados o personalizados evaden firmas conocidas |
| Cambiar contraseñas de WordPress elimina los backdoors | Falso | Por definición: el backdoor no depende de credenciales de WP |
| Reinstalar WordPress core elimina todos los backdoors | Parcialmente verdadero | Elimina los del core; los de plugins, themes y uploads persisten |
Cómo hardening WordPress tras eliminar backdoors
Limpiar el sitio es la mitad del trabajo. Sin hardening, el mismo atacante (o sus scripts automatizados) puede volver. Ya lo cubrimos antes en plugins de seguridad más robustos.
- Permisos de archivos correctos. Archivos PHP: 644. Directorios: 755. wp-config.php puede quedar en 640 para mayor restricción. Cualquier archivo con 777 es un vector potencial.
- Bloqueá ejecución de PHP en uploads/. En Apache, un archivo .htaccess dentro de wp-content/uploads/ con
php_flag engine offo la directiva equivalente impide que PHP se ejecute ahí aunque el atacante suba un archivo. En Nginx, la regla equivalente bloquea esa ubicación. - Web Application Firewall. Wordfence en modo firewall bloquea intentos de subida de shells y acceso a URLs conocidas de backdoors antes de que lleguen a PHP. Si tu hosting tiene ModSecurity a nivel servidor, activarlo agrega una capa más.
- Dos factores en todas las cuentas administradoras. Wordfence trae 2FA incluido. Si el vector de entrada inicial fue una contraseña comprometida, 2FA corta esa posibilidad en el próximo intento.
- Actualizaciones al día. La mayoría de los hackeos empiezan por una vulnerabilidad conocida en un plugin desactualizado. Si necesitás infraestructura con gestión de seguridad activa y actualizaciones controladas, un hosting especializado como donweb.com puede ayudar con el stack del servidor.
- Monitoreo de integridad de archivos. Wordfence puede alertarte por email cuando se modifica algún archivo del core. Configurá esa alerta y no la ignores: una modificación no esperada en horario de madrugada es exactamente la señal que querés ver antes de que el daño escale.
Errores comunes al limpiar un WordPress hackeado
- Solo cambiar contraseñas y dar el tema por resuelto. El backdoor no depende de las credenciales de WordPress. Sigue ahí aunque cambiés todo. Sin limpiar los archivos infectados, el sitio vuelve a reinfectarse en horas o días.
- Reinstalar WordPress sin tocar plugins ni themes. El core reinstalado está limpio, pero si el backdoor está en functions.php o en un plugin, sobrevive. La limpieza tiene que ser completa o no sirve.
- Escanear sin verificación manual para casos dudosos. Los escáneres automáticos pierden backdoors muy bien ofuscados o personalizados. Si el sitio ya fue comprometido, el escaneo automático es un punto de partida, no la verificación definitiva.
- No identificar cómo entró el atacante. Si limpiás sin tapar el vector de entrada (plugin vulnerable, contraseña débil, FTP sin protección), el mismo atacante puede volver a injectar. La forensia básica es parte obligatoria de la limpieza.
- Asumir que encontraste el único backdoor. Un atacante con experiencia deja más de uno. Si encontrás un archivo sospechoso, buscá más antes de dar la limpieza por terminada.
Preguntas Frecuentes
¿Cómo detectar backdoors ocultos en mi WordPress?
Combiná Wordfence (escáner gratuito o premium) con búsqueda manual por SSH: grep -rl "eval(base64_decode" /ruta/wordpress --include="*.php". Revisá también que no haya archivos .php en wp-content/uploads/ y que wp-includes/ no tenga archivos nuevos no reconocidos. Un escaneo de integridad comparando con el core limpio de WordPress.org es la verificación más confiable para el código base.
¿Dónde se esconden los backdoors PHP en WordPress?
Las ubicaciones más frecuentes son wp-content/uploads/ (archivos PHP camuflados como imágenes o con nombres aleatorios), wp-includes/ (archivos con nombres similares a los del core), functions.php del tema activo (al final del archivo) y mu-plugins/ (invisible desde el panel de administración). También se inyectan dentro de archivos legítimos mezclados con código funcional.
¿Cómo eliminar un backdoor de WordPress completamente?
El procedimiento completo implica: reemplazar wp-admin/ y wp-includes/ con archivos limpios de WordPress.org vía FTP, reinstalar todos los plugins desde el repositorio oficial, eliminar PHP de wp-content/uploads/, auditar la base de datos en wp_options y wp_users, y cambiar todas las credenciales (WordPress, base de datos y FTP). Sin completar todos estos pasos, el sitio puede reinfectarse en poco tiempo.
¿Qué patrones de código indican malware en WordPress?
Las funciones más características del malware PHP son eval() (especialmente combinada con base64_decode o gzinflate), system(), shell_exec(), passthru() y str_rot13. Ninguna de estas tiene uso legítimo en themes y plugins estándar de WordPress. También son señales de alarma las variables dinámicas como $$variable y las funciones que reciben parámetros de $_GET o $_POST sin validación visible.
¿Cómo verificar si hay usuarios admin fantasmas en WordPress?
Revisá wp-admin → Usuarios → filtrar por rol Administrador. Cualquier cuenta que no reconocés es sospechosa. Para verificación más profunda (algunos backdoors ocultan usuarios del panel), accedé a la base de datos vía phpMyAdmin y ejecutá: SELECT user_login, user_email FROM wp_users;. Eliminá usuarios no reconocidos y revisá wp_usermeta para borrar los metadatos asociados a esos user_id.
Conclusión
Un WordPress que «parece» limpio después de cambiar contraseñas sigue siendo un sitio comprometido si los archivos infectados están intactos. Los backdoors PHP son la puerta que el atacante dejó abierta para volver cuando quiera, y en 2026, con herramientas de ataque automatizadas que barren millones de instalaciones WordPress buscando vulnerabilidades conocidas, la ventana entre un sitio comprometido y uno reinfectado puede ser de horas.
Los patrones son reconocibles, las herramientas de detección son accesibles (Wordfence gratuito hace una parte importante del trabajo), y el procedimiento de limpieza es documentable. Lo que no tiene solución de una sola vez es el mantenimiento posterior.
El hardening post-limpieza, las actualizaciones al día, el bloqueo de ejecución PHP en uploads/ y el monitoreo de integridad de archivos no son extras opcionales. Son la diferencia entre un incidente único y uno que se repite cada mes.
Fuentes
- Wordfence – Plugin de seguridad y escáner de malware para WordPress
- Sucuri Blog – Hidden Backdoors Uncovered in WordPress Malware Investigation
- WPHackedHelp – eval(base64_decode) hack en WordPress: análisis y remoción
- MalCare – Cómo detectar backdoors PHP y cuentas admin falsas en WordPress
- AyudaWP – Puertas traseras en WordPress: qué son y cómo eliminarlas