GitHub Code Held 543,699 Working Keys and Passwords and the Oldest Dates Back to 2009

543,699 keys and passwords sat in public GitHub code and still worked when researchers tested them in July 2026. The oldest went back to 2009. 51.8 percent were types GitHub’s default protection does not block.

Researchers at Truffle Security went through 224 million public GitHub repositories. For each API key, cloud key, database password and token they found in the code, they asked the service that issued it if it still let them in. They did that on 27 and 28 July 2026, and 543,699 of them still worked.

An API key or a database connection string is a login. It is a long line of characters that a program sends to a service to prove it is allowed in, and whoever has that line has the access. Put it in a file and push the file to a public repository, and that login is public. In the researchers’ words: “A leaked key that still authenticates is access.”

The median key had been sitting in public for at least 784 days. A quarter of them were older than four years, and one in ten was older than 6.3 years. The oldest was last touched on 13 June 2009. It is a database login in the config file of an Erlang web server, and it still worked in July 2026, 17 years later.

Next in line came an FTP login in the C source code of a GPS logger, from September 2009. That one was copied into 62 repositories. A developer forks a project or copies a folder into their own repository, and the password goes along with the code. The researchers counted each key once, however often it turned up, and the 543,699 keys sat in 1,103,438 places in total.

And that number is the low end. The researchers scanned The Stack v3, a snapshot of 224 million public repositories that Hugging Face put together to train AI models, collected up to 7 August 2025. It holds the default branch of each repository, the main one, as it stood on that day, without the history behind it. As the report puts it: “Anything that was force pushed away, moved to a non-default branch, or committed and reverted before August 2025 is invisible to this method.”

If you once took a key out of a file and moved on, it is still in your history. Git keeps the earlier versions of your files, so the commit that held the key is still there after you remove the line in a new commit.

GitHub’s own documentation goes further. Even after you rewrite the history, the old commits can still be reached in clones and forks, through pull requests that point to them, and on GitHub itself through the commit’s ID, in what GitHub calls cached views. Its first instruction is to replace the key: “as a first step you need to revoke and/or rotate that secret.”

What still let the researchers in, by type:

• → 69,041 Google Cloud service account keys
• → 51,067 MongoDB database logins
• → 33,343 Google API keys
• → 11,465 Postgres database logins, 88 percent of those found
• → 9,189 SendGrid email keys, out of 22,800
• → 6,819 AWS access keys, out of 82,411

At some services almost nothing survived. Of 73,048 GitHub tokens in public code, 260 still worked. Of 30,437 Hugging Face tokens, 15. Against that stands Google Cloud with 69,041 working keys out of 126,963.

The report explains the gap in one line: “Detection without revocation leaves the key working.” GitHub scans public code for tokens from services in its partner program and sends what it finds to that service. What happens next is up to the service. Where the service switches the key off, it stops working. Where it does not, the key can keep working for years, as an AWS key from November 2009 did.

Google does switch keys off. Since 16 June 2024, it disables service account keys, the keys a program uses to log in to Google Cloud without a person behind it, when it finds them in public repositories on GitHub and GitLab. That is on by default, also for existing customers who made no other choice.

It is a setting, and a company can switch it to WAIT_FOR_ABUSE, which leaves a leaked key on until it is used in a way that harms the platform, and even then Google only might switch it off. And still 54 percent of those keys in the report worked in July 2026.

Two things in Google’s own documentation fit. Keys that leaked between 16 January and 16 June 2024, before the setting existed, were never disabled automatically. And Google writes that it “doesn’t guarantee that it will detect exposed keys.” For newer leaks the picture is different: of these keys that leaked in 2025, 8 percent still worked.

AWS reacts fast and still leaves the key active. In a test that Unit 42 researchers published in September 2026, a key that showed up in a public GitHub repository got a quarantine policy within 10 seconds. That policy blocks certain risky actions. They write: “AWS purposefully denies specific actions rather than completely disabling the compromised access key or user password.” The key itself stays active.

GitHub did build something to stop new leaks. Since 29 February 2024, push protection is on by default for pushes to public repositories: when you push a key it recognizes by its pattern, the push is blocked. You can still push it anyway, “if you deem the secret safe.” Where it applies, it works. Across the rollout, the types it blocks fell by 53 percent, and the other types by 7 percent.

Even so, 199,843 of the working keys leaked after GitHub switched it on. And 51.8 percent of all working keys are of a type a public repository accepts by default, with database connection strings and Google API keys in that group.

A Maps key and a Gemini key start with the same characters, AIzaSy. The first is meant to sit inside a web page so the map can load. The second opens Google’s AI and is, as the researchers write, “a billable credential attached to a model endpoint,” so the bill goes to the owner, whoever uses the key. “One pattern cannot tell those apart, so nothing gets blocked.”

In February 2026 the researchers showed it can be one and the same key: when you switch on the Gemini API in a Google Cloud project, the existing keys in that project can silently gain access to it. They found 2,863 of those keys on public websites, Google’s own among them. In the GitHub code, the researchers found 31,374 working Gemini keys, with a median leak date of February 2025, a year after push protection was switched on.

All 543,699 keys are also in a download. The dataset comes in two versions. In the one meant for training, a detection model replaced emails, keys, names, passwords and IP addresses with placeholders. The full version, 224 million repositories, sits in a public storage bucket, and its own page says the files “are not PII-redacted. They are the raw file contents as crawled from GitHub and may contain emails, credentials, API keys, and other personal data that was public on GitHub.” PII means personal information.

The researchers had found this in AI training data before. In June 2026 they scanned 7.6 petabytes of Hugging Face training data and found 221,303 working keys in 6,003 datasets.

If you have ever pushed code with a key in it:

• → Switch the key off or replace it with a new one first (revoke or rotate), and clean up the history second. The researchers’ advice is to treat a committed key as burned the moment it lands, whether or not anything flagged it.
• → Scan your own history instead of trusting the block at push time. Push protection was not on by default for anything you committed before February 2024.
• → Use keys that expire. The report says that “most of what we found would have aged out harmlessly if it had ever been given a lifetime.”
• → On Google Cloud, check that the organization policy iam.serviceAccountKeyExposureResponse is set to DISABLE_KEY.
• → Look up your repositories on the “Am I in The Stack?” page and ask for removal there. Repositories that opt out are left out of the next release. A key in a copy that was already downloaded still has to be replaced.
• → Run TruffleHog on your own repositories. It is free and open source, knows more than 800 types of secrets, and with --results=verified it only shows the keys it confirmed still work by testing them against the service.

1
2

trufflehog git https://github.com/YOUR-USER/YOUR-REPO --results=verified
trufflehog github --org=YOUR-ORG --results=verified

For deleted and hidden commits on GitHub, TruffleHog has an experimental mode. It is an alpha feature, and finding the commits takes between 20 minutes and a few hours:

1

trufflehog github-experimental --repo https://github.com/YOUR-USER/YOUR-REPO.git --object-discovery

In my course you keep API keys in environment variables, outside your code, and learn to find exposed config files with Google dorks. My Ethical Hacking Complete Course Zero to Expert takes you there step by step: reconnaissance, scanning, exploitation and traffic analysis, hands-on, from your first day with no Linux or hacking background.

→ Join my complete ethical hacking course

Hacking is not a hobby but a way of life.

Sources:

Truffle Security | Google Cloud | Hugging Face