Build/.git/config

Key Takeaways

• Critical Security Risk: The presence of a .git directory within a build/ or web-accessible folder is a high-severity vulnerability (CWE-200).
• Information Disclosure: The config file reveals remote repository URLs, branch structures, and potentially sensitive credentials or internal hostnames.
• Automated Exploitation: Attackers use specialized tools like git-dumper to reconstruct entire source codebases from exposed .git directories.
• Root Cause: This usually stems from improper CI/CD pipeline configurations or "copy-all" build scripts that fail to exclude hidden metadata.
• Mitigation Strategy: Implement strict web server rules (Nginx/Apache) to deny access to all dot-files and ensure build artifacts are sanitized.

Introduction

In modern DevOps workflows, the "build" directory is intended to be a clean, production-ready artifact containing only the compiled assets, minified JavaScript, optimized CSS, and static HTML required to run an application. However, a recurring and dangerous error in deployment pipelines is the accidental inclusion of the .git directory within this output—specifically, the build/.git/config file.

The .git/config file is the heart of a Git repository's local configuration. While it is vital for developers working in a local environment, its existence in a public-facing web directory is a catastrophic failure of security hygiene. When a web server serves the contents of a build/ folder, and that folder contains a .git directory, the entire version control history of the project becomes an open book to anyone with a web browser or a basic command-line tool.

This article provides a technical autopsy of why this happens, the specific data points exposed within the configuration file, and the professional-grade methods required to prevent such leaks in enterprise environments.

Deep Analysis

The Anatomy of build/.git/config

The config file follows an INI-style format, organized into sections denoted by square brackets. In a standard, healthy repository, this file manages how the local instance interacts with remote servers. When this file is exposed via build/.git/config, the following sections provide a roadmap for attackers:

[core]
    repositoryformatversion = 0
    filemode = true
    bare = false
    logallrefupdates = true

[remote "origin"]
    url = https://github.com/enterprise-org/secret-project.git
    fetch = +refs/heads/*:refs/remotes/origin/*

[branch "main"]
    remote = origin
    merge = refs/heads/main

From the example above, an attacker immediately gains three critical pieces of intelligence:

1. The Remote URL: The [remote "origin"] section reveals the exact location of the source code. If the URL is a private GitHub, GitLab, or Bitbucket instance, the attacker now knows the exact target for credential stuffing or phishing attacks against the organization's developers.
2. Internal Naming Conventions: The repository name (e.g., secret-project) provides insight into the company's internal project codenames, which can be used in social engineering.
3. Branching Strategy: The [branch] section tells the attacker which branches are active (e.g., main, develop, staging), allowing them to target specific versions of the code that might contain unpatched vulnerabilities.

The Mechanism of the "Git Leak" Attack

An attacker does not simply read the config file and stop there. The exposure of build/.git/config is often the first step in a multi-stage exploitation process. Modern automated scanners, such as those used by Shodan or Censys, constantly crawl the IPv4 space looking for the /.git/ pattern. Once identified, the attacker uses tools like git-dumper or dvcs-ripper.

These tools work by systematically requesting every file within the .git/ directory. They target .git/index (which contains a list of all files in the repo), .git/objects/ (which contains the actual file content compressed as blobs), and .git/logs/ (which contains the commit history). By reconstructing these pieces, an attacker can rebuild the entire project directory structure on their local machine, effectively downloading the 100% of the source code without ever having access to the actual Git server.

Quantitative Risk Assessment

The impact of this exposure can be quantified by looking at the "Data Exposure Ratio." In a typical web application, the build/ directory might contain 5MB of minified assets. However, the accompanying .git/ directory, if it contains the full history of a project with a 2-year development cycle, can easily exceed 250MB. This means an accidental configuration error can increase the data footprint of a single directory by 5,000%, providing a massive payload of sensitive information for the attacker.

Why does it end up in build/?

There are three primary technical reasons why a .git directory migrates into a build folder:

• Improper use of cp -r: A deployment script might use a command like cp -r . ./build/. Since the .git folder is a hidden directory within the root, a recursive copy command will include it unless specifically excluded.
• Docker Layer Caching: In Dockerized environments, if a COPY . . command is executed before a .dockerignore file is properly configured, the entire .git history is baked into the image layers. If that image is then used to serve static files, the risk is realized.
• Misconfigured Build Tools: Some older or poorly configured bundlers/task runners may treat the entire project root as the context for the build, inadvertently pulling in hidden metadata. This is similar to the risks seen in htdocs/.git/config exposure, where the web root itself is a Git repository.

Comparison / Alternatives

Understanding how different Git configurations interact is essential for preventing accidental exposure. Below is a comparison of the three main levels of Git configuration and their typical usage.

Common Mistakes / Misconceptions

Myth 1: "The .git folder is hidden, so users can't see it."
Reality: While .git is hidden in standard file explorers (like macOS Finder or Windows Explorer), it is perfectly visible to any HTTP request. An attacker does not need to "see" it in a browser; they only need to guess the path /build/.git/config. If the server returns a 200 OK instead of a 403 Forbidden or 404 Not Found, the directory is effectively public.

Myth 2: "Using a .gitignore file prevents this."
Reality: A .gitignore file tells Git which files to ignore when committing to the repository. It does not tell your build script or your web server which files to exclude from the build/ folder or the public web root. You need a .dockerignore for Docker, a .npmignore for NPM packages, and web server rules for your production environment.

Myth 3: "If I don't have secrets in my code, I'm safe."
Reality: Even without API keys, the exposure of your entire logic, proprietary algorithms, and internal infrastructure details (via the remote URL) constitutes a major intellectual property theft and a reconnaissance goldmine for attackers.

FAQ