GitHub meldt dat hackers toegang kregen tot 4000 interne repository's

GitHub meldt dat er gegevens van interne repository's zijn gestolen. Het lijkt te gaan om bijna 4000 privérepository's. De hackersgroepering TeamPCP biedt de gegevens op een hackersforum te koop aan.

Wat zijn secrets?

Met GitHub Secrets kunnen gebruikers gevoelige gegevens opslaan voor gebruik in GitHub Actions. Dat kunnen bijvoorbeeld api-keys, access tokens of interne wachtwoorden zijn. Normaal gesproken zijn dergelijke secrets afgeschermd, maar als hackers toegang krijgen tot een interne repository, kunnen ze soms toch worden buitgemaakt.

GitHub meldt in een post op X dat een werknemer dinsdag is gecompromitteerd door een kwaadwillige VS Code-extensie. Volgens het bedrijf zijn er daarbij zo'n 3800 interne repository's gestolen. Het lijkt er niet op dat er informatie van klanten buiten de interne repository's is gestolen. "We hebben het risico zoveel mogelijk beperkt door kritieke secrets te vervangen." Het bedrijf onderzoekt of er nog verdere maatregelen nodig zijn.

Cybercrimegroep TeamPCP meldde dinsdag op een hackersforum dat hij toegang heeft gekregen tot zo'n 4000 repository's met privécode, waaronder broncode en interne organisatiegegevens. De groep biedt de gestolen gegevens aan voor minstens 50.000 dollar. Als er geen koper wordt gevonden, worden de gegevens volgens TeamPCP gratis gepubliceerd.

Eerder dit jaar hackte TeamPCP al kwetsbaarhedenscanner Trivy, waardoor onder meer containerimages en GitHub-releases die deze tool gebruiken, risico liepen om gecompromitteerd te worden. Ook stal de groepering onlangs 'een beperkt aantal inloggegevens' van interne broncoderepository's van OpenAI.

Reacties (38)

[The Zep Man]

GitHub meldt in een post op X dat een werknemer dinsdag is gecompromitteerd door een malafide VS Code-extensie. Volgens het bedrijf zijn er daarbij zo'n 3800 interne repository's gestolen.
(...)
Het bedrijf onderzoekt of er nog verdere maatregelen nodig zijn.

Het lijkt mij dat verdere preventieve en actieve maatregelen nodig zijn, gezien een enkele succesvolle aanval op een ontwikkelomgeving data uit zoveel repositories lekt.

[Reactie gewijzigd door The Zep Man op 20 mei 2026 10:51]

[nzall]

Wat mij vooral zorgen baart is dat die gestolen repos natuurlijk een goudmijn zijn voor hackers, zeker tegenwoordig met AI. Laat daar Mythos of een lokaal equivalent een nachtje op los en je vindt gegarandeerd wel iets dat kan worden misbruikt...

[timonnl]

En dan loop je ook nog het risico dat er in deze repo's weer keys van externe systemen opgeslagen kunnen zijn waarmee weer een hoop andere gegevens buit gemaakt kunnen worden. Hier zal maar net een API key van de CRM omgeving van een klant in staan waar geen IP whitelist op ingesteld is en alle gegevens van de klanten van deze klant liggen op straat.
Never mind het zijn interne repo's waar (hopelijk) geen externe API keys in opgeslagen zijn...

[Reactie gewijzigd door timonnl op 20 mei 2026 10:13]

[Xilonz]

Gezien de kwaadaardige extensie vanalles kon, is het goed mogelijk dat die keys via andere wegen (.env files etc) al zijn bemachtigt. Ik denk niet dat ze dat risico nemen en gewoon alle keys roteren.

[guidoruben]

Die keys stop je tegenwoordig niet meer in een .env file. Maar zet je tijdens deployment rechtstreeks in het OS vanuit een secrets manager. Dus tenzij je toegang hebt tot de productie omgeving kom je daar niet bij.

[NanoBob]

Überhaupt mag je hopen dat er geen keys in source control zitten.

[therazo]

Je wordt gedownvote, maar ik denk dat je gelijk hebt. Een ervaren security researcher zou kwetsbaarheden - indien aanwezig - kunnen vinden op een live omgeving met de broncode ernaast. Wellicht zou dit wel wat langer duren .
AI heeft een totaal andere insteek, maar heeft ook al bewezen (nog onbekende) exploits te kunnen vinden.

[Barsonax]

Inderdaad, kan mij moeilijk voorstellen dat je perse toegang moet hebben tot 3800! repositories.

Je ziet het echter wel vaker bij bedrijven dat de toegang gewoon wagenwijd openstaat naar bijv productie. Vaak ook niet consistent want bijv dan weer wel zware virus scanner aanzetten op dev machines, alsof het dan wel veilig is (vooral zwaar irritant langzaam).

[DefaultGateway]

Ze hebben zelf ook nog niet veel los gelaten

