GitHub fixt kritieke rce-bug waardoor miljoenen repository's toegankelijk waren

GitHub heeft een kritieke remote code execution-kwetsbaarheid opgelost. Daardoor konden kwaadwillenden toegang krijgen tot miljoenen repository's, zowel openbaar als privé. Volgens GitHub is de kwetsbaarheid niet misbruikt.

Cloudsecuritybedrijf Wiz ontdekte de CVE-2026-3854-kwetsbaarheid naar eigen zeggen met behulp van de AI-tool IDA MCP. Door de injectionbug uit te buiten, kon iedereen met pushtoegang tot een repository commando's uitvoeren op de backendservers van GitHub. Wiz beweert dat het eenvoudig was om de kwetsbaarheid uit te buiten, omdat hier slechts één enkel gitpushcommando voor nodig was.

Hierdoor zouden onbevoegden toegang kunnen krijgen tot miljoenen openbare en privérepository's op GitHub. Op GitHub Enterprise Server zou het mogelijk zijn geweest om een hele server te compromitteren, waardoor kwaadwillenden lees- en schrijftoegang hadden tot alle interne repository's en secrets.

Wiz heeft GitHub op de hoogte gebracht van de kwetsbaarheid. Het platform wist de bug zelf te reproduceren en had binnen enkele uren een fix uitgebracht. Uit intern onderzoek zou blijken dat er geen sprake was van misbruik. De kwetsbaarheid is al in maart gedicht, maar dat is nu pas bekendgemaakt.

Reacties (17)

[BvdW1978]

Grappig dat ze altijd heel snel weten te melden dat het niet misbruikt is..

[PolarBear]

Ze hebben het in maart gefixt, dus ook wat tijd gehad voor onderzoek lijkt mij.

[DDX]

Ergens wel slecht dat ze dan nu pas info naar buiten brengen.
Als bleek dat er wel misbruik van gemaakt was hadden ze beter in maart al advies kunnen geven om secrets etc aan te passen.

[RobertMe]

Er zijn ook enterprise klanten die ook deze kwetsbare versie draaien / draaiden. Als ik het mij goed herinner van een Hacker News discussie van gisteren waren er gisteren nog iets van 80% van de online gevonden enterprise GitHub installaties (als in: "on-premise") kwetsbaar . Daarom dat er vaker wel al over een kwetsbaarheid wordt gecommuniceerd maar nog niks wordt prijsgegeven, evt in combinatie met "op datum X om tijdstip Y komt een nieuwe versie uit" zodat gebruikers een update kunnen plannen.

Maar gezien het hier gaat om een lek dat, volgens GitHub zelf dan, niet actief misbruikt is lijkt het mij prima om dit ASAP te fixen, en "gesloten" naar de klanten (van GitHub Enterprise dus) te communiceren. En dan pas later publiekelijk bekend te maken. Des te meer tijd die Enterprise klanten de tijd hebben om de boel te updaten voordat er veel meer aandacht voor komt. Dat er een maand zit tussen fixen en publiceren lijkt mij dan ook prima. Immers lijkt het niet om een zero-day te gaan.

[R_Zwart]

Je moet ook niet teveel melden. Dan loop je het risico dat de echte criticals ondersneeuwen. Deze was geclassificeerd als high.

[Xfade]

Ik gok dat ze ook wel info hadden gegeven in maart als er wat gebeurt was.

Als je weet dat iets veilig genoeg bleek, waarom dan direkt info geven? Ik zou ook wachten en analyseren desnoods met hulp van justitie e.d.

[batjes]

Omdat dit soort meuk veelal minimaal in de syslogs terecht komt en het is een kleine moeite om dit een half jaar of langer in zoiets als Graylog bij te houden.

[Keypunchie]

In dit geval vermoed ik dat je een vrij specifiek verzoek moet sturen naar de API, die je vervolgens de toegang geeft. Dat komt wel in je access logs terecht, dus kun je nazoeken (tot op zekere hoogte, vaak worden access logs niet oneindig bewaard).

[flossed]

Tja je kan moeilijk zeggen dat big tech bedrijf xyz voor veel geld alle code voor zijn ai heeft opgezogen

[pim]

Dit is dus eigenlijk een goede reden om github niet te gebruiken?
Veiligheid valt niet te garanderen.

[densoN]

Verwacht jij beter vulnerability management op een eigen interne VCS/SCM? Zo ja, dan zou je een verhuizing kunnen overwegen.

[downtime]

Het is een goede reden om geen computers meer te gebruiken. Eigenlijk kun je heel veel dingen dan niet meer gebruiken omdat veiligheid vrijwel nooit gegarandeerd kan worden.

[morphje]

We hebben in de afgelopen decennia gigantische clusterfucks gezien van epische proporties die onder normale omstandigheden zou leiden tot failissement van het bedrijf in kwestie.

En toch blijven we excuses geven voor die bedrijven, niet omdat de fouten catastrofaal zijn, maar omdat we bang zijn om zelf fouten te maken en daarmee zelf moeten opdraaien voor die fouten. Nu kunnen we de grote amazon of microsoft de schuld geven en niemand die ook maar luistert of excuses aanbiedt.

Een minister president die met z'n Nokia alle SMSjes wist? Geen enkel probleem
AI topvrouw die al haar e-mails wistte? Oh het was AI.
Amazon die de dienstverlening van duizenden bedrijven stopt? Oh DNS foutje.
De lijst is kilometers lang.

We zijn werkelijk te afhankelijk geworden van grote partijen dat we dit soort excuses blijven accepteren. Bang om zelf kleine foutjes te maken, dus accepteren we vele malen grotere fouten van anderen en tegelijkertijd verliezen we steeds meer kennis en kunde in onze eigen rangen.

[SuperDre]

Veiligheid valt nergens 100% te garanderen.

[patchii]

Zou de fix de huidige fouten met pull requests hebben veroorzaakt? https://www.githubstatus.com/incidents/x69zbgdyfzg0

[ToAoM]

Neuh... Dat is een indexing issue, waarschijnlijk veroorzaakt door het vele malen grotere volume in Pull Requests, Actions workflows etc.

GitHub heeft in de eerste 2 maanden van dit jaar al bijna net zoveel werk te verstouwen gehad als heel vorig jaar.

[patchii]

Je hebt compleet gelijk, in de tekst staat ook dat dit zich heeft afgespeeld in maart. Te snel overheen gelezen.