In February 2026, the Mysterium VPN research team published an internet-wide study that found 4,964,815 IP addresses serving publicly accessible .git directories, the hidden folders Git uses to track a project's history. According to the researchers, 252,733 of those exposures, about 5%, had deployment credentials sitting inside the .git/config file. The cause is not an exploit but a deployment habit: whole project folders, hidden files included, are copied onto live web servers that do not block them. Anyone who requests the right paths can rebuild the site's source code and, in many cases, lift the tokens and passwords that let build systems and automation accounts talk to code repositories. Those credentials are non-human identities, and once exposed they give an attacker the same access as the pipeline they belong to. The study is a figure from a single vendor with no published method, but it matches earlier attacker activity and a later independent scan.
Key takeaways
- Mysterium VPN published its study on 5 February 2026, reporting 4,964,815 IP addresses with publicly accessible .git structures. The "millions" figure refers to IP addresses, not confirmed unique organisations.
- 252,733 exposed .git/config files (about 5.09%) contained deployment credentials, according to the researchers, typically embedded in remote repository URLs.
- The United States accounted for 1,722,949 of the exposed IPs (about 34.70%), followed by Germany, France, India and Singapore.
- The credentials at risk are machine identities: basic authentication in URLs, reused CI/CD automation accounts and access tokens that were never rotated.
- Attackers already farm this mistake at scale: Sysdig's 2024 EMERALDWHALE research described more than 15,000 cloud credentials stolen from exposed Git configuration files, and Intruder found 28,000 exposed repositories in August 2026.
At a glance
| Researchers | Mysterium VPN research team (study written up by Gintarė Mažonaitė) |
|---|---|
| Disclosed | 5 February 2026; covered by Security Affairs on 6 February and SC Media and GBHackers on 9 February 2026 |
| Affected | Operators of web servers worldwide that serve the .git directory; 4,964,815 IP addresses according to the study |
| Attacker | No specific attacker named in the study; prior campaigns such as EMERALDWHALE show criminals scanning for the same files |
| Entry point | Publicly readable .git paths such as /.git/HEAD, /.git/config and /.git/index on production web servers |
| Identities exposed | Deployment credentials in .git/config remote URLs: embedded basic authentication, CI/CD automation accounts, long-lived access tokens |
| Impact | Source code reconstruction for exposed sites; 252,733 .git/config files with deployment credentials, according to the researchers |
| Category | NHI (deployment tokens, automation accounts, secrets sprawl); research / exposure study |
What happened
On 5 February 2026, Mysterium VPN published the results of what it called "a 2026 internet-wide data study" of web servers exposing Git metadata. The study counted 4,964,815 IP addresses with publicly accessible .git structures. It did not publish its scan dates, tooling or verification method, so the figures should be read as the researchers' own counts rather than independently verified numbers.
A .git folder holds everything Git needs to rebuild a project: its commit history, the index of tracked files and the configuration that points at remote repositories. It is meant to stay on developer machines and build servers. When it is copied to a public web root, it becomes readable by anyone. The researchers write that attackers "can request a handful of well-known paths, like /.git/HEAD, /.git/config, and /.git/index, which act as a roadmap to how the website is structured and configured," and can then reconstruct the website's content with widely available tools.
The more serious finding concerns one file. According to the study, .git/config "stores repository configuration values, including remote definitions", and credentials often end up inside those remote URLs. The researchers list three common patterns: basic authentication embedded in a URL, automation accounts created for CI/CD that are reused across environments, and temporary access tokens that were meant to be rotated but were not. They counted 252,733 cases where deployment credentials were present in .git/config, which they describe as the difference between "exposed metadata" and "direct unauthorized access."
The exposure was concentrated in large hosting markets. The United States led with 1,722,949 IPs, about 34.70% of the total, followed by Germany (419,102), France (237,593), India (218,661), Singapore (189,900), the Netherlands (165,174), Japan (164,768), Russia (147,859), the United Kingdom (140,341) and Hong Kong (127,223).
Mysterium VPN gives four reasons the mistake keeps recurring: entire project folders are uploaded to live sites, packaging tools include hidden folders, protection is applied to the main site address but not to alternate routes such as the raw server IP or another domain, and many web servers do not block hidden folders by default. Security Affairs, SC Media and GBHackers reported the study in the following days, repeating the headline figures.
The problem is not new, and it is actively exploited. In October 2024, Sysdig described EMERALDWHALE, an operation that scanned for exposed /.git/config files with tools such as httpx, discovered 67,000 exposed URLs and stole more than 15,000 cloud service credentials. TechRadar reported that lists of exposed Git config URLs were selling for about $100 on Telegram. In August 2026, Intruder published a separate scan of 3.5 million hosts that found 28,000 exposed repositories and recovered more than 400 AWS access keys, 107 Stripe API keys, 123 OpenAI API keys, 80 Telegram tokens and 17 GitHub personal access tokens, noting that "many of the credentials we extracted were still active at the time of testing."
Timeline
| Date | Event |
|---|---|
| 30 October 2024 | Sysdig publishes EMERALDWHALE research: more than 15,000 cloud credentials stolen via exposed Git configuration files. |
| 5 February 2026 | Mysterium VPN publishes its study: 4,964,815 IPs with exposed .git structures and 252,733 .git/config files with deployment credentials. |
| 6 February 2026 | Security Affairs reports the study. |
| 9 February 2026 | SC Media and GBHackers report the findings, including the country breakdown. |
| 20 August 2026 | Intruder publishes an independent scan finding 28,000 exposed .git repositories with live AWS, Stripe, OpenAI and GitHub credentials. |
| 28 August 2026 | eSecurity Planet reports Intruder's findings. |
How it happened: the identity attack path
- Machine credentials written into Git configuration. A deployment process clones a repository using a URL that carries a username and password or a token. Git stores that URL, credentials included, in .git/config.
- Repository metadata shipped to production. The project folder, hidden .git directory and all, is copied to the web root, either by hand or by a packaging tool that includes hidden files.
- Web server serves hidden paths. The server does not deny requests for /.git/, or the block covers only the main hostname while the raw IP or another domain stays open.
- Mass discovery. Scanners request /.git/config and /.git/HEAD across large IP ranges. Sysdig documented attackers doing exactly this with httpx and selling the resulting URL lists.
- Credentials harvested, code rebuilt. The attacker reads remote URLs for embedded secrets and uses dumping tools to rebuild the source code, which can contain further hard-coded keys in its history.
- Access as the pipeline. A working deployment token lets the attacker read or push to private repositories, or use cloud keys found alongside it, with the privileges of the automation account rather than a person.
Impact
- Scale: 4,964,815 exposed IP addresses and 252,733 .git/config files with deployment credentials, according to Mysterium VPN. The researchers did not report how many of those credentials were valid.
- Geography: the United States accounted for about 34.70% of exposed IPs; the United Kingdom accounted for 140,341.
- Consequences named by the researchers: source code theft, credential abuse, supply chain attacks through stolen repository access, infrastructure mapping and lateral movement into cloud and third-party services, as summarised by Security Affairs.
- Evidence of real abuse: Sysdig's EMERALDWHALE research and Intruder's 2026 scan show exposed Git data yielding working cloud, payment, AI platform and GitHub credentials. Intruder reports that one AWS key opened a bucket of internal employment documents, including attendance records and disciplinary files.
What this means for NHI governance
Exposed .git directories are a secrets sprawl problem in its plainest form. The credential in a remote URL was created for a machine, used by a machine and then forgotten on a machine. Nobody owns it, it is rarely rotated, and nothing alerts when a stranger downloads the file that holds it. The study's own list of causes, reused CI/CD automation accounts and tokens "meant to be rotated but weren't", is a description of non-human identities without lifecycle management.
The figures also show why static secrets do not stay where they are put. A token pasted into a clone command ends up in configuration, configuration ends up in a deployment artefact, and the artefact ends up on the internet. Each copy is an unmanaged instance of the same identity. Scanning code before commit helps, but it would not have caught a credential that Git wrote into its own configuration during deployment.
The treatment is the same as for any leaked non-human identity: assume compromise, revoke and reissue, and then ask what that credential could reach. A deployment account with write access to a private repository is a supply chain foothold, not just a data leak. The EMERALDWHALE operation showed criminals will industrialise this; Intruder's warning that autonomous agents shorten "the window between exposure and compromise" suggests the time available to fix it is shrinking.
Recommendations
- Block .git at the edge. Deny all requests to /.git/ paths in the web server, reverse proxy or CDN, and test the raw IP and every alternate hostname, not just the main domain.
- Deploy build artefacts, not working copies. Ship only the files the site needs, and exclude .git and other hidden folders from packaging and sync jobs.
- Keep credentials out of remote URLs. Use a credential helper, short-lived deploy tokens or federated identity instead of passwords or tokens embedded in clone URLs. The Secrets Management Guide covers centralising and shortening secrets.
- Treat any exposed .git/config credential as compromised. Revoke and rotate it, then review repository and cloud logs for use by unknown sources. Challenges of Rotating NHIs explains why this needs planning at scale.
- Give every automation account one owner and one purpose. Stop reusing CI/CD accounts across environments, scope them to the repositories they need and retire them with the pipeline, following the NHI Lifecycle Management Guide.
- Scan your own estate from the outside. Check your public hosts for readable /.git/HEAD and /.git/config, and alert on requests for those paths.
- Scan full history for secrets. Credentials removed from the latest commit remain in history, so scan the whole repository, as covered in our look at the secret sprawl challenge.
Frequently asked questions
Are millions of Git servers really leaking secrets?
Mysterium VPN's February 2026 study counted 4,964,815 IP addresses exposing .git metadata, so the "millions" figure refers to exposed Git data, not leaked secrets. Of those, the researchers found deployment credentials in 252,733 .git/config files, about 5%. The study's method has not been published.
Why is an exposed .git folder dangerous?
It lets anyone rebuild the website's source code and read its Git configuration. If the configuration contains a remote URL with a password or token, the attacker gains the access of the deployment account, which can include private repositories and connected cloud services.
How do I check whether my site exposes its .git directory?
Request paths such as /.git/HEAD and /.git/config on your domains and on the server's raw IP address. If they return content, block access at the web server or CDN, remove the folder from production and rotate any credentials it contained.
Related NHI Mgmt Group resources
EMERALDWHALE breach · 17,000 secrets in public GitLab repositories · Docker Hub leak: 10,000+ images expose secrets · The secret sprawl challenge · Secrets Management Guide
How NHI Mgmt Group can help
Deployment tokens, CI/CD automation accounts and API keys left in configuration files are non-human identities that nobody is watching until an attacker finds them. Our NHI Foundation Level Training Course teaches teams how to discover, own, rotate and retire these identities before they leak.
References
- Mysterium VPN: Nearly 5 Million Web Servers Found Exposing Git Metadata, Study Reveals Widespread Risk of Code and Credential Leaks (5 February 2026)
- Security Affairs: Nearly 5 Million Web Servers Found Exposing Git Metadata (6 February 2026)
- SC Media: Millions of servers expose Git metadata, thousands leak credentials (9 February 2026)
- GBHackers: Over 5 Million Misconfigured Git Web Servers Found Exposing Secrets Online (9 February 2026)
- Sysdig: EMERALDWHALE, 15k cloud credentials stolen in operation targeting exposed Git config files (30 October 2024)
- TechRadar: Thousands of cloud credentials stolen from exposed Git config files (31 October 2024)
- Intruder: API keys, bank details, disciplinary files: what 28,000 exposed git repos gave up (20 August 2026, updated 21 August 2026)
- eSecurity Planet: 28,000 Exposed Git Repositories Leak Credentials (28 August 2026)