"Yesterday we detected and contained a compromise of an employee device involving a poisoned VS Code extension. We removed the malicious extension version, isolated the endpoint, and began incident response immediately."

[indigo79]

Zonder verdere informatie is daar weinig over te zeggen. Als die gebruiker toegang heeft tot zoveel interne repositories, heeft een malafide VS Code-extensie dat vrij makkelijk ook. Bewijst vooral dat software uit onbekende bronnen installeren (uiteraard) nog altijd een risico is, ook als dat VS Code extensies zijn en dat meer toegang dan noodzakelijk nooit een goed idee is (ook niet als de medewerker zelf te vertrouwen is).

[Pinkys Brain]

Waarom is het eigenlijk nog geen best practice in de IT om alle authenticatie via PKI te doen? Dat iets moderns als OpenAI API nog gewoon beveiligd is met een shared secret vind ik vreemd, beetje van het niveau "C werkt prima als je competent ben". Dat alle mensen incompetent zijn met shared secrets moet gewoon meegenomen worden in de ontwerp phase van een moderne API.

Als alle authenticatie via PKI was kon je de secret key in HSMs stoppen (session keys ook als de HSM de throughput aankan).

[roelboel]

Hoe zie je dit voor je? Stel dat ik op mijn laptop met de GH cli issues wil zien. Nu krijg ik een token. Hoe zou dit dmv PKI moeten werken?

[Pinkys Brain]

Specifiek voor Github kan je in plaats van access tokens, SSH met een SSH keys gebruiken.

Natuurlijk is er in veel gevallen geen PKI alternatief, maar dat is nou precies het probleem wat ik heb met de IT wereld.

[roelboel]

