28,000 Exposed .git Repositories Leak Active AWS, OpenAI, Stripe and GitHub Credentials

A large-scale internet scan has uncovered 28,000 publicly accessible .git repositories exposing credentials for AWS, OpenAI, Stripe, GitHub, and other services, illustrating how a basic web server misconfiguration can turn source code history into an immediate cloud access risk.

The research, published by attack-surface management firm Intruder, examined 3.5 million live HTTP hosts selected from a larger pool of 40 million potentially relevant subdomains.

Intruder said many of the recovered credentials remained active during validation.

The exposure occurs when a web server allows external access to a project’s .git directory.

Although visitors may see only a normal website, an exposed Git metadata folder can provide enough information for an attacker to reconstruct source code, configuration files, and historical commits.

That historical element is crucial. Developers may remove a hardcoded secret from the latest version of an application, but the credential can remain retrievable from an older commit.

Deleted branches, rewritten history and reflogs can also retain references to commits that are no longer visible in the project’s current state.

Intruder developed an open-source tool, gitreaper, to handle the collection challenge at internet scale.

Rather than cloning every exposed repository to disk, the tool walks the Git object graph in memory, retrieves commits, trees and blobs, scans each blob for secrets, and discards non-matching content. Only files that trigger a detection are retained.

The approach avoids the storage burden associated with downloading full repositories, which can range from megabytes to tens of gigabytes.

It also enables scanning beyond the repository’s HEAD state, where organizations are most likely to assume a removed secret is no longer exposed.

The AWS findings pose the greatest potential impact. Intruder reported that exposed keys included access to an S3 bucket containing internal employment records, including attendance and disciplinary information.

Intruder Researchers said that, the scan identified more than 400 AWS access keys, 107 Stripe API keys, 123 OpenAI API keys, 80 Telegram bot tokens, and 17 GitHub personal access tokens (PATs).

Such data could support targeted phishing, impersonation or broader social-engineering operations.

28,000 Exposed .git Repositories

Another AWS credential was found in a previously committed .env file and provided access to a music-hosting collection.

While less sensitive on its face, the case demonstrates how a repository leak can expose resources that developers may consider private or low-risk.

Live Stripe secret keys can create a direct financial fraud and privacy exposure.

Depending on assigned privileges, an attacker may be able to view customer information, inspect transaction and payout histories, issue refunds or potentially redirect payouts.

Intruder said one recovered key enabled access to payout schedules, transaction history, revenue figures and partial bank-account details.

GitHub PATs present a separate software supply-chain risk. A valid token with organization or repository permissions may allow an intruder to read private source code, steal proprietary material or inject malicious commits into trusted development workflows.

The findings arrive as exposed credentials gain fresh significance in autonomous-agent threat models.

In July, OpenAI and Hugging Face disclosed an evaluation-related security incident in which models identified and used publicly exposed credentials associated with four external accounts.

OpenAI said one account was used as an outbound relay and staging path, another for data storage, while two were accessed read-only.

That incident does not mean every exposed Git directory will be targeted by AI agents.

However, it reinforces a key operational reality: attackers no longer need to discover, validate and operationalize every leaked credential manually. Automated systems can compress the time between discovery and abuse.

Organizations should block public access to .git paths at the web-server and CDN layer, rotate every credential that may have entered source control, audit full Git history rather than only current branches, and adopt automated secret scanning in pre-commit, CI/CD and repository-hosting workflows.

An exposed .git directory should be handled as a potential credential compromise, not merely a configuration defect.

★ Which Security Tools Should You Cut? Score Them on One Page – Download the Inherited Security Stack Guide