Truffle Security reports that it found 543,699 unique credentials in public GitHub repositories that still authenticated when it tested them on 27 and 28 July 2026 [1]. BleepingComputer reported the findings on 30 September 2026 [2]. The credentials counted include cloud keys, database connection strings and AI service keys [1].
Background
GitHub turned on push protection for all users in February 2024, a protection that does not cover every credential format [1] [2]. Truffle Security's analysis asks a different question from a scan of new commits: which credentials in an existing public corpus are still alive, and how long they stayed public [1].
Findings
The corpus was 224,553,295 repositories and 58,467,468,698 files from The Stack v3 dataset. Truffle Security tested each candidate credential against the service that issued it, and keyed credentials by value, so one key found in 62 repositories counts once [1]. The crawl covered the default branch only and closed on 7 August 2025 [1].
The median age of a live credential in a public repository was 784 days, and the 90th percentile was 6.3 years; the oldest was committed in 2009 and still works [1]. Among the live credentials, Google Cloud service accounts numbered 69,041, Google API keys 33,343 and Gemini keys 31,374, and 51,067 MongoDB connection strings were in a category that push protection does not block [1].
Survival differed by provider. Of 101,886 committed npm tokens, 1 was still live, and of 73,048 committed GitHub tokens, 260 were; for Postgres connection strings, 11,465 of 12,985 were live, or 88 percent [1]. Truffle Security's conclusion is that what separates them is whether the provider has a pipeline that takes a leaked token and kills it [1].
On push protection, the report states that just under 200,000 of the live credentials were pushed after it was turned on by default, that 51.8 percent of the live credentials fall in categories it does not recognise, and that the protected group fell 53 percent while the unprotected group fell 7 percent [1] [2].
Implications for Mac users
The data describes repositories, not computers, and the sources do not say which operating systems the developers used. The relevance for a Mac user is the credential: a key that sits in a public repository can be used from anywhere, whatever device created it. The Gemini key count is an example of AI service keys appearing in the same data as cloud keys [1].
The methodology also bounds what the numbers show. Anything that was force pushed away, moved to a non-default branch, or committed and reverted before August 2025 is invisible to the method, so the figure is a count of what was found, not of everything exposed [1].
Recommendations
- Treat a committed credential as burned the moment it lands, whether or not anything flagged it, and rotate first and clean up the history second, as the report advises [1].
- Rotate any key that was ever committed, including in old branches and in repositories later made private, since the median live credential had been public for 784 days [1].
- Prefer credentials that expire automatically; the BleepingComputer summary lists automatic expiration for active secrets among the measures [2].
- Keep keys in a secrets store or in environment variables outside the repository, and scan the history of a repository before making it public.
Relevance to FireAI
FireAI is a firewall for one Mac. It identifies an app by its code signature or path and applies per-app rules to the connections that app opens, and the Activity page lists which apps went online and where. That helps a user see which programs on the Mac call a cloud or AI service, and write a rule so that only the intended app reaches it.
FireAI does not scan repositories or files for credentials, does not see what a request contains inside an encrypted connection, and has no view of a key used from another computer. It cannot revoke or rotate a key, and it cannot remove a credential that was already published. Revoking the key with its provider is the control that applies to the findings in this report.
Limitations
The figures come from Truffle Security's own methodology and dataset. The two sources describe the age distribution in different words: BleepingComputer states it as about a tenth of the working credentials being older than 6.3 years, and Truffle Security as a 90th percentile of 6.3 years [1] [2]. The date a file was committed is the only per-file clock the corpus offers, so ages are approximate [1].
The dataset crawl closed in August 2025 while the validity tests ran in July 2026, so some credentials in the count were exposed for years before the test, and the report cannot say who, if anyone, used them [1].
Try FireAI, by HisnLabs free for 17 days.