28,000 Git Repositories Exposed API Keys, Bank Details

Key Takeaways

• A widespread oversight in development practices has led to the exposure of approximately 28,000 Git repositories.
• These exposed repositories contain highly sensitive data, including API keys for major platforms (AWS, Stripe, OpenAI, Telegram, GitHub), bank details, and confidential employee disciplinary records.
• The vulnerability stems from publicly accessible `.git` directories on web servers, allowing automated tools to reconstruct repository history and retrieve sensitive information, even if it was “removed” in later commits.
• This exposure presents a severe risk for data theft, financial fraud, sophisticated phishing attacks, and unauthorized system access.
• Immediate action is required to secure these repositories, rotate all compromised credentials, and implement robust secret management practices.

A significant lapse in software development security has left thousands of software repositories vulnerable, according to new research. Investigators have identified 28,000 publicly accessible Git repositories containing critical credentials, sensitive financial data, and private internal employee documents. This exposure could grant malicious actors unfettered access to cloud infrastructure and proprietary business systems.

This situation differs from a traditional malware attack. The core issue arises when web servers inadvertently expose their hidden Git directories. This oversight enables automated scanning tools to download codebases and retrieve previous file versions, revealing historical data that developers might believe has been deleted.

Any secret inadvertently committed and subsequently leaked can be exploited for a range of illicit activities, including data exfiltration, payment fraud, advanced phishing campaigns, or the injection of malicious code. Security analysts at Intruder uncovered this widespread exposure during a broad-scale examination of internet-facing systems.

In a detailed report, Intruder revealed that their analysis, which involved scanning 3.5 million live hosts, highlighted a persistent vulnerability where credentials, once committed, can remain accessible long after a developer attempts to remove them. The findings corroborate earlier reports concerning publicly exposed AWS credentials that remained active for years post-exposure.

The danger presented by these exposed Git repositories is particularly extensive because Git’s version control history can retain sensitive information—such as secrets, configuration data, and internal documents—across deleted branches and past commits. This means that even if a secret is removed from the latest version of a project, its presence in earlier commits within the repository’s history can still be exploited.

28,000 Exposed Git Repositories

The research methodology began with identifying approximately 40 million potential targets derived from Certificate Transparency data. This initial set was then refined to hosts operating an HTTP service, which were subsequently scanned for exposed Git repositories. To efficiently inspect repository history without downloading entire projects, the researchers developed a specialized tool named gitreaper.

The significance of Git’s history cannot be overstated. Simply deleting a password or API key from the most recent version of a project does not erase its presence from earlier commits. Git metadata, branch pointers, and commit logs can guide an attacker to this legacy content, a vulnerability previously observed in the CISA public GitHub exposure, which involved cloud credentials and infrastructure code.

The comprehensive scan successfully retrieved over 400 AWS access keys, 107 Stripe API keys, 123 OpenAI API keys, 80 Telegram tokens, and 17 GitHub personal access tokens. Intruder’s testing confirmed that some of these credentials remained active, indicating a direct pathway for unauthorized access into the linked environments.

One specific hardcoded AWS key provided access to an Amazon S3 bucket containing confidential employee documents, including attendance records and disciplinary files. Such sensitive internal data can be leveraged by attackers to craft highly credible fraudulent communications, target specific employees, or extort organizations through threats of public disclosure.

Separately, another key, embedded within a configuration file, exposed a payment service’s payout and transaction history. This accessible data included crucial revenue figures, detailed payout schedules, and partial bank account information. Depending on the associated permissions, a valid payment key could be misused to issue unauthorized refunds, view sensitive customer details, or even redirect legitimate payouts to attacker-controlled accounts.

Old Commits Turn Small Errors Into Incidents

This report underscores the critical importance of treating exposed Git directories as severe security incidents, rather than minor web server misconfigurations. The threat landscape has evolved, with attackers increasingly employing automated tools to discover exposed secrets. Previous research has demonstrated that automated credential-hunting bots can locate publicly disclosed AWS credentials within minutes of their exposure.

What You Should Do

• Immediately Restrict Access: Remove public access to all `.git` directories on web servers. Implement server configurations to deny access to these paths.
• Assess and Rotate All Credentials: Conduct a thorough review of all current and historical commits within any potentially exposed repositories. Rotate every credential found, including API keys, tokens, and passwords, assuming they are compromised. Revoking only the most recent or visible key is insufficient if older versions are still exposed.
• Implement Secret Management: Migrate all sensitive data, such as API keys and credentials, into dedicated secret management vaults or environment-based systems. Avoid hardcoding secrets directly into code or configuration files.
• Review Logs for Suspicious Activity: Scrutinize cloud activity logs and payment service transaction histories for any signs of unauthorized access or suspicious usage associated with the exposed credentials.
• Enforce Principle of Least Privilege: Ensure that all credentials are configured with the minimum necessary permissions required for their intended function, limiting the potential impact of a compromise.
• Integrate Secret Scanning into CI/CD: Implement automated secret scanning tools within your Continuous Integration/Continuous Deployment (CI/CD) pipelines. Configure these tools to detect and block commits containing sensitive information before they reach production.
• Regularly Audit Configuration Files: Perform routine checks for exposed environment configuration files (e.g., `.env`) that could inadvertently reveal cloud account access details.
• Clean Repository History (Cautiously): While cleaning repository history to remove sensitive data is possible, it is a complex process. Assume that any previously public secret has been copied by attackers and proceed with credential rotation regardless of history cleaning efforts.
• Educate Development Teams: Provide ongoing training to developers on secure coding practices, proper secret management, and the risks associated with exposing Git repositories.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.