1. GH's SSH keys werken per-repo. Het is onvergelijkbaar met access tokens;
2. GH's SSH keys zijn geen PKI. De P van PKI is er wel (asymmetrische crypto) maar er is geen sprake van een CA of andere elementen van PKI;
3. Je slaat zelf de spijker op de kop en dat is mijn punt: PKI wordt in zulke gevallen niet gebruikt omdat het niet praktisch is. Het is (mede dankzij Let's Encrypt) vandaag eenvoudig om servers een certificaat te geven, maar clients niet. Vandaar dat ik in mijn voorbeeld het over mijn laptop had. Het is geen onwil of onkunde, het is gewoonweg een onpraktische oplossing.

[Pinkys Brain]

Clienten hebben geen sleutel nodig die aanvaard word door een publieke CA, ze hebben een sleutel nodig die aanvaard word door jouw (baas). Kijk bijvoorbeeld naar passkeys, komt buiten attestatie geen publieke CA aan te pas. Dat de PKI bij github gebrekkig is, is nog steeds hetgeen waar ik een probleem mee heb.

In een rationeel systeem zou binnen een bedrijf alle authenticatie met asymmetrische encryptie gedaan worden. Met centraal beheerde prive sleutels, die voor werknemers en server processen dan gesynchroniseerd worden naar centraal geregistreerde HSMs (yubikeys, cloudhsm, etc).

In plaats van tokens voor github zou je bijvoorbeeld passkeys kunnen registreren voor elk toegangsrecht (prive sleutel word door jouw bedrijf gegenereerd en beheerd, publieke sleutels worden naar Github gestuurd).

Alles wat met shared secrets kan, kan met PKI.

PS. yubihsm ipv yubikey, want iedereen doet alsof device bound keys nuttig zijn (zijn ze niet) en willen alleen maar iets nuttigs leveren als je het HSM noemt en het 100x duurder is.

[Reactie gewijzigd door Pinkys Brain op 20 mei 2026 16:02]

[demianmonteverd]

Als je eenmaal een API hebt staan buiten is het altijd lastig om deze te veranderen. Zeker als je grotere klanten hebt zoals github die heeft.

[Pinkys Brain]

Github kan verder weinig doen hieraan, wat ze ook doen als je in kan loggen op een account kan je een shared secret van een github action achterhalen.

Ze zouden hoogstens een cloudhsm aan kunnen bieden voor github actions onafhankelijk van Azure/AWS. Maar als de secrets niet PKI zijn helpt dat weinig.

[R_Zwart]

Het korte antwoord: er zijn nog teveel "cowboys" in de IT wereld. Voor een industrie die al zo lang bestaat is er nog steeds een hoog hobbygehalte, vaak onder het mom van "teveel gedoe", "niet leuk". Veel developers vinden het veel leuker om nieuwe functionaliteit te maken.

Op de gebieden waar het wel professioneel er aan toe gaat is PKI wel redelijk ingeburgerd. Zo wordt in bijvoorbeeld 4G/5G mobiele netwerken wordt PKI vrijwel overal gebruilkt.

[Scriptkid]

. Als er geen koper wordt gevonden, worden de gegevens volgens TeamPCP gratis gepubliceerd.

Tja zo motiveer je kopers wel lol.

[Luctia]

Zou een manier kunnen zijn om GitHub over te halen om te kopen

[Voutloos]

Github zelf inderdaad, of een partij welke exclusief de macht wil.

Bovenste bericht gaat uit van een eerlijke markt, maar deze transactie betreft ook chantage, macht en minder brave partijen.

[geerttttt]

Eigenlijk gek dat de lijst met repo namen niet bekend is. Als namelijk de repo van jouw bedrijf hier tussen zit is dat immers waarschijnlijk wel wat geld waard om dat prive te houden. Die repo staat niet voor niets op prive natuurlijk...

[Dooxed]

Nou als je die info voor jezelf wil houden dan koop je.

[Scriptkid]

dus jij vertrouwed die hackers dat ze het niet 2x of Xx verkopen lol

[Dooxed]

Ik niet hoor. Reputatie van PCPT schijnt niet te best te zijn "On the resale and reuse question specifically, Wiz's incident response team observed that TeamPCP's exfiltrated data and compromised secrets are potentially being shared with other groups to enable a range of operations. They also note that while the speed at which the stolen secrets were used suggests it was the same threat actors responsible for the supply chain operations, they could not rule out the secrets being shared with other groups and used by them." WizWiz

[Evert de Wit]

Het is dan wel weer ironisch dat juist Github geraakt wordt door een malafide vscode extensie; misschien is Microsoft nu wel bereid om het op een meer fundamentele manier op te lossen.

[SuperDre]

En hoe zou volgens jou dit dan fundamenteel opgelost moeten worden, en waarom de 'nu wel' sneer?

[Evert de Wit]

Er moet MFA nodig zijn voor het publiceren naar registries; ten minste voor non-canary versies.

Maar goed je hebt wel gelijk dat mijn opmerking te overdreven is. Microsoft doet al heel veel voor vscode extensies.

[ro8in]

Welke malafide extensie is dit dan? Wellicht handig om erbij te vermelden.

[teek2]

Misschien deze? https://github.com/nrwl/nx-console/security/advisories/GHSA-c9j4-9m59-847w

Maar ze zijn denk ik nog aan het onderzoeken.

[Reactie gewijzigd door teek2 op 20 mei 2026 09:40]

[PdeBie]

Klinkt alsof Github dit keer de pechvogel is en dat dit net zo goed bij Gitlab had kunnen gebeuren.

[fuzzyIon]

Ideaal voor een supplychain attack.

[FrostyPeet]

De hacking industrie is ondertussen een genadeloze activiteit geworden. Club die rustig een paar ton kapotslaan om een jaar lang aan alle digitale poorten te rammelen van hun prooi. Onaantastbaar, wie doet hen wat?

Uit bittere eigen ervaring merkte ik hoe griezelig het is geworden. Een voip toestel dat ik niet werkend kreeg. Even die firewall uitzetten om te controleren of het daar in zat. Binnen een paar minuten rinkelde de telefoon. Nummer 100. CsipSimple. Gewoon, een voip toestel van een nietszeggend doelwit met geen enkele economische waarde. In een paar minuten van even de firewall uitzetten. CsipSimple. Een open source "security" tool die trekjes heeft van een aanvalstool. Open source, voor elke scriptkiddie te downloaden.

En dan die cyber security experts die honend "kneus" en "eigen schuld" roepen. Diezelfde experts die machteloos staan tegenover die hack clubs en dus foldertjes met goede tips hebben. Dat je een firewall niet even uit moet zetten, je zet je voordeur toch ook niet open? Maar er moet toch ook een werkend toestel geïnstalleerd worden en op een gegeven moment zou het toch een firewall kwestie kunnen zijn. Bij de voordeur lopen niet de hele dag mensen rond die meteen naar binnen willen glippen op het moment dat de deur op een kier staat.

Nederig geworden door deze ervaring is mijn strategie om zo min als mogelijk aan internet te hangen.

[angushansen]

ik download dan ook vrijwel geen extensies tenzij het first party is. deed ik eigenlijk altijd maar tegenwoordig ben ik 10x zo streng. srry hoor maar ik vertrouw weinig meer op s*** het internet

[Reactie gewijzigd door angushansen op 20 mei 2026 11:23]

[Harm_H]

Lijkt me dat Vscode extensies een strengere verificatie gaan krijgen. Hebben ze al verplichte ID check en open-source code als eis?

Elke obscure npm package of Vscode extensie is een ingang. Auteurs van degelijke pakketten zijn net als directeuren van bedrijven een hoog risico doelwit.

Je ziet nu al dat ontwikkelaars werken met scripts om alleen t-1 of t-2 packages toe te staan. Misschien worden 'Long-term support' LTS versies ook wel de standaard in plaats altijd de laatste. In elk geval niet dagelijks overal de laatste versie continu updaten.