Stel: je ontwikkelingspartner werkt met tools van Microsoft. Die tools halen automatisch code-pakketten op, draaien die in een AI-assistent, en iemand merkt niets. Tot er inloggegevens worden doorgestuurd naar een onbekende server. Dat is geen theoretisch scenario. GitHub blokkeerde in juni 2026 in totaal 73 open-sourcepakketten die cryptografisch geverifieerd waren als Microsoft-code, maar toch aangepast bleken om wachtwoorden en toegangssleutels te stelen. Het onderzoek loopt nog, maar de vraag voor jou als kmo-eigenaar is al duidelijk: weet je IT-partner of dev-leverancier of zij geraakt zijn?
GitHub detecteerde dat tientallen open-sourcepakketten die als officiële Microsoft-tools werden gepresenteerd, waren aangepast met kwaadaardige code. Ars Technica meldt dat het om de tweede keer in enkele weken gaat dat Microsoft-pakketten op deze manier werden besmet. GitHub blokkeerde in totaal 73 van deze pakketten.
Het bijzondere aan deze aanval is het activeringsmoment. De kwaadaardige code werd niet ontworpen om altijd te draaien, maar specifiek om te activeren wanneer een ontwikkelaar die pakketten opent via een AI-coding agent, een softwaretool die automatisch code schrijft, leest en uitvoert. Denk aan GitHub Copilot of Cursor. Op het moment dat de agent de pakketinhoud verwerkt, kunnen inloggegevens worden doorgestuurd zonder dat de ontwikkelaar iets merkt.
Microsoft heeft een beperkt aantal klanten gecontacteerd die mogelijk getroffen inhoud hebben geladen. Bevestigde gevallen van credential-diefstal bij klanten zijn op dit moment publiek niet vastgesteld, maar het onderzoek loopt. Onderzoekers adviseren iedereen die de betrokken pakketten via AI-agents heeft gebruikt, ervan uit te gaan dat hun systemen mogelijk blootgesteld zijn. Dat is een voorzichtigheidsmaatregel, geen zekerheid.
Dit incident raakt je ook als je zelf geen code schrijft. Als je IT-partner, webdeveloper of softwareleverancier werkt met open-sourcepakketten en AI-coding tools, dan loop je mee in dezelfde keten. Credentials die worden gestolen bij je leverancier, zijn vaak toegangssleutels tot cloudomgevingen, databases of bedrijfsapplicaties die ook jouw data bevatten.
Het risico zit in drie lagen:
Voor kmo’s die IT grotendeels uitbesteden, is de kern van het probleem niet technisch maar organisatorisch: weet je wat je leverancier gebruikt, hoe die tools worden geconfigureerd en of er monitoring is op afwijkend gedrag? Als dat antwoord onduidelijk is, is dat het eerste risico om aan te pakken.
Indicaties wijzen erop dat aanvallen via open-source supply chains toenemen. Een vergelijkbaar incident deed zich eerder in 2026 voor bij SAP npm-pakketten, waarbij AI-coding agents eveneens als aanvalsoppervlak dienden. Dit is geen incident op zichzelf, het is een patroon.
Je hoeft geen technische kennis te hebben om de juiste vragen te stellen. Stuur morgen een e-mail of plan een kort gesprek in met je IT-partner of ontwikkelingspartner. Vraag concreet:
Als je leverancier deze vragen niet kan beantwoorden of de context niet kent, is dat een signaal op zich. Goede IT-partners volgen dergelijke incidenten actief op en communiceren proactief naar klanten.
Wat je niet zelf moet doen: ga geen code doorzoeken of logs handmatig analyseren zonder begeleiding. Dat riskeert fouten of gemiste signalen. Vraag je leverancier of een gespecialiseerde securitypartner om die controles uit te voeren. Bij Clear IT bekijken we dit soort vragen soms samen met klanten om te bepalen welke stappen prioriteit verdienen.
Het onderzoek naar dit incident loopt nog en bevestigde schade bij klanten is publiek niet vastgesteld. Maar wachten op officiële cijfers is hier geen verstandige strategie. De drie verificaties hierboven kosten je minder dan een halfuur en geven snel duidelijkheid over jouw blootstelling. Zijn de antwoorden vaag of ontbreekt er monitoring bij je leverancier? Dan is dat het gesprek dat je nu moet voeren, niet pas na een incident. Contractuele garanties en actieve opvolging zijn geen luxe meer, ze zijn standaard verwacht van elke IT-partner die je vertrouwt met jouw data.
Niet automatisch. Vraag eerst aan je leverancier of ze de betrokken pakketten hebben gebruikt en of er afwijkende activiteit is vastgesteld. Als er een reele indicatie is van blootstelling, dan adviseert een securityspecialist je welke credentials prioriteit hebben.
Nee. Als je IT-partner of externe ontwikkelaar de betrokken tools gebruikt, loop je mee in dezelfde risicozone. Je hoeft zelf geen code te schrijven om indirect getroffen te worden via credentials of cloudtoegang die je leverancier beheert.
Dat weet je vaak niet zonder te vragen. Stel de vraag expliciet: welke AI-tools gebruiken jullie ontwikkelaars, en hebben die tools toegang tot credentials of omgevingen die aan ons bedrijf gelinkt zijn? Een transparante partner geeft daar direct antwoord op.
Dat is op dit moment publiek niet vastgesteld. Microsoft heeft een beperkt aantal klanten wereldwijd gecontacteerd over mogelijke blootstelling, maar bevestigde gevallen van credential-diefstal zijn nog niet publiek gemeld. Het onderzoek loopt.
