GitLab Public Repositories Secrets Study 2025: How 17,000+ Live Credentials Surfaced in 5.6 Million Public Projects

In November 2025, security engineer Luke Marshall published research, through Truffle Security's Research CFP programme, showing that public GitLab repositories were leaking credentials on a large scale. He scanned about 5.6 million public GitLab Cloud repositories with the open-source TruffleHog scanner and found 17,430 verified live secrets, spread across 2,804 unique domains. Google Cloud Platform credentials were the most common type, followed by MongoDB keys, Telegram bot tokens and OpenAI keys, and some still-valid secrets had been committed as far back as 2009. There was no attacker and no breach of GitLab itself: every secret was a non-human identity (an API key, token or service credential) that a developer had committed to a public project and never revoked. Marshall notified affected organisations, earned about $9,000 in bug bounties and, according to BleepingComputer, many organisations revoked their secrets in response. The study is a clear measure of how long leaked machine credentials stay usable when nobody owns them.

At a glance

What happened

This is a research study rather than an attack. Marshall set out to measure how many working credentials were sitting in public GitLab Cloud repositories, following an earlier scan of Bitbucket Cloud that Truffle Security published on 20 November 2025.

He started with enumeration. According to his write-up, "GitLab exposes a public API endpoint (https://gitlab.com/api/v4/projects) that can be used to retrieve the list of repositories by sequentially paginating through results." Each repository was then queued in AWS Simple Queue Service and picked up by an AWS Lambda function that scanned it with TruffleHog. The scanner was run with flags including --only-verified, which means a finding is only counted when TruffleHog can confirm with the provider that the credential still works. Marshall says the setup "set me back about $770 USD, but it let me scan 5,600,000 repositories in about 24 hours." Techzine reports that the scan ran with a concurrency of a thousand processes.

The result was 17,430 verified live secrets. Marshall compares this with his Bitbucket study, which found 6,212 verified secrets in about 2.6 million repositories, and says GitLab showed "a ~35% higher density of leaked secrets per repository". BleepingComputer reports that the largest group, "over 5,200 of them", were Google Cloud Platform credentials, followed by MongoDB keys, Telegram bot tokens and OpenAI keys. Marshall writes that "About 1 in 1,060 repos contained a set of valid GCP credentials". He also found 406 valid GitLab tokens inside GitLab repositories, against only 16 on Bitbucket, and describes the pattern as platform locality: "Secrets tend to leak where they live".

Age was the other striking finding. "The earliest commit timestamp for a valid secret is 2009-12-16!", Marshall writes. BleepingComputer reports that most leaked secrets are newer than 2018. Marshall notes that Bitbucket's exposure "has effectively plateaued since 2018", while "GitLab experienced an explosive surge during the same period."

Finding the owners was harder than finding the secrets. Marshall says the aim was "relating the secret to an organization rather than just relating the committer to an organization", using metadata that TruffleHog extracts from the credential itself. He used "an LLM capable of performing web searches (Claude Sonnet 3.7)" to identify the best disclosure route for each organisation and "a simple Python script" to generate disclosure emails. He reports disclosing to more than 120 organisations and contacting more than 30 SaaS providers directly.

The most valuable single finding illustrates the identity problem well. Marshall describes a Slack token "committed by a @hotmail.com address to a public GitLab repo" that turned out to belong to an organisation's Slack workspace, which used Okta for sign-in. The finding "was accepted as a P1 and paid $2100."

Timeline

How it happened: the identity attack path

1. Credentials hardcoded in code and config. Developers committed cloud keys, database credentials, bot tokens and API keys into repositories, often alongside the code that used them.
2. Repositories made public. Once a project is public, every commit in its history is readable, including files and lines that were later deleted.
3. Discovery at scale is cheap. A public API listed every project, and a serverless pipeline scanned all of them in a day for about $770. Anyone with the same skills could do the same.
4. Verification separates live from dead. TruffleHog checked each candidate against the provider, so every one of the 17,430 findings was a working credential at scan time.
5. No expiry, no owner. Keys committed more than 15 years earlier still worked. Nobody had rotated or revoked them, which suggests nobody knew they existed.
6. Personal identities leaking corporate access. The $2,100 Slack token was committed from a personal email address but unlocked a company workspace, so the organisation had no line of sight to where its credential had gone.

Impact

