Ficheros expuestos: por qué un `.git` o un `wp-config.bak` es una brecha

Por PathSentinel · Jesús Macías Rubiales — Investigación de seguridad web

La carpeta .git expuesta es uno de esos fallos que parecen inofensivos hasta que alguien te enseña lo que revela. Un .git público, un wp-config.bak olvidado o un .env accesible no son «archivos sueltos»: son las llaves de tu instalación servidas desde el navegador. Este artículo forma parte de nuestra guía sobre cómo saber si tu web está hackeada, y aquí nos centramos en por qué estos ficheros son una brecha y cómo cerrarla.

Qué revela realmente una carpeta .git expuesta

Cuando despliegas por FTP o «copiando la carpeta», muchas veces subes también el directorio .git de control de versiones. Si ese directorio queda accesible en tudominio.com/.git/, no estás exponiendo un archivo: estás exponiendo todo el historial de tu proyecto. Con herramientas públicas y triviales, cualquiera reconstruye tu código fuente completo a partir de una carpeta .git expuesta, incluidos:

• Credenciales de base de datos escritas en el código o en ficheros de configuración versionados por error.
• Claves de API de pasarelas de pago, correo, servicios en la nube o integraciones internas.
• Rutas, lógica de validación y comentarios que le dicen a un atacante exactamente dónde apretar.
• Contraseñas de commits antiguos que «borraste» del archivo pero siguen vivas en el historial.

Es decir: un fallo de configuración de un minuto convierte tu repositorio privado en documentación de ataque gratuita.

El primo cercano: wp-config.bak, .env y las copias «temporales»

El mismo problema se repite con los editores y los despliegues manuales. Al editar wp-config.php, muchos paneles o editores dejan una copia de seguridad automática: wp-config.php.bak, wp-config.php~, wp-config.old o wp-config.php.save. Aquí está el detalle crítico: el servidor solo interpreta como PHP los ficheros .php. Una copia terminada en .bak o .old se sirve como texto plano, así que cualquiera que la pida ve tus credenciales de base de datos y tus claves de seguridad en claro.

La lista de sospechosos habituales incluye:

• wp-config.php.bak, config.php.old, settings.php.save
• .env, .env.local, .env.backup
• info.php o phpinfo.php de pruebas que revelan toda la configuración del servidor
• Ficheros de log accesibles (error_log, debug.log) con rutas y datos internos

Estos ficheros son exactamente lo que rastrean los bots automatizados en cuanto tu dominio aparece publicado. No hace falta que seas un objetivo: basta con existir.

Por qué esto es una brecha y no un «detalle menor»

Un fichero expuesto no siempre significa que ya te hayan entrado, pero sí que la puerta está abierta y señalizada. La documentación de Google sobre sitios pirateados y las guías de OWASP sitúan la exposición de información sensible entre las causas raíz más frecuentes de compromiso: primero se filtra la configuración, después se usa esa configuración para entrar de verdad. Con tus credenciales de base de datos, un atacante puede leer datos de clientes, inyectar administradores o plantar un backdoor persistente.

Y el problema rara vez viene solo. Quien deja un .git público suele dejar también copias de la base de datos accesibles; lo tratamos en backups y .sql al descubierto. Cuando esas credenciales filtradas se usan para modificar el sitio, el síntoma visible acaba siendo el tráfico desviado que explicamos en redirecciones maliciosas.

Cómo comprobarlo y cerrarlo

La verificación es sencilla y la puedes hacer tú:

• Prueba a abrir en el navegador tudominio.com/.git/config. Si te descarga o muestra texto, tienes una carpeta .git expuesta.
• Prueba variantes de tu configuración: /wp-config.php.bak, /.env, /info.php.
• Bloquea el acceso a estos directorios y extensiones desde la configuración del servidor (reglas en .htaccess o en el bloque del servidor), no despliegues nunca la carpeta .git a producción y elimina las copias temporales tras editar.
• Si encuentras credenciales expuestas, considéralas comprometidas: rótalas todas (base de datos, API, claves de seguridad de WordPress), no solo cambies el fichero de sitio.

Este tipo de fuga es especialmente crítica en entornos exigentes como banca y tiendas con datos de tarjeta, donde una clave filtrada no es una molestia sino un incidente reportable. La referencia de buenas prácticas de CISA es un buen punto de partida para endurecer la configuración.