Reports
CRÍTICA[CONFIGURACIÓN]#3584078

Listado de directorios en un servidor web de Essity dejaba al descubierto credenciales de base de datos y copias de la web

Un servidor web de Essity tenía activado el listado de directorios, así que cualquiera podía recorrer sus ficheros: credenciales de la base de datos, una copia de seguridad de 69 MB con todo el código y documentos internos.

Resumen
Resumen en castellano de un reporte público, no una traducción literal. El código y los comandos se mantienen como en el original.

Resumen

El investigador lazyar encontró en el programa de Essity un servidor web con el listado de directorios (directory listing) activado. El nombre del sitio y su dirección aparecen tachados en la versión pública del reporte.

Con esa opción activa, cuando se pide una carpeta que no tiene página de índice, el servidor devuelve una lista con todo lo que contiene. Aquí eso dejaba a la vista la estructura completa de ficheros del sitio, y en ella había cosas que nunca deberían estar dentro de la raíz web:

  • credenciales de la base de datos;
  • copias de seguridad completas de la web, entre ellas un fichero de 69 MB con todo el código fuente;
  • documentos internos sensibles;
  • el directorio de subidas (uploads);
  • el panel de administración, admin.php.

HackerOne clasificó la debilidad como Information Exposure Through Directory Listing con severidad crítica. El reporte se envió el 3 de marzo de 2026, consta como resuelto y se hizo público el 10 de junio de 2026.

Pasos de reproducción

El reporte no detalla pasos: solo da la dirección del servidor, que está tachada en la versión pública. Lo que describe se reduce a esto:

  1. Abrir en el navegador la raíz del servidor afectado (https://████████/).
  2. El servidor devuelve el listado de ficheros y carpetas en lugar de una página.
  3. Desde ese listado se accede a la estructura completa, con las credenciales, las copias de seguridad y los documentos internos.

Impacto

Según el investigador, un atacante podía:

  • Comprometer la base de datos: las credenciales funcionaban y daban lectura y escritura completas sobre una base de datos con datos personales de clientes.
  • Llevarse todo el código fuente descargando la copia de seguridad de 69 MB.
  • Acceder a datos de clientes en el directorio de subidas, que podía contener información sensible de usuarios.
  • Atacar el panel de administración: admin.php quedaba accesible y expuesto a ataques de fuerza bruta.
  • Llevarse información de negocio y propiedad intelectual de los documentos internos y del código.

El investigador añade que exponer datos personales así supone incumplir normas como el RGPD o la CCPA.

Remediación

El reporte figura como resuelto, pero no explica qué se cambió.

Qué aprender de este caso

  • Al revisar un dominio, pide la raíz y carpetas típicas como /backup/, /uploads/, /old/ o /includes/ sin nombre de fichero. Si sale una página tipo "Index of /", el listado está activo y conviene mirarlo entero.
  • Desactiva el listado en el servidor (Options -Indexes en Apache, autoindex off en Nginx) y no te fíes de que cada carpeta tenga su index: la que no lo tenga queda a la vista.
  • Guarda las copias de seguridad y los ficheros de configuración con credenciales fuera de la raíz web. Aunque el listado esté apagado, un .zip o un config con nombre fácil de adivinar se sigue pudiendo descargar.
  • Si unas credenciales han estado expuestas, cámbialas. Y limita desde dónde acepta conexiones la base de datos, para que un fichero de configuración filtrado no baste para entrar.