.git/config exposé : comment des crawlers pillent des dépôts de code entiers

Le 19 juin 2026, une seule adresse IP a envoyé 434 039 requêtes en une journée vers le blog du développeur Bruce Ediger, presque toutes ciblant un seul fichier : /.git/config. Le lendemain, la même adresse en a renvoyé 220 239. À titre de comparaison, ce serveur reçoit habituellement entre 96 000 et 120 000 requêtes par jour, tous visiteurs confondus. Ce pic n'est pas un déni de service aveugle : c'est un crawler spécialisé qui tente de reconstruire des dépôts Git entiers à partir d'un fichier de configuration oublié à la racine d'un serveur web.

L'histoire, documentée en détail sur son blog, illustre une faille aussi banale que redoutable : un dossier .git resté accessible publiquement à la racine d'un site. Une erreur de déploiement extrêmement courante, et un boulevard pour qui sait où chercher.

Pourquoi .git/config est une cible si précieuse

Quand vous clonez ou initialisez un dépôt Git, un dossier .git se crée à la racine du projet. Il contient tout l'historique des commits, les objets Git (le code source complet, version par version), les références de branches, et un fichier config qui liste les remotes configurés : l'URL du dépôt distant, souvent sous la forme [email protected]:organisation/projet.git.

Si ce dossier se retrouve déployé tel quel dans la racine publique d'un serveur web (un cas fréquent avec des déploiements FTP, des builds mal filtrés, ou un simple git clone directement dans le dossier servi par Apache ou Nginx), n'importe qui peut le demander en HTTP. Et contrairement à une idée reçue, il n'est pas nécessaire d'avoir un listing de répertoire activé pour piller un .git exposé : les noms de fichiers internes à Git sont prévisibles ( .git/HEAD, .git/index, les objets sous .git/objects/), ce qui permet à des outils automatisés de reconstruire un dépôt complet fichier par fichier, sans jamais voir la liste des fichiers présents.

Anatomie du crawler : ce que révèlent les journaux

En épluchant ses journaux Apache, Bruce Ediger a identifié un sous-réseau de 59 adresses IP (195.178.110.0/24) actif depuis le 13 mars 2025, cumulant 699 774 requêtes. Il distingue quatre comportements distincts :

• Scan de configuration généraliste, en continu depuis le début des relevés : requêtes vers .git/config, .env, ses variantes .env.save et .env.backup, wp-config.php ou docker-compose.prod.yml, avec un ou deux user-agents par jour.
• Recherche de vulnérabilités PHP classiques, les 6 et 7 avril 2026 : 377 requêtes en une heure et 52 minutes vers des fichiers comme phpinfo.php ou server_info.php, susceptibles de révéler la configuration du serveur.
• Le pic de spidering .git/config des 19 et 20 juin 2026, déclenché par une requête initiale sur /.git/HEAD, suivie d'un enchaînement systématique pour reconstituer le contenu du dépôt.
• Une campagne distincte les 15 et 16 mars 2026 (1 334 puis 380 requêtes), avec un grand nombre de user-agents différents, qui parcourait la page d'accueil et les articles du blog pour en extraire des URLs à visiter.

Détail piquant : Ediger fait tourner sur son propre site un générateur qui renvoie, pour chaque requête sur /.git/config, un contenu différent et partiellement aléatoire (noms de dépôts et de branches inventés). Le crawler a continué de spidérer malgré des réponses incohérentes d'une requête à l'autre, signe d'une collecte automatisée peu regardante sur la qualité de ce qu'elle absorbe.

Comment vérifier si vous êtes exposé

Le test prend dix secondes, depuis un terminal :

curl -I https://votre-domaine.fr/.git/config

Si la réponse est un 200 OK, votre configuration Git est publique et lisible par n'importe qui. Une réponse en 403 ou 404 signifie que l'accès est bloqué ou que le dossier n'existe pas à cet endroit, ce qui est la situation attendue.

Comment s'en prémunir

Trois réflexes suffisent à fermer cette faille durablement :

• Ne jamais déployer le dossier .git en production. Un pipeline de build (CI/CD, export d'artefact) doit produire un répertoire de déploiement qui ne contient que les fichiers nécessaires à l'exécution, jamais le dépôt Git lui-même.
• Bloquer explicitement l'accès au niveau du serveur web, en complément, au cas où un dossier .git se retrouverait malgré tout dans le répertoire public. Sur Apache :

  <Location "/.git">
      Require all denied
  </Location>

  Sur Nginx :

  location /.git {
      deny all;
      return 404;
  }

• Étendre la règle aux autres fichiers sensibles repérés dans les journaux d'Ediger : .env et ses variantes, ainsi que les fichiers de configuration d'outils tiers comme docker-compose.prod.yml, qui suivent le même schéma d'exposition accidentelle.

Notre lecture chez CZSyn

Ce que montre ce relevé, c'est que la faille .git/config n'a rien d'exotique : elle est scannée en continu, à bas bruit, depuis au moins mars 2025, par des réseaux qui alternent entre sondage discret et rafales massives quand ils flairent une cible qui répond. Le chiffre qui doit alerter n'est pas le pic à 434 039 requêtes en une journée, mais la régularité du bruit de fond qui le précède : ce sont ces scans permanents, invisibles dans un tableau de bord classique, qui finissent par trouver le serveur mal configuré.

Pour une PME ou une agence qui gère plusieurs sites, la bonne pratique n'est pas de réagir après coup mais d'auditer l'ensemble du parc au moment du déploiement : vérifier qu'aucun dossier .git, aucun fichier .env, aucun fichier de configuration de build ne traîne dans le répertoire public, sur chaque environnement, à chaque mise en production. C'est un contrôle de quelques minutes qui évite une fuite de code source, voire de secrets, si des identifiants ont un jour été committés par erreur dans l'historique du dépôt.

Sources primaires

• Bruce Ediger, « Caught a .git/config crawler », 2026.
• Git, documentation officielle, « gitrepository-layout ».
• Apache HTTP Server, documentation officielle, directive « Location ».