debug.log público en WordPress: qué filtra y cómo cerrarlo

Respuesta corta: si activas WP_DEBUG_LOG, WordPress escribe los errores en /wp-content/debug.log, y ese fichero se puede descargar desde el navegador. Puede contener rutas del servidor, versiones de plugins, consultas a la base de datos y a veces datos personales o claves. Para cerrarlo: desactiva el log o llévalo fuera de la carpeta pública desde wp-config.php, bloquea el acceso en Apache o nginx y saca el fichero que ya existe.

Es de los descuidos más comunes en WordPress: alguien activa la depuración para arreglar un error, lo arregla y se olvida de desactivarla. No es un hackeo, pero un debug.log público le da a un atacante mucha información gratis. Esta guía forma parte de nuestra guía sobre qué hacer con un WordPress hackeado.

Qué es el debug.log y por qué es un problema

WordPress tiene tres constantes de depuración en wp-config.php:

• WP_DEBUG: activa el modo depuración.
• WP_DEBUG_LOG: guarda los errores en un fichero. Si vale true, el fichero es wp-content/debug.log.
• WP_DEBUG_DISPLAY: muestra los errores en pantalla (nunca debería estar activo en una web en producción).

El problema es la ubicación, que lo convierte en un debug.log público. wp-content es una carpeta pública, y las reglas estándar de WordPress no impiden descargar un .log. Cualquiera que pida https://tudominio.com/wp-content/debug.log lo recibe, y hay robots que lo piden a todas las webs WordPress que encuentran.

Qué puede filtrar, según lo que hayan escrito los plugins y el tema:

• Rutas completas del servidor, que a menudo incluyen el usuario del hosting (/home/usuario/public_html/…).
• Nombres y versiones de plugins y temas, justo lo que un atacante necesita para buscar plugins vulnerables.
• Errores de base de datos con la consulta completa, el prefijo de las tablas y, a veces, datos de usuarios.
• Correos, IPs, nombres de clientes o usuarios, si algún plugin los escribe al registrar un error.
• Respuestas de servicios externos (pasarelas de pago, CRM, envío de correo) que algunos plugins vuelcan al log, a veces con tokens.

Además, el fichero crece sin límite: hemos visto debug.log de varios gigas llenando el disco del hosting.

Cómo saber si te pasa

curl -sI https://tudominio.com/wp-content/debug.log
curl -s -r 0-1500 https://tudominio.com/wp-content/debug.log

Si el primer comando devuelve 200 (o 206) y el segundo enseña líneas como [06-Oct-2026 09:12:33 UTC] PHP Warning: …, está expuesto. Un 403 o un 404 es lo que quieres ver. Ojo con los 200 que en realidad devuelven tu página de error en HTML: no es el log.

Comprueba también si Google lo ha indexado con site:tudominio.com inurl:debug.log, y mira en el servidor si las constantes están activas:

wp config get WP_DEBUG
wp config get WP_DEBUG_LOG
ls -lh wp-content/debug.log

Cómo cerrar un debug.log público paso a paso

1. Revisa qué contiene antes de tocarlo

Antes de moverlo, mira si hay claves o datos personales. Si los hay, tendrás que cambiar esas claves y valorar si es una brecha de datos.

grep -ciE "password|passwd|token|api[_-]?key|secret|bearer" wp-content/debug.log
grep -oiE "[a-z0-9._%+-]+@[a-z0-9.-]+\.[a-z]{2,}" wp-content/debug.log | sort -u | head

2. Desactiva el log o sácalo de la carpeta pública

Si no estás depurando nada, desactívalo:

wp config set WP_DEBUG false --raw
wp config set WP_DEBUG_LOG false --raw
wp config set WP_DEBUG_DISPLAY false --raw

Si necesitas seguir registrando errores (es buena idea en webs con tienda o formularios), indica una ruta fuera de la carpeta pública. Desde WordPress 5.1, WP_DEBUG_LOG acepta una ruta:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', '/home/usuario/logs/wp-debug.log' );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

Comprueba que la carpeta existe y que PHP puede escribir en ella. Busca también si las constantes están definidas dos veces en wp-config.php o si algún plugin activa el log por su cuenta.

3. Bloquea el acceso en el servidor

Aunque desactives el log, bloquéalo: el día que alguien lo vuelva a activar, seguirá cerrado.

En Apache 2.4, añade esto al .htaccess de la raíz o de wp-content:

<Files "debug.log">
    Require all denied
</Files>

En hostings con Apache 2.2 (cada vez menos), la sintaxis es Order allow,deny seguido de Deny from all dentro del mismo bloque.

En nginx, dentro del bloque server, antes de las reglas de PHP:

location ~* /wp-content/debug\.log$ {
    deny all;
}
# o, para cualquier .log de la web:
location ~* \.log$ {
    deny all;
}

Después, nginx -t y recarga. En Plesk, estas reglas van en «Configuración de Apache y nginx» → «Directivas adicionales de nginx». Si usas una CDN o un cortafuegos delante, puedes bloquear la ruta también ahí.

4. Saca el fichero que ya existe

Muévelo fuera de la carpeta pública (puede servirte para depurar) o, si no lo necesitas, bórralo:

mkdir -p ~/logs && mv wp-content/debug.log ~/logs/debug-$(date +%F).log
curl -sI https://tudominio.com/wp-content/debug.log

El último comando debe devolver 403 o 404.

5. Limpia lo que haya salido fuera

• Si contenía claves o tokens, cámbialos en el servicio correspondiente.
• Si estaba indexado, en cuanto devuelva 403 o 404 Google lo irá quitando; para acelerarlo, usa la herramienta «Retiradas» de Search Console.
• Si contenía datos personales de clientes o usuarios, es una brecha de datos: valora la notificación a la AEPD en un plazo de 72 horas (en aepd.es tienes una herramienta para decidirlo).

Errores habituales

• Activar la depuración para arreglar un error y no desactivarla. Es, con diferencia, el origen más habitual. Cuando depures un error crítico, apúntate quitarlo al terminar.
• Desactivar el log y dejar el fichero. El fichero antiguo sigue ahí, descargable.
• Usar WP_DEBUG_DISPLAY en producción. Los errores salen en pantalla para cualquier visitante.
• Bloquear en .htaccess en un servidor nginx. nginx no lee .htaccess; la regla no hace nada.
• No mirar qué había dentro. Si había claves, siguen siendo válidas.

Para agencias: encontrar los debug.log abiertos de toda la cartera

En una cartera de webs, siempre hay alguna en la que alguien activó la depuración hace meses. Jeffrey lo comprueba una vez al día, desde fuera y sin plugin, en todas las webs que detecta como WordPress: pide /wp-content/debug.log, lee solo el principio del fichero y, si se sirve como texto y tiene el formato de un log de PHP, abre un aviso para revisar con el tamaño del fichero. Si el servidor devuelve tu página de error en HTML, no lo cuenta como expuesto. Cuando el fichero deja de ser accesible (403 o 404), el aviso se cierra solo.

No es un aviso crítico, porque un log abierto no es un hackeo, pero sí uno de esos descuidos que conviene cerrar la misma semana.

Preguntas frecuentes