Truffle Security rapporterar att man hittade 543 699 unika inloggningsuppgifter i publika GitHub-repositorier som fortfarande autentiserade när de testades den 27 och 28 juli 2026 [1]. BleepingComputer rapporterade fynden den 30 september 2026 [2]. De räknade inloggningsuppgifterna omfattar molnnycklar, anslutningssträngar till databaser och nycklar till AI-tjänster [1].
Bakgrund
GitHub slog på push protection för alla användare i februari 2024, ett skydd som inte täcker alla format för inloggningsuppgifter [1] [2]. Truffle Securitys analys ställer en annan fråga än en genomsökning av nya commits: vilka inloggningsuppgifter i ett befintligt publikt material som fortfarande lever, och hur länge de förblev publika [1].
Resultat
Materialet bestod av 224 553 295 repositorier och 58 467 468 698 filer från datamängden The Stack v3. Truffle Security testade varje kandidat bland inloggningsuppgifter mot tjänsten som utfärdat den, och nyckelade inloggningsuppgifterna efter värde, så att en nyckel som hittades i 62 repositorier räknas en gång [1]. Genomsökningen omfattade bara standardgrenen och avslutades den 7 augusti 2025 [1].
Medianåldern för en levande inloggningsuppgift i ett publikt repositorium var 784 dagar, och den 90:e percentilen var 6,3 år; den äldsta committades 2009 och fungerar fortfarande [1]. Bland de levande inloggningsuppgifterna uppgick Google Cloud-servicekonton till 69 041, Google API-nycklar till 33 343 och Gemini-nycklar till 31 374, och 51 067 anslutningssträngar till MongoDB fanns i en kategori som push protection inte blockerar [1].
Överlevnaden skilde sig mellan leverantörer. Av 101 886 committade npm-tokens var 1 fortfarande levande, och av 73 048 committade GitHub-tokens var 260 det; för anslutningssträngar till Postgres var 11 465 av 12 985 levande, eller 88 procent [1]. Truffle Securitys slutsats är att det som skiljer dem åt är om leverantören har en process som tar en läckt token och dödar den [1].
Om push protection anger rapporten att strax under 200 000 av de levande inloggningsuppgifterna pushades efter att det slagits på som standard, att 51,8 procent av de levande inloggningsuppgifterna ligger i kategorier som det inte känner igen, och att den skyddade gruppen minskade med 53 procent medan den oskyddade gruppen minskade med 7 procent [1] [2].
Följder för Mac-användare
Datan beskriver repositorier, inte datorer, och källorna anger inte vilka operativsystem utvecklarna använde. Relevansen för en Mac-användare är inloggningsuppgiften: en nyckel som ligger i ett publikt repositorium kan användas varifrån som helst, oavsett vilken enhet som skapade den. Antalet Gemini-nycklar är ett exempel på att nycklar till AI-tjänster förekommer i samma data som molnnycklar [1].
Metodiken sätter också gränser för vad siffrorna visar. Allt som force-pushats bort, flyttats till en annan gren än standardgrenen, eller committats och återställts före augusti 2025 är osynligt för metoden, så siffran är en räkning av det som hittades, inte av allt som exponerats [1].
Rekommendationer
- Behandla en committad inloggningsuppgift som bränd i samma stund den hamnar där, oavsett om något flaggade den, och rotera först och städa historiken sedan, som rapporten rekommenderar [1].
- Rotera varje nyckel som någonsin committats, även i gamla grenar och i repositorier som senare gjorts privata, eftersom den levande medianuppgiften hade varit publik i 784 dagar [1].
- Föredra inloggningsuppgifter som går ut automatiskt; BleepingComputers sammanfattning listar automatiskt utgående för aktiva hemligheter bland åtgärderna [2].
- Förvara nycklar i ett hemlighetsvalv eller i miljövariabler utanför repositoriet, och sök igenom ett repositoriums historik innan det görs publikt.
Relevans för FireAI
FireAI är en brandvägg för en enda Mac. Den identifierar en app via dess kodsignatur eller sökväg och tillämpar regler per app på de anslutningar appen öppnar, och sidan Aktivitet listar vilka appar som gått online och vart. Det hjälper en användare att se vilka program på Macen som anropar en moln- eller AI-tjänst, och att skriva en regel så att bara den avsedda appen når den.
FireAI söker inte igenom repositorier eller filer efter inloggningsuppgifter, ser inte vad en förfrågan innehåller inne i en krypterad anslutning och har ingen insyn i en nyckel som används från en annan dator. Den kan inte återkalla eller rotera en nyckel och kan inte ta bort en inloggningsuppgift som redan publicerats. Att återkalla nyckeln hos dess leverantör är den kontroll som gäller för fynden i den här rapporten.
Begränsningar
Siffrorna kommer från Truffle Securitys egen metodik och datamängd. De två källorna beskriver åldersfördelningen med olika ord: BleepingComputer anger att ungefär en tiondel av de fungerande inloggningsuppgifterna är äldre än 6,3 år, och Truffle Security anger en 90:e percentil på 6,3 år [1] [2]. Datumet då en fil committades är den enda klocka per fil som materialet erbjuder, så åldrarna är approximativa [1].
Datamängdens genomsökning avslutades i augusti 2025 medan giltighetstesterna kördes i juli 2026, så vissa inloggningsuppgifter i räkningen var exponerade i flera år före testet, och rapporten kan inte säga vem, om någon, som använde dem [1].
Prova FireAI från HisnLabs gratis i 17 dagar.