# Encontrar una puerta trasera en WordPress: cómo localizar accesos ocultos > Encontrar puertas traseras en WordPress: revise el núcleo y plugins con WP-CLI, cuentas admin, mu-plugins, subidas y base de datos, y ciérrelas bien. Fuente: https://phpsos.de/es/ratgeber/backdoor-wordpress-finden/ Actualizado: 25/10/2026 Proveedor: PHP SOS, Ayuda de emergencia para PHP y seguridad de servidores. Ayuda inmediata por WhatsApp: https://wa.me/491736494914?text=Hola%20PHP%20SOS%2C%20necesitamos%20ayuda%20con%20nuestro%20servidor%20PHP.%20Empresa%3A%20%E2%80%A6%20Sitio%20web%3A%20%E2%80%A6 **En resumen:** la forma más rápida de encontrar una puerta trasera en WordPress es contrastar el núcleo y los plugins con las sumas de comprobación oficiales mediante WP-CLI y revisar después, de forma específica, los mu-plugins, las subidas, `wp-config.php`, las cuentas de administrador y la base de datos. Importante tras PHP2Shell: una actualización de WordPress no cierra la vulnerabilidad de PHP ni elimina una puerta trasera ya existente. ## Por qué los responsables de WordPress deberían mirar con más atención ahora Con PHP2Shell se han conocido en octubre de 2026 dos vulnerabilidades críticas en el propio PHP, CVE-2026-109618 y CVE-2026-109619. Permiten ejecutar código malicioso sin autenticación, con independencia de lo bien mantenida que esté su instalación de WordPress. Hay parches desde el 21/10/2026, pero según informes de los medios ya el 17/10 se observó un primer intento de ataque. Quien fue vulnerable en ese periodo debería buscar rastros. WordPress es un objetivo típico, porque muchas instalaciones tienen una estructura parecida y los atacantes conocen los escondites. Lo que deben hacer los responsables en general respecto a PHP2Shell se explica en la página [WordPress y PHP2Shell](https://phpsos.de/es/plattformen/wordpress/). Haga las revisiones siguientes, a ser posible, sobre una copia o después de una copia de seguridad. Los comandos solo leen y no modifican nada. ## Cómo notar una puerta trasera en el día a día Una puerta trasera está pensada para pasar desapercibida. Aun así, hay indicios que se notan también sin conocimientos técnicos. Entre ellos, las redirecciones a sitios ajenos que solo se producen con visitantes procedentes de la búsqueda de Google o solo en dispositivos móviles. También son sospechosas las páginas nuevas con publicidad de medicamentos, juegos de azar o copias de productos de marca que aparecen en el índice de búsqueda pero no en el backend de WordPress. Otros indicios son las advertencias de Google o del navegador, las quejas de clientes por correos de spam desde su dominio, un consumo de tiempo de cálculo repentinamente alto en el proveedor de hosting o administradores que nadie del equipo conoce. Ninguno de estos signos demuestra por sí solo una puerta trasera. Si varios aparecen a la vez, no debería posponer las revisiones siguientes. Y a la inversa: que no llame la atención nada de esto no significa que la instalación esté limpia. Precisamente las puertas traseras creadas solo para un acceso posterior no muestran a menudo ningún efecto hacia fuera. ## Encontrar una puerta trasera en WordPress: revisar el núcleo y los plugins WP-CLI puede comparar los archivos del núcleo de WordPress y de los plugins del directorio oficial con las sumas de comprobación publicadas. Cada discrepancia es una tarea de revisión concreta. ```bash cd /var/www/meine-seite # Archivos del núcleo frente a las sumas de comprobación oficiales wp core verify-checksums # Plugins del directorio oficial wp plugin verify-checksums --all # Versiones instaladas y estado wp plugin list wp theme list ``` Los plugins y temas comerciales no se pueden revisar así. Para ellos solo sirve la comparación con un paquete original recién descargado del proveedor. Los plugins desconocidos que nadie del equipo ha instalado son siempre sospechosos, aunque aparezcan desactivados. ## Escondites típicos en el sistema de archivos Algunos lugares aparecen una y otra vez en las instalaciones de WordPress comprometidas: - `wp-content/mu-plugins/`: se carga automáticamente y no aparece en la lista normal de plugins. - `wp-content/uploads/`: ahí van imágenes y documentos, no archivos PHP. - `wp-config.php`: líneas `include` o `require` adicionales al principio o al final. - `.htaccess` y `.user.ini` en el directorio web y en subcarpetas: redirecciones inesperadas o archivos precargados automáticamente. - Archivos en el directorio principal cuyos nombres recuerdan a archivos del núcleo de WordPress pero que no le pertenecen. ```bash # Archivos PHP en la carpeta de subidas find wp-content/uploads -type f -name "*.php*" # Contenido de los plugins Must-Use ls -la wp-content/mu-plugins/ # Todos los archivos .htaccess y .user.ini con su fecha de modificación find . \( -name ".htaccess" -o -name ".user.ini" \) -exec ls -la {} + # Archivos PHP modificados recientemente find . -type f -name "*.php" -newermt "2026-10-17" -ls ``` Los patrones de búsqueda generales para código ofuscado los describe la guía [Detectar y eliminar webshells](https://phpsos.de/es/ratgeber/webshell-erkennen/). ## Revisar usuarios, base de datos y tareas programadas Muchas puertas traseras ni siquiera están en el sistema de archivos. A los atacantes suele bastarles una cuenta de administrador adicional para volver más tarde. ```bash # Todos los administradores con su fecha de registro wp user list --role=administrator --fields=ID,user_login,user_email,user_registered # Tareas programadas en WordPress wp cron event list # Dirección del sitio (las manipulaciones provocan redirecciones) wp option get siteurl wp option get home # Entradas con scripts incrustados wp db query "SELECT ID, post_title FROM $(wp db prefix)posts WHERE post_content LIKE '% **Importante:** > Tras un hallazgo, cambie todas las contraseñas y las claves de seguridad de `wp-config.php`. De lo contrario, las sesiones existentes de los atacantes seguirán siendo válidas. ## Cerrar las puertas traseras y evitar que vuelvan Si ha encontrado una puerta trasera, una reinstalación suele ser más segura que reparar archivos sueltos. Este orden ha dado buen resultado: 1. Conservar las pruebas: guardar registros, archivos sospechosos y una exportación de la base de datos con fecha. 2. Llevar PHP a una versión corregida y reiniciar todos los procesos de PHP. 3. Instalar el núcleo de WordPress, los plugins y los temas de nuevo desde fuentes originales. 4. Conservar las subidas y la base de datos una vez verificadas, eliminar las cuentas ajenas y cambiar todos los accesos. 5. Impedir la ejecución de PHP en la carpeta de subidas a nivel de servidor. Para Nginx basta con un bloque en la configuración del servidor: ```nginx location ~* ^/wp-content/uploads/.*\.php$ { deny all; } ``` En Apache se logra lo mismo con una regla en la configuración del servidor para la carpeta de subidas. Un `.htaccess` en la propia carpeta de subidas es más débil, porque un atacante con permisos de escritura puede volver a modificarlo. Tras la limpieza, prevea unas semanas de observación más estrecha. Los nuevos administradores, los nuevos archivos PHP y los cambios en `wp-config.php` deberían llamar la atención de inmediato durante ese tiempo, por ejemplo mediante una revisión periódica con WP-CLI o una supervisión de archivos en el servidor. Cómo establecer después los permisos de archivos para que WordPress solo pueda escribir donde es necesario lo muestra la guía [Permisos de archivos en el servidor web](https://phpsos.de/es/ratgeber/dateirechte-webserver/). ## ¿Cómo ayuda PHP SOS en concreto? - Conservamos el estado de la instalación antes de modificar nada. - Revisamos el núcleo, los plugins, los temas, la base de datos, las cuentas y la configuración del servidor en busca de puertas traseras. - Reinstalamos WordPress desde fuentes limpias y conservamos solo contenidos verificados. - Reforzamos el servidor y la instalación y documentamos qué se encontró y qué se corrigió. El desarrollo de una limpieza lo describe el servicio [Eliminación de malware y webshells](https://phpsos.de/es/leistungen/malware-entfernung/). ## Preguntas frecuentes **¿Cierra una actualización de WordPress la vulnerabilidad PHP2Shell?** No. PHP2Shell está en el intérprete de PHP, no en WordPress. Actualizar WordPress, los temas o los plugins no cambia nada; lo decisivo es la versión de PHP del servidor y reiniciar todos los procesos de PHP. **¿Encuentra un plugin de seguridad todas las puertas traseras?** No de forma fiable. Un plugin se ejecuta dentro de la instalación comprometida y puede haber sido manipulado. Complételo con revisiones desde fuera, por ejemplo con las sumas de comprobación de WP-CLI y una comparación con los archivos originales limpios. **¿Qué son los mu-plugins y por qué resultan sospechosos?** Los plugins Must-Use de la carpeta wp-content/mu-plugins se cargan automáticamente y no aparecen en la lista normal de plugins. A los atacantes les gusta aprovecharlo porque los administradores rara vez miran esa carpeta. **¿Puede una puerta trasera estar también en la base de datos?** Sí. El código malicioso o las redirecciones se almacenan con frecuencia en opciones, entradas o widgets. Además, los atacantes suelen crear cuentas de administrador propias, que encontrará en la tabla de usuarios. ## Fuentes - [WordPress.org](https://wordpress.org/) - [php.net: avisos de seguridad](https://www.php.net/) - [OWASP Cheat Sheet Series](https://cheatsheetseries.owasp.org/)