Un debug.log de WordPress sin protección revelaba rutas internas y plugins en un sistema del Departamento de Defensa

Resumen

El investigador xgoon encontró en un sistema incluido en el programa del Departamento de Defensa de EE. UU. un fichero debug.log de WordPress que cualquiera podía abrir, sin autenticarse. El fallo pertenece a la debilidad "Information Exposure Through Debug Information": el registro de depuración, pensado para quien administra el sitio, quedaba servido por la web como un fichero más.

El contenido eran avisos y advertencias de PHP, y con ellos se filtraban la ruta absoluta de la aplicación en el servidor y detalles de un plugin instalado. HackerOne recoge la severidad como baja. El host y la dirección exacta del fichero aparecen censurados en el reporte público.

El reporte se envió el 28 de agosto de 2025, consta como resuelto y se divulgó el 12 de enero de 2026.

Pasos de reproducción

1. Abrir en un navegador la dirección del fichero debug.log, censurada en el reporte público. No hace falta iniciar sesión.
2. Comprobar que el servidor devuelve directamente el contenido del registro. El reporte incluye este fragmento:

[18-Jun-2025 15:19:46 UTC] PHP Warning:  Undefined array key "host" in /home/site/wwwroot/wp-content/plugins/wp-optimize/cache/class-wpo-cache-config.php on line 251
[18-Jun-2025 15:19:46 UTC] PHP Deprecated:  strtolower(): Passing null to parameter #1 ($string) of type string is deprecated in /home/site/wwwroot/wp-content/plugins/wp-optimize/cache/class-wpo-cache-config.php on line 251

Impacto

Según el reporte, un atacante sin autenticar podía obtener lo siguiente:

• Ruta interna del servidor: el registro muestra la ruta completa /home/site/wwwroot/. El investigador señala que este dato puede servir de apoyo en ataques posteriores, como la inclusión de ficheros locales o remotos (LFI/RFI).
• Plugin identificado: aparece la ubicación del plugin wp-optimize y parte de su funcionamiento, lo que permite buscar vulnerabilidades conocidas que le afecten.
• Comportamiento ante errores: los avisos enseñan cómo reacciona el sistema a una entrada inesperada, algo útil para intentar saltarse validaciones.
• Riesgo futuro: el fragmento publicado solo contiene avisos de PHP, pero si el fichero siguiera creciendo podría acabar guardando tokens, claves de API, consultas SQL o credenciales.

Remediación

El reporte no detalla qué cambió exactamente el programa; solo consta como resuelto. Estas son las medidas que propuso el investigador:

1. Bloquear el acceso público a los ficheros .log con .htaccess o con reglas del servidor web. Ejemplo para Apache:

<FilesMatch "\.log$">
  Require all denied
</FilesMatch>

1. Desactivar la depuración en producción en wp-config.php:

define('WP_DEBUG', false);
define('WP_DEBUG_LOG', false);

1. Actualizar wp-optimize a la última versión, para cubrir posibles vulnerabilidades y las llamadas a funciones obsoletas.
2. Revisar los registros con regularidad para detectar información sensible y eliminar las entradas innecesarias.

Qué aprender de este caso

• En un WordPress, prueba si el debug.log se sirve por la web: con WP_DEBUG_LOG activado, su ubicación por defecto es wp-content/debug.log, dentro de la carpeta pública del sitio.
• Lee los avisos de PHP como un mapa: una sola línea como las de este caso ya da la ruta absoluta, el plugin, el fichero y la línea de código.
• Si necesitas registrar errores en producción, escribe el fichero fuera de la raíz web. Así no dependes de que una regla como FilesMatch esté bien aplicada, sobre todo si el servidor cambia o no lee .htaccess.
• Trata el registro de errores como un dato sensible: hoy guarda un aviso de strtolower(), pero mañana podría guardar una consulta o un token.