• Scale: 17,430 verified live secrets across 2,804 unique domains in about 5.6 million repositories, according to Marshall and BleepingComputer.
• Secret types: over 5,200 GCP credentials according to BleepingComputer, then MongoDB keys, Telegram bot tokens and OpenAI keys; 406 valid GitLab tokens according to Marshall.
• Remediation: more than 120 organisations notified and more than 30 SaaS providers contacted. BleepingComputer reports that many organisations revoked their secrets, but "an undisclosed number of secrets continue to be exposed on GitLab."
• Bounties: about $9,000 in total, including $2,100 for the Slack token.
• Misuse: none of the sources reports that any of these secrets was used maliciously. That is not evidence that none was; public secrets can be found by anyone.

What this means for NHI governance

Every item in this study is a non-human identity. A GCP service account key, a MongoDB connection string, an OpenAI key and a Slack token each grant access to data or compute without a person signing in. Unlike a human account, none of them has MFA, most have no expiry and many have no named owner. When one leaks into a public repository, whoever finds it becomes that identity.

The age of the findings is the governance lesson. A credential from 2009 still working in 2025 means nobody inventoried it, rotated it or noticed it was public for more than 15 years. Marshall's own conclusion is that secrets "must be rotated" because they "do not simply expire on their own". Deleting a file or making a later commit does nothing: the credential stays in Git history until it is revoked at the provider. Our guide to the secret sprawl challenge explains why these credentials spread faster than teams can track them.

The study also shows how thin the line is between research and attack. The same public API and the same open-source scanner are available to anyone, and the cost was a few hundred dollars. The Slack case adds a human element: a developer using a personal address committed a credential that opened a corporate workspace. Ownership has to follow the credential, not the person who happened to commit it. This pattern repeats across the misconfigured Git servers, Docker Hub images and Common Crawl training data studies.

Recommendations

• Keep secrets out of code. Store credentials in a secrets manager and inject them at runtime, as set out in our Secrets Management Guide.
• Scan before and after every push. Use pre-commit hooks and CI scanning with verification, and scan full Git history, not just the current branch, before any repository is made public.
• Revoke, then clean up. When a secret leaks, revoke or rotate it at the provider first. Rewriting history is secondary, because the credential may already have been copied.
• Give every API key an owner and an expiry. Track who issued each key, what it can reach and when it must be rotated, following the API Key Management Guide.
• Prefer short-lived credentials. Replace long-lived cloud service account keys with federated or short-lived tokens wherever the platform supports it, so a leak expires quickly.
• Watch public platforms for your own secrets. Monitor public code hosts for credentials tied to your domains, and run a clear intake route so researchers can report findings quickly.
• Control personal accounts. Discourage work on company projects from personal accounts and email addresses, so leaked credentials can be traced back to the organisation that owns them.

Frequently asked questions

How many secrets were found in public GitLab repositories?

Luke Marshall's November 2025 study found 17,430 verified live secrets across about 5.6 million public GitLab Cloud repositories, belonging to 2,804 unique domains. Google Cloud Platform credentials were the most common type.

Was GitLab hacked?

No. There was no breach of GitLab's systems. The secrets were committed by users to their own public repositories, and the researcher found them using GitLab's public API and the open-source TruffleHog scanner.

Why were secrets from 2009 still valid?

API keys and service credentials usually have no built-in expiry. Unless someone rotates or revokes them at the provider, they keep working even if the file that exposed them was later deleted from the repository.

Related NHI Mgmt Group resources

Misconfigured Git servers leaking secrets · Docker Hub images expose secrets · Secrets in a public LLM training dataset · Challenges of Rotating NHIs · The Secret Sprawl Challenge

How NHI Mgmt Group can help

Leaked keys in public repositories are non-human identities that nobody is tracking, and finding, owning and rotating them is a core NHI discipline. Our NHI Foundation Level Training Course gives teams a practical way to inventory secrets, assign ownership and cut the lifetime of every credential they issue.

References

• Truffle Security: Scanning 5.6 million public GitLab repositories for secrets (25 November 2025)
• Truffle Security: Scanning 2.6 million public Bitbucket Cloud repositories for secrets (20 November 2025)
• BleepingComputer: Public GitLab repositories exposed more than 17,000 secrets (28 November 2025)
• CyberInsider: Massive GitLab scan finds 17,000+ valid secrets in public repositories (27 November 2025)
• Open Source For You: TruffleHog's Open Source Probe Exposes Thousands Of Live GitLab Secrets (28 November 2025)
• Techzine: Large-scale GitLab scan reveals more than 17,000 leaked secrets (1 December 2025)