Exposed .git and .env Files: Find Them Before Attackers

The most common total loss is a forgotten artefact

In the updated OWASP risk list, Security Misconfiguration has moved from position five to position two (OWASP Top 10:2025). The underlying data is unambiguous: an average incidence rate of 3.00 percent with a maximum rate of 27.70 percent, 719,084 recorded occurrences and 1,375 mapped CVEs across 16 bundled weakness classes (OWASP Top 10:2025, A02 Security Misconfiguration). More remarkable than the ranking is the finding behind it: across the analysed data set, every tested application showed some form of misconfiguration (OWASP Top 10:2025).

An exposed .git directory is the prototype of this category. It is not a vulnerability in the sense of a programming error - no buffer overflow, no injection. It is a file sitting where nobody expected it, which the web server dutifully serves because nobody has configured it otherwise. That is exactly why it does not appear in a vulnerability feed. Anyone who bases security work on CVE notifications is structurally blind to this risk.

For the reporting period July 2024 to June 2025, the German Federal Office for Information Security counts an average of 119 new vulnerabilities per day, an increase of around 24 percent over the previous report (BSI, The State of IT Security in Germany 2025). In the same period the BSI registered 950 ransomware cases, around 80 percent of which affected small and medium-sized enterprises (BSI, The State of IT Security in Germany 2025). Those numbers describe the pressure - but they do not describe the entry route. In many cases it is far more mundane: a set of credentials that was retrievable somewhere.

The economics on the attacker side are correspondingly simple. No exploit knowledge is required, only a list of domains and an HTTP client. On 20 and 21 April 2025, GreyNoise observed roughly 4,800 unique IP addresses per day specifically looking for /.git/config - the largest spike since September 2024, whereas the three preceding waves each involved around 3,000 IP addresses (GreyNoise). 95 percent of all IP addresses observed in this category over a 90-day window were classified as malicious (GreyNoise). Germany ranked third among target regions with 4,138 observed IP addresses, behind Singapore and the United States (GreyNoise).

The findings list: what is actually reachable on websites

The following list is not a theoretical collection. It describes the paths that regularly answer with HTTP 200 in external checks of company websites - usually on systems that are otherwise well maintained (project experience). The common denominator: all of these files are created during development or deployment and have no business being in the served directory.

This enumeration matches the test the OWASP Web Security Testing Guide describes under WSTG-CONF-04: the review of old, backup and unreferenced files for sensitive information (OWASP Web Security Testing Guide). The guide names three effects: configuration files with database credentials and internal paths, unreferenced administration pages with powerful functionality, and old file versions in which already fixed defects remain exploitable (OWASP Web Security Testing Guide).

Backup archives may contain copies of all files within - or even outside - the webroot. This allows an attacker to quickly enumerate the entire application, including unreferenced pages, source code and include files.

— OWASP Web Security Testing Guide, WSTG-CONF-04

Why a 403 response on /.git/ proves nothing

The most common fallacy goes like this: somebody opens https://your-domain.com/.git/ in a browser, sees a 403 page and considers the topic closed. That check is worthless because it asks the wrong question. A Git repository is not read through the directory but through individual files inside it whose names are known in advance.

There are at least four reasons why a 403 on the directory can coincide with a 200 on the files below it. First: many rule sets block only the exact directory path (location = /.git/) instead of every path starting with it. Second: a 403 also appears when merely the directory listing is disabled - the web server is saying I will not show you the contents, not I serve nothing here. Third: the rule sits at the CDN or the web application firewall while the origin server remains unprotected and reachable through a second address. Fourth: the rule exists for www.your-domain.com but not for the apex domain, the staging subdomain or an old domain still pointing at the same document root.

GET https://your-domain.com/.git/         -> 403  (directory blocked)
GET https://your-domain.com/.git/HEAD     -> 200  "ref: refs/heads/main"
GET https://your-domain.com/.git/config   -> 200  [remote "origin"] url=https://...
GET https://your-domain.com/.git/index    -> 200  DIRC ... (file list of the checkout)

Assessment: the repository is fully readable.
The 403 on the directory did not prevent access -
it only suppressed the directory listing.

The consequence for your own routine is unambiguous: do not query the directory, query concrete files - and do not evaluate only the status code, evaluate the content. A server that returns a friendly 200 page reading page not found for every request makes pure status-code checking worthless.

• /.git/HEAD - answers with ref: refs/heads/main or a commit hash
• /.git/config - contains the remote URL, often with username and token
• /.git/index - starts with the DIRC signature and lists every file of the checkout
• /.git/logs/HEAD - reflog with commit hashes, authors and timestamps
• /.git/packed-refs - reference list of all branches and tags
• /.git/objects/info/packs - index of the pack files for bulk download
• /.env and /.env.local - check the content for KEY=VALUE patterns, not just for status 200

From a metadata fragment to the complete source code

Git is a content-addressed object store. Every object - commit, tree, file content - lives at a path derived entirely from its SHA hash. Whoever can read .git/HEAD knows the current reference. Resolving the reference yields the commit hash. The commit points to a tree, which points to further trees and file contents. Each step is another HTTP request at a computable address. A directory listing is not needed at any point.

.git/index accelerates the procedure further: the file contains the complete file list of the last checkout with paths and associated object hashes. It is effectively a ready-made table of contents - turning step-by-step reconstruction into a targeted retrieval of exactly the interesting files: configurations, database access, payment integrations, deployment scripts.

A documented campaign shows how industrialised this approach has become: between August and September 2024, an attacker group systematically searched target lists of more than 500 million IP addresses, 12,000 IP ranges, 500,000 domains and around one million cloud host names for the path /.git/config (Sysdig Threat Research Team, Operation EMERALDWHALE). More than 67,000 URLs with exposed Git configuration were found (Sysdig Threat Research Team). This produced over 15,000 stolen cloud credentials and access to more than 10,000 private repositories (Sysdig Threat Research Team). Of roughly 6,000 sampled access tokens, about 2,000 were still valid (Sysdig Threat Research Team).

The damage does not stop at the source code. A valid repository token implies write access to the code base, database credentials imply the data set, mail credentials imply sending under your own sender domain. Treating source code as the only loss at this point substantially underestimates the event. The same chain is what makes third-party scripts a security risk as soon as an attacker gains write access to served files.

Server rules for nginx and Apache

The server rule is the emergency brake, not the solution - but it works immediately and belongs on every system. Two details determine its quality: it has to match on a prefix basis, covering every path below the directory, and it should return 404 instead of 403. A 403 confirms to a scanner that something worth protecting exists at that location.

# nginx: do not serve deployment artefacts (server block)

# Version control metadata - the directory AND every file below it
location ~ /\.(git|svn|hg|bzr)(/|$) {
    return 404;
}

# All dot files, with an exception for ACME and security.txt
location ~ /\.(?!well-known/) {
    return 404;
}

# Backups, dumps, editor leftovers, archives
location ~* \.(bak|old|orig|save|swp|swo|sql|dump|tar|tgz|zip|rar|7z)$ {
    return 404;
}

# Directory listings off by default
autoindex off;

The second rule in the example blocks all dot files using a negative lookahead for .well-known/. That matters because legitimate content lives under this path: the ACME challenge for certificate issuance and the security.txt documenting the reporting channel for vulnerabilities. How to set that channel up properly is described in the article on security.txt and vulnerability disclosure.

# Apache 2.4: vhost configuration (preferred) or .htaccess

# Version control and environment files: return 404 instead of 403
RedirectMatch 404 "/\.(git|svn|hg|bzr)(/|$)"
RedirectMatch 404 "/\.env"
RedirectMatch 404 "/\.DS_Store"

# Backups, dumps and editor leftovers
<FilesMatch "\.(bak|old|orig|save|swp|swo|sql|dump|tgz|zip)$">
    Require all denied
</FilesMatch>

# Directory listings off
Options -Indexes

Once the rules are in place, the result belongs in the same observation routine as certificate lifetimes and response times. The XICTRAQ security scan checks the served responses from the outside and reports when a path that previously answered with 404 suddenly returns content. Complementing this, the article on HTTP security headers covers the second half of delivery hardening.

Deployment without a repository in the web root

The problem is only solved sustainably once the repository does not exist on the target system at all. As long as git pull is the deployment mechanism, the complete project history sits on the web server - and every future misconfiguration makes it readable again. Five building blocks bring the deployment into a state where the server rule is merely a safety net.

1. Build artefact instead of working copy. The build process produces a directory or archive containing only the files to be served - without .git, tests, fixtures or development dependencies.
2. Point the document root at the subdirectory. The web server points at public/, web/ or dist/, not at the project root. That places .env, composer.json, vendor/ and .git structurally outside the delivery - even without any blocking rule.
3. Release directories with a symlink. Every release lands in its own folder and a current symlink points at the active state. This makes rollbacks atomic and prevents half-finished states in the document root.
4. Transfer with an exclusion list. Instead of synchronising a repository on the server, the transfer runs via rsync or upload with an explicit exclusion list for .git, node_modules, .env, *.bak and archive formats.
5. No editing on the production system. No cp config.php config.php.bak, no editor sessions leaving .swp files behind. Changes originate in the repository and arrive through a release - not the other way around.

Two small files contribute disproportionately here: .dockerignore prevents .git from being copied during the image build, and export-ignore entries in .gitattributes keep test data and development tooling out of git archive exports. Both take minutes and close an entire class of mistakes.

Secrets belong outside the document root

The second half of the problem is the credentials themselves. An .env file is not dangerous because it exists but because it sits in a place a web server can serve. Four principles keep it out of reach.

The German BSI IT-Grundschutz framework anchors these requirements in module APP.3.1 Web applications and web services. Requirement A12 calls for secure configuration and explicitly for keeping security-relevant information out of error messages and responses (BSI IT-Grundschutz, APP.3.1). A14 addresses the protection of confidential data, A21 secure HTTP configuration and A22 penetration testing and review as a recurring check (BSI IT-Grundschutz, APP.3.1). These four requirements cover exactly the case described here - from configuration through delivery to regular re-testing.

If you already maintain a component list, include deployment artefacts in it. The article on the software bill of materials under the CRA describes how an inventory becomes a solid basis for vulnerability assessment - and the same inventory discipline answers the question of which files a release may contain at all.

Re-check externally after every release

One-off checks age badly. A server configuration is migrated, a CDN rule set is overwritten, a staging environment is set up and then left unhardened, a service provider restores an old .htaccess. Any of these can reopen a block without anybody noticing - because nothing visible changes in daily operation.

The re-check therefore belongs with the release and afterwards on a fixed interval. What it has to deliver is manageable but precise.

• From the outside, via the public address. A test run on the server itself bypasses CDN, load balancer and firewall - exactly the layers where rules live or are missing.
• Every host name individually. Apex domain, www, staging subdomains, old domains with redirects and, where applicable, the origin address behind the CDN.
• Content instead of status code. Check /.git/HEAD for ref:, /.env for KEY=VALUE patterns, .DS_Store for its file signature. A 200 with an error page is not a finding; a 200 with content certainly is.
• HTTP and HTTPS separately. Some blocking rules only exist in the TLS vhost while the plain-text vhost serves unchanged.
• Include directory listings. Test /backup/, /old/, /uploads/, /tmp/ and /logs/ for active directory listing.
• Evaluate response headers. Server version, X-Powered-By and framework signatures reveal the technology state and guide targeted follow-up requests.

This automates well because the check is stateless: a list of paths, a list of hosts, a comparison against the expected result. That is precisely how continuous checking works in XICTRAQ - the article on automating website audits describes the principle, and alerting via email, Slack and webhooks makes sure a newly opened file does not wait for the next quarterly report.

If you are obliged under NIS2 or the Cyber Resilience Act, plan for the evidence at the same time: a documented, recurring check is part of the required technical measures. Which deadlines and responsibilities apply is set out in the article on NIS2 registration and management responsibility. And if you also run AI features on your website, the corresponding disclosure duties are covered in the article on AI Act transparency obligations for website chatbots.

Immediate measures when credentials have already leaked

When the check produces a finding, one ground rule applies: rotate instead of delete. Every set of credentials that has ever been in a publicly retrievable file or in the history of a publicly readable repository must be treated as known - regardless of whether access can be proven. Deleting the file removes the copy, not the knowledge.

1. Close the delivery immediately. Add the server rule, remove the file, reload the configuration. This step takes minutes and stops further leakage.
2. Rotate credentials by impact. Order: deploy keys and repository tokens, database access, mail and SMTP access, payment and API keys, administration accounts. Revoke old keys explicitly instead of merely overwriting them.
3. Review access logs. Search for requests to /.git/, /.env and backup paths across the entire available period. Successful retrievals with status 200 are the relevant entries, not the 404s.
4. Look for persistence. New or changed files in the document root, unknown administration accounts, additional cron jobs, altered redirects and foreign script inclusions.
5. Assess the data. If a database dump was served, personal data is affected. That starts the clock for notifying the supervisory authority under Article 33 GDPR - 72 hours from becoming aware.
6. Clean the history, but replace the keys. Removing secrets from repository history is laborious and offers no retroactive protection. The effective step remains the exchange of the keys.
7. Document the incident. Time of discovery, affected paths, rotated credentials, check results. This documentation is the basis for notification duties and for the follow-up.

How to turn these steps into a dependable procedure is described in the website incident response plan in seven steps. If you additionally want to verify whether files in the delivery path were changed after the incident, the screenshot changelog and visual diff and the monitoring of embedded scripts provide the matching tools.

Forgotten files belong on the checklist

The figures from the internet-wide scan are uncomfortably concrete: 4.96 million servers with publicly reachable .git metadata, 252,733 of them with active credentials in the served configuration, Germany among the three most affected countries (Security Affairs, 06 Feb 2026). This is not a question of missing competence. It is a question of missing feedback: nobody sees what the web server delivers as long as nobody asks for it from the outside.

The effort for the countermeasure is out of all proportion to that. A server rule is written in ten minutes. Repointing a document root at the public/ directory is routine. Serving a build artefact instead of a working copy is a one-off pipeline change. And an automated re-check after every release costs no attention as long as it finds nothing.

What remains is habit. Website security work rarely fails for lack of knowledge; it fails because checks happen once and configurations keep moving afterwards. The classics from the website security checklist and the risk categories of the OWASP Top 10:2025 help with classification - but both only become effective once the comparison between intent and reality runs regularly.

A good next step is unspectacular: open https://your-domain.com/.git/HEAD. Then /.env. Then the same paths on every subdomain you operate. If everything answers with 404, you have invested five minutes. If not, you have made the most important finding of the quarter. The security scan then takes over that check permanently, the live demo shows the result without signing up, and the plan overview shows from which scope continuous checking is included.