GitHub Gehackt via een VS Code-extensie (mei 2026): Het 60-Minuten Noodplan voor Elke Ontwikkelaar

GitHub Gehackt via een VS Code-extensie (mei 2026): Het 60-Minuten Noodplan voor Elke Ontwikkelaar

Op 20 mei 2026 bevestigde GitHub dat circa 3.800 interne broncode-repositories zijn buitgemaakt via een kwaadaardige VS Code-extensie op het werkstation van een medewerker. Als je de afgelopen 14 dagen een GitHub PAT of npm-token hebt gebruikt binnen VS Code, tellen de komende 60 minuten echt mee. Dit is het stappenplan: wat er precies is gebeurd, of je risico loopt, en wat je als eerste moet roteren.

Kernpunten

• Wat er is gebeurd: GitHub.com-productie is niet gehackt — een medewerker installeerde een vergiftigde extensie (zeer waarschijnlijk Nx Console v18.95.0) die PATs uitlekte en ~3.800 interne repos kopieerde.
• Klantdata: Niet getroffen. De gelekte data betreft GitHubs interne broncode, niet klantcode of -accounts.
• Wie loopt risico: Elke ontwikkelaar die tussen circa 18 mei 12:36 UTC en 18 mei 12:47 UTC (het 11-minutenvenster) een VS Code-extensie installeerde of bijwerkte, of iedereen die langlevende GitHub PATs binnen VS Code gebruikt.
• Wat nu te doen: Roteer GitHub PATs als eerste, npm-tokens als tweede, AWS/cloudsleutels als derde — volledig stappenplan in het onderdeel "Wat ontwikkelaars moeten doen" hieronder.

TL;DR: De 6 Dingen voor het Komende Uur

De snelste manier om de schade van het github gehackt vscode extensie-incident te beperken is het roteren van credentials die een vergiftigde extensie kan bereiken, controleren wat er op je laptop staat en je GitHub-org-log nakijken voor het venster 18-20 mei UTC. Zes acties, gerangschikt op impact, in volgorde.

1. Intrek elk GitHub Personal Access Token dat de afgelopen 30 dagen is aangemaakt of gebruikt in VS Code.
2. Roteer npm-tokens via npm token revoke en geef ze opnieuw uit met 2FA + trusted publishing.
3. Scan je laptop op IoCs uit GHSA-c9j4-9m59-847w (bestandspaden, processen; commando's hieronder).
4. Controleer code --list-extensions --show-versions en verwijder alles wat je niet kunt verantwoorden.
5. Pin extensieversies in devcontainer.json en stel een allowlist op organisatieniveau in.
6. Bekijk je GitHub-org-auditlog op onbekende repo-pushes tussen 18 en 20 mei UTC.

Als je maar tijd hebt voor twee, doe dan #1 en #3. De rest kan een uurtje wachten.

Is GitHub Echt Gehackt? Laten We de Krantenkop Rechtzetten

Nee, de productie-infrastructuur van GitHub.com is op 20 mei 2026 niet gehackt. Het werkstation van één GitHub-medewerker raakte gecompromitteerd nadat die medewerker een kwaadaardige VS Code-extensie installeerde (zeer waarschijnlijk Nx Console v18.95.0). De aanvaller, die zichzelf TeamPCP noemt (gevolgd als UNC6780), maakte circa 3.800 interne broncode-repositories van GitHub buit. Klantcode, klantaccounts en GitHubs productieservices zijn niet getroffen.

Dit is het overzicht van wat er wel en niet is gebeurd.

Waarom is deze framing belangrijk? Omdat de conclusie niet "github gehackt" is. De conclusie is dat ontwikkelaarsendpoints inmiddels de zachte plek zijn van elke engineeringorganisatie. Elk geheim dat je team bezit (GitHub PATs, npm-tokens, AWS-sleutels, vault-sessies, API-sleutels van AI-providers) staat op een laptop met nauwelijks EDR-dekking. Één vergiftigde extensie die draait in je IDE erft dat allemaal.

GitHubs eigen woordvoerder, geciteerd in Bleeping Computer, bevestigde het endpoint-frame en de "geen klantdata"-verklaring. Help Net Security voegde de TeamPCP-attributie toe. De technische bewijsketen voor de extensie staat in advisory GHSA-c9j4-9m59-847w.

GitHub.com is niet gehackt. Een GitHub-medewerker wel. Houd dat onderscheid in je hoofd terwijl je de rest leest.

Wat Er Echt Gebeurd Is: Tijdlijn van de Inbreuk van Mei 2026

Het github breach 2026-verhaal ontvouwde zich in vier fasen over circa 48 uur. Een vergiftigde extensie werd gepubliceerd op 18 mei om 12:36 UTC, elf minuten later verwijderd, de volgende dag door GitHub gedetecteerd en op 20 mei openbaar gemeld. De compacte tijdlijn, met bronnen:

Dat 11-minutenvenster is het vreemdste detail. Het suggereert dat de aanvaller extensies rouleerde om marketplace-detectie te ontwijken — hetzelfde patroon dat Koi Security documenteerde bij de GlassWorm OpenVSX-worm van oktober 2025. TeamPCP / UNC6780 heeft eerder compromitteringen in 2026 geclaimd bij Trivy, KICS, LiteLLM, TanStack en MistralAI. Zelfde groep, zelfde aanpak, andere doelwitten.

Vorige maand waren het de env-vars van Vercel. Vandaag zijn het GitHubs repos. Het patroon dat we al 9 maanden zien, blijft de schaderadius verder uitbreiden. Bekijk onze analyse van de Vercel breach-respons voor het verwante incident.

De Waarschijnlijke Extensie: Nx Console v18.95.0 (En Waarom GitHub Het Niet Bevestigt)

GitHub heeft de betrokken extensie bij de compromittering van het medewerkers-endpoint niet formeel benoemd. Forensisch bewijs wijst sterk in de richting van Nx Console v18.95.0, maar dit blijft zeer waarschijnlijk, niet bevestigd. We werken dit artikel bij als GitHub een andere extensie officieel noemt. Beschouw de rest van dit onderdeel als beste beschikbare attributie, niet als vastgesteld feit.

Vier omstandige aanwijzingen verbinden Nx Console met de GitHub-bekendmaking:

1. Overeenkomst in timing: Het GHSA-c9j4-9m59-847w-venster (18 mei, 12:36-12:47 UTC) valt binnen het venster van de compromittering van het medewerkers-endpoint zoals vermeld in GitHubs eigen bekendmaking.
2. Overlap in forensische IoCs: StepSecurity's gepubliceerde analyse van de Nx Console-payload (bestandspaden, processen zoals __DAEMONIZED, netwerkeindpunten) komt overeen met de artefacten die op het gecompromitteerde endpoint zijn aangetroffen, zoals beschreven in de writeup van Wiz.
3. Attributiepatroon van TeamPCP: TeamPCP / UNC6780 is actief in de VS Code supply-chain-ruimte (Trivy, KICS, LiteLLM, TanStack, MistralAI in 2026) met een consistente payloadstructuur.
4. Het 11-minutenvenster voor verwijdering: Kenmerkend voor supply-chain-aanvallen waarbij de aanvaller het publicatiemoment controleert maar de marketplace het snel oppikt.

Als je Nx Console niet hebt geïnstalleerd, ben je er nog niet veilig mee af. Het bredere aanvalspatroon (__DAEMONIZED-processen, IMDS-misbruik, ~/.claude/settings.json-exfiltratie) geldt voor elke vergiftigde extensie. De triage in het volgende onderdeel is van toepassing ongeacht welke extensie je vermoedt.

Ben Je Getroffen? De 5-Minuten Triage

Er zijn drie snelle tests. (1) Heb je tussen 18 mei 12:36 en 12:47 UTC een VS Code-extensie geïnstalleerd of automatisch bijgewerkt? (2) Staan er IoC-bestanden van GHSA-c9j4-9m59-847w op je laptop? (3) Heb je de afgelopen 14 dagen een GitHub PAT gebruikt binnen VS Code? Voer alle drie in minder dan vijf minuten uit.

Test 1 — Extensiecontrole

# Lijst alle geïnstalleerde extensies met versies
code --list-extensions --show-versions

# Controleer specifiek op Nx Console v18.95.0
code --list-extensions --show-versions | grep -i "nrwl.angular-console\|nx-console"

Alles dat automatisch is bijgewerkt tussen 17 en 18 mei verdient een tweede blik. Als je Nx Console ziet op exact 18.95.0, is de kans groot dat je getroffen bent. De gepatchte versie is 18.100.0. Verwijder de extensie of ga direct naar het stappenplan hieronder.

Test 2 — IoC-scan

# Controleer op artefacten van het gedemoniseerde credential-oogstproces (GHSA-c9j4-9m59-847w)
ps aux | grep -i "__DAEMONIZED" | grep -v grep
ls -la ~/.local/share/kitty/ 2>/dev/null
find ~ -name "*.daemonized*" 2>/dev/null

# IMDS-misbruikindicator (AWS-credential-oogst)
# Controleer shellgeschiedenis op onverwachte curl naar 169.254.169.254
grep -E "169\.254\.169\.254|metadata\.google\.internal" ~/.zsh_history ~/.bash_history 2>/dev/null

Een schone machine geeft niets terug voor de __DAEMONIZED-grep, geen .daemonized-bestanden en geen IMDS-hits in je shellgeschiedenis. Als een van die checks iets oplevert, beschouw de laptop dan als gecompromitteerd en behandel elke credential die er de afgelopen 30 dagen op is gebruikt als verbrand.

Test 3 — PAT-blootstelling

Als je de afgelopen 14 dagen een GitHub PAT (klassiek of fijnmazig) hebt gebruikt in een VS Code-terminal, geïntegreerde git of een extensie die de GitHub API aanroept, ga er dan vanuit dat die is gecompromitteerd en ga naar het rotatiestappenplan hieronder. Dit is de conservatieve standaard — je kunt niet controleren of het token in het geheugen zat terwijl de extensie actief was. Roteer het.

Als je Claude Code gebruikt, bevat de IoC-lijst specifiek ~/.claude/settings.json. Bekijk onze Claude Code hooks-gids voor wat er in dat bestand staat en welke sleutels je als eerste moet roteren.

Conclusie. Als een van deze drie tests positief uitslaat, stop dan met het lezen van het verhaal. Ga direct naar het stappenplan in het volgende onderdeel. De komende 55 minuten zijn belangrijker dan de postmortem.

Wat Ontwikkelaars Moeten Doen: Het 60-Minuten Noodplan

Roteer credentials in prioriteitsvolgorde. Tier 0 (komende 30 min): GitHub PATs en npm-tokens. Tier 1 (vandaag): AWS/cloudsleutels, 1Password/Vault, GitHub Actions-secrets. Tier 2 (deze week): third-party SaaS, OAuth-grants, SSH-sleutels. Tier 3 (wanneer het uitkomt): alleen-lezen en publieke sleutels. Elke tier correspondeert met een specifieke verlaging van de schaderadius.

NU DIRECT: Als Je Vermoedt Dat Je Getroffen Bent

Als je triage positief uitviel, doe dan deze drie dingen in volgorde voordat je verder gaat.

1. Stop het daemon en verwijder de verdachte extensie:

# Stop de kwaadaardige payload (GHSA-c9j4-9m59-847w)
pkill -f __DAEMONIZED
pkill -f "nx-console.*18.95.0"

# Verwijder de verdachte extensie onmiddellijk
code --uninstall-extension nrwl.angular-console

1. Trek de netwerkkabel van je laptop als je aanwijzingen hebt van actieve exfiltratie. Klinkt drastisch. Dat is het ook. Doe het toch. Je kunt offline verder onderzoeken.
2. Bel je securityteam of post in #security op Slack voordat je iets anders doet. Als je alleen werkt, ga direct naar Tier 0 hieronder.

Tier 0 (Komende 30 Minuten): GitHub + npm

GitHub PAT intrekken via de gh CLI en de webinstellingen:

# Bevestig als wie je bent geauthenticeerd
gh auth status

# Lijst app-installaties waartoe het token toegang heeft (helpt de schaderadius in kaart te brengen)
gh api -H "Accept: application/vnd.github+json" /user/installations

# De gh CLI kan klassieke PATs niet rechtstreeks intrekken — gebruik de web-UI:
#   https://github.com/settings/tokens
# Klik op "Revoke" bij ELK token. Selecteer niet "de token die waarschijnlijk wel goed is."

# Geef opnieuw uit met fijnmazige PATs + maximaal 90 dagen geldigheid:
#   https://github.com/settings/personal-access-tokens/new
# Beperk scope tot één repository tegelijk, nooit het hele account.

# Voor organisatie-PATs en installaties:
gh api /orgs/{ORG}/installations

npm-tokenrotatie:

# Lijst en trek elk npm-token in
npm token list
npm token revoke <token-id-1>
npm token revoke <token-id-2>

# Verplicht 2FA voor authenticatie en schrijfbewerkingen
npm profile enable-2fa auth-and-writes

# Voor CI: migreer naar OIDC trusted publishing — geen langlevende tokens meer
# Documentatie: https://docs.npmjs.com/trusted-publishers

Als je gepubliceerde packages beheert, is je npm-token de gevaarlijkste credential die je bezit. Roteer die vóór AWS.

Tier 1 (Vandaag): Cloud + Vaults + CI-secrets

AWS-toegangssleutels komen daarna. De IoCs tonen IMDS-misbruik, dus elke IAM-gebruiker die het gecompromitteerde endpoint heeft aangeraakt is verdacht:

# Lijst toegangssleutels voor de huidige IAM-gebruiker
aws iam list-access-keys --user-name $(aws sts get-caller-identity --query 'Arn' --output text | cut -d/ -f2)

# Deactiveer de oude sleutel (verwijder nog niet — laat workloads eerst luid falen)
aws iam update-access-key --access-key-id AKIA... --status Inactive --user-name <user>

# Maak een nieuwe sleutel aan
aws iam create-access-key --user-name <user>

# Zodra geïmplementeerd en geverifieerd, verwijder de oude sleutel
aws iam delete-access-key --access-key-id AKIA... --user-name <user>

# Als een EC2-instantie IMDSv1 gebruikte, forceer IMDSv2 onmiddellijk
aws ec2 modify-instance-metadata-options --instance-id i-... --http-tokens required

1Password CLI: meld je af op elk apparaat (op signout --all), genereer sessietokens opnieuw en controleer recente vault-toegang via het webauditlog van 1Password op alles dat van het gecompromitteerde endpoint afkomstig is.

HashiCorp Vault: trek je gebruikerstoken in (vault token revoke -self) en laat een beheerder een nieuw token uitgeven met een kortere TTL.

GitHub Actions-secrets: als een geroteerde credential ook in Actions staat, werk die dan bij. Gebruik gh secret set GITHUB_PAT --body <new-pat> per repository, of de organisatie-UI voor organisatiesecrets.

Anthropic- en OpenAI-API-sleutels: de IoC-lijst van GHSA-c9j4-9m59-847w noemt specifiek ~/.claude/settings.json als oogstdoel. Trek je Anthropic-console-API-sleutel in en geef die opnieuw uit, samen met elke OpenAI-sleutel die je ooit in dat bestand hebt opgeslagen.

Tier 2 (Deze Week): SSH + OAuth + Wachtwoordvaults

SSH-sleutels bewegen langzamer maar vallen nog wel in scope. De extensie had leesrechten op ~/.ssh/:

# Controleer bestaande SSH-sleutels (wanneer zijn ze gegenereerd?)
for key in ~/.ssh/id_*; do
  if [ -f "$key" ]; then
    echo "Sleutel: $key"
    stat -c '%y' "$key" 2>/dev/null || stat -f '%Sm' "$key"
  fi
done

# Genereer een nieuwe Ed25519-sleutel
ssh-keygen -t ed25519 -C "geroteerd-$(date +%Y%m%d)" -f ~/.ssh/id_ed25519_new

# Upload de publieke sleutel naar GitHub
gh ssh-key add ~/.ssh/id_ed25519_new.pub --title "geroteerd-$(date +%Y%m%d)"

# Verwijder de oude sleutel via de GitHub web-UI en verifieer daarna dat SSH nog werkt
ssh -T [email protected]

Browserwachtwoordbeheerder en OS-sleutelhanger: roteer elk wachtwoord dat de extensie plausibel heeft kunnen zien via het klembord. Realistische blootstelling betreft wachtwoorden die je naar het klembord hebt gekopieerd terwijl de extensie actief was.

Tier 3 (Wanneer Het Uitkomt): Controle + Verificatie

Controleer je GitHub-org-log voor het compromitteringsvenster. Hiervoor heb je org-beheerdersrechten nodig:

# Haal push-events op voor het venster 18-20 mei
gh api -X GET /orgs/{ORG}/audit-log \
  --paginate \
  -f phrase='action:repo.push created:2026-05-18..2026-05-20' | jq '.[] | {actor, created_at, repo}'

# Spot-check verdachte commits (onverwachte auteurs, grote diffs)
gh api -X GET /repos/{ORG}/{REPO}/commits \
  -f since=2026-05-18T00:00:00Z \
  -f until=2026-05-20T23:59:59Z | jq '.[] | {sha, author: .commit.author, message: .commit.message}'

# Vernieuw OAuth-grants
gh auth refresh -s admin:org -s admin:public_key

Als het auditlog pushes toont vanuit het compromitteringsvenster die jij niet hebt gemaakt, escaleer dan naar je securityteam en bewaar de auditlog-JSON. Probeer niets "ongedaan te maken" in de repository. Bewaar het bewijs eerst.

We behandelden dezelfde gelaagde rotatielogica voor de Vercel env-var-inbreuk in april: zelfde structuur, andere laag.

Het 5-Vragen Extensieaudit-Framework (Gebruik Dit Altijd)

Voordat je een VS Code-extensie installeert of vertrouwt, doorloop je vijf tests: domeinage van de uitgever, versiesnelheid, package.json-activatiegebeurtenissen, permissiescope versus verwacht gedrag, en open-source-repo-audit. Nx Console v18.95.0 had Test #2 niet doorstaan: een plotselinge versiesprong na een stabiele releasecadans is het klassieke supply-chain-signaal.

1. Domeinage van de uitgever. Is het domein van de uitgever ouder dan één jaar? Nieuwe uitgevers op recent geregistreerde domeinen brengen meer risico met zich mee. Controleer via de Visual Studio Marketplace-uitgeverspagina of via whois op het domein van het e-mailadres van de uitgever.
2. Versiesnelheid. Toont de versiegeschiedenis een normale cadans (één release per 1-4 weken) of een plotselinge piek (drie releases in 24 uur)? Plotselinge snelheid is een signaal. Nx Console v18.95.0 was een snelheidsanomalie.
3. package.json-activatiegebeurtenissen. Open het .vsix-bestand (het is een zip) en lees activationEvents. Extensies die activeren op * (altijd aan) hebben het grootste aanvalsoppervlak. Geef de voorkeur aan extensies die activeren op een specifieke taal of bestandsnaam.
4. Vereiste permissies versus verwacht gedrag. Vraagt een "thema"-extensie om netwerktoegang? Heeft een "snippet"-extensie schrijfrechten op het bestandssysteem nodig? Discrepanties zijn rode vlaggen. Vergelijk met Microsofts documentatie over extensie-runtime-security.
5. Open-source-repo-audit. Staat de broncode op GitHub? Lees de laatste vijf commits op verdachte wijzigingen: post-install-hooks, base64-gecodeerde blobs, netwerkaanroepen naar onbekende domeinen.

Een extensie die activeert op * en om netwerktoegang vraagt, is functioneel een externe shell met VS Code eraan vastgemaakt.

Hetzelfde auditframework is van toepassing op MCP-servers, het volgende extensieklasse-supply-chain-aanvalsoppervlak. Bekijk onze beste MCP-servers 2026-analyse voor welke we vertrouwen en waarom.

Waarom Dit Blijft Gebeuren: De Supply Chain-golf van 2025-2026

De GitHub-inbreuk van 20 mei is één knooppunt in een boog van 9 maanden: Shai-Hulud npm-worm (sept. 2025), GlassWorm OpenVSX-worm (okt.-nov. 2025), Shai-Hulud 2.0 (nov. 2025, 25.000+ getroffen repos), Mini Shai-Hulud (begin 2026), Nx Console (18 mei 2026), GitHub-endpoint-compromittering (20 mei 2026). Ontwikkelaarsendpoints zijn de nieuwe zachte plek.

• Sept. 2025, Shai-Hulud npm-worm. Zelfpropagererende malware in populaire npm-packages. CISA gaf een waarschuwing uit over de wijdverspreide compromittering.
• Okt.-nov. 2025, GlassWorm. De eerste zelfpropagerende worm gericht op VS Code-extensies op OpenVSX. Koi Security-bekendmaking.
• Nov. 2025, Shai-Hulud 2.0. Meer dan 25.000 repos buitgemaakt. Microsoft Security Blog publiceerde inperkingsgidsen.
• Begin 2026, Mini Shai-Hulud. TeamPCP-variant. Kleinschalige herhaling bij Trivy, KICS, LiteLLM, TanStack en MistralAI.
• 18 mei 2026, Nx Console v18.95.0. Zeer waarschijnlijke vector voor de GitHub-endpoint-compromittering.
• 20 mei 2026, GitHub maakt het bekend. ~3.800 interne repos buitgemaakt. Volgens Wiz's Shai-Hulud forensische serie is het IMDS-misbruikpatroon een directe evolutie.

Het patroon is duidelijk: ontwikkelaarslaptops bevatten elk geheim van de organisatie (GitHub PATs, AWS-sleutels, vault-tokens, AI-provider-sleutels) en hebben vrijwel geen EDR-dekking. Zolang dat onevenwicht niet wordt gecorrigeerd, gaat deze golf door.

Defensieve AI is één stuk van het antwoord. We behandelden dit in onze analyse van hoe AI datalekken voorkomt eerder dit jaar.

GitHubs Bredere Reactie: Trusted Publishing, FIDO 2FA, 90-Dagen Tokens

GitHub was al vier supply-chain-beveiligingsmaatregelen aan het uitrollen vóór 20 mei: verplichte 2FA voor npm-uitgevers, een limiet van 90 dagen op fijnmazige schrijftokens, TOTP-afschaffing ten gunste van FIDO en passkeys, en OIDC trusted publishing voor GitHub Actions en GitLab CI. De inbreuk van mei versnelt een migratie die al gaande was; er is geen nieuw beleid ingevoerd.

GitHubs bredere plan voor een veiliger npm supply chain dateert van maanden voor dit incident. Hoe sneller je je daarnaar richt, hoe kleiner je schaderadius de volgende keer.

Hardening: Overleven voor de Volgende Keer

Zes toekomstgerichte maatregelen: pin extensieversies in devcontainer.json, stel een org-niveau extensie-allowlist in, draai EDR met zichtbaarheid op extensieprocessen, scan elk push op secrets, beperk PATs tot één repository en adopteer OIDC trusted publishing in plaats van langlevende tokens. Geen van deze had elk incident voorkomen — samen krimpen ze de schaderadius van "alles op de laptop" naar "één repository".

{
  "name": "secure-dev",
  "extensions": [
    "[email protected]",
    "[email protected]",
    "[email protected]"
  ],
  "settings": {
    "extensions.autoUpdate": false,
    "extensions.autoCheckUpdates": false
  },
  "containerEnv": {
    "VSCODE_GALLERY_SERVICE_URL": "https://your-internal-allow-list.example.com"
  }
}

Kort samengevat:

• Pin elke extensieversie in devcontainer.json om auto-update uit te schakelen.
• Allowlist op org-niveau door VSCODE_GALLERY_SERVICE_URL te laten wijzen naar een interne mirror.
• EDR met IDE-procesvisibiliteit: Crowdstrike, SentinelOne of Microsoft Defender for Endpoint met VS Code in scope.
• Secretscan bij elke push: pre-commit en push-moment, server-side.
• Beperk elke PAT tot één repository: nooit *-scopes.
• OIDC trusted publishing: geen langlevende npm- of registry-tokens in CI.

De Linux copy_file_range CVE van vorige week is een verwant verhaal: andere laag, zelfde les. De vertrouwensgrens die je vergeten was, is de grens die toeslaat.

Als je overweegt AI-coding-agents te gebruiken, pas dan hetzelfde auditframework toe. Ze hebben hetzelfde vertrouwensprofiel als extensies. Onze beste AI-coding-agents 2026-analyse laat zien welke agents dat vertrouwen verdienen.

Veelgestelde Vragen

Is GitHub gehackt?

Niet in de zin die de meeste krantenkoppen suggereren. GitHub.com-productie is niet gehackt. Een GitHub-medewerker installeerde een kwaadaardige VS Code-extensie op zijn werkstation, waardoor circa 3.800 interne broncode-repositories van GitHub zijn buitgemaakt. Klantcode, klantaccounts en GitHubs productieservices zijn niet getroffen.

Welke VS Code-extensie was er precies bij betrokken?

GitHub heeft de naam van de extensie niet formeel bevestigd. Forensisch bewijs van StepSecurity, Wiz en GHSA-c9j4-9m59-847w wijst zeer waarschijnlijk naar Nx Console v18.95.0, gepubliceerd op 18 mei om 12:36 UTC en elf minuten later verwijderd. We behandelen dit als "zeer waarschijnlijk, niet bevestigd" totdat GitHub het officieel benoemt.

Is Nx Console nu veilig te gebruiken?

De gepatchte versie is 18.100.0. Als je de oudere v18.95.0 geïnstalleerd hebt, verwijder die dan onmiddellijk, voer de IoC-scan in ons triagegedeelte uit en installeer opnieuw uitsluitend van de officiële Nrwl-uitgever op versie 18.100.0 of hoger. Controleer het uitgeversdomein voordat je opnieuw installeert en pin de versie in devcontainer.json.

Is klantdata getroffen bij de GitHub-inbreuk?

Nee. Volgens GitHubs officiële verklaring via Bleeping Computer zijn klantbroncode, klantaccounts, OAuth-tokens en door GitHub gehoste productiedata niet geraadpleegd. De gelekte data betreft GitHubs interne broncode van het medewerkers-endpoint. Beschouw dit als een laptop-incident van een medewerker, niet als een platforminbreuk.

Hoe weet ik of mijn GitHub PAT is gestolen?

Dat weet je niet met zekerheid. De conservatieve aanname: als je de afgelopen 14 dagen een GitHub PAT hebt gebruikt binnen VS Code, beschouw die dan als gecompromitteerd en roteer hem. Controleer je GitHub-auditlog via gh api /orgs/{ORG}/audit-log op onbekende push-events tussen 18 en 20 mei UTC, trek het token dan in en geef een nieuw uit.

Wat zijn TeamPCP en UNC6780?

TeamPCP is een dreigingsgroep; UNC6780 is de tracking-ID die door incident-response-vendors is toegewezen. Ze hebben publiekelijk de GitHub-inbreuk geclaimd. Dezelfde groep heeft 2026-compromitteringen geclaimd bij Trivy, KICS, LiteLLM, TanStack en MistralAI — een consistent patroon van supply-chain-aanvallen via VS Code en npm.

Zijn VS Code-extensies in een sandbox?

Nee, niet op een zinvolle manier. VS Code-extensies draaien in het Node.js-proces van de IDE met de volledige bestandssysteem- en netwerkrechten van de gebruiker. Ze kunnen elk bestand in je thuismap lezen, inclusief SSH-sleutels, ~/.aws/credentials, ~/.claude/settings.json en procesgeheugen via /proc/*/mem op Linux. Microsoft documenteert het runtime-beveiligingsmodel en de beperkingen ervan in de officiële extensiedocumentatie.

Had dit invloed op GitHub Codespaces of CI-runners?

Tot nu toe geen bewijs van. De compromittering betrof een werkstation van een medewerker, niet door GitHub gehoste infrastructuur. Codespaces, GitHub Actions-runners en klantgerichte CI-infrastructuur zijn niet als getroffen gemeld. We werken dit artikel bij als nieuwe IoCs dat beeld veranderen.

Conclusie

Drie dingen om mee weg te lopen:

1. GitHub.com is niet gehackt. Het VS Code-werkstation van een medewerker wel. De les geldt voor elke ontwikkelaar.
2. Roteer nu, auditframework voor altijd. Het 60-minutenplan is de patch; het 5-vragen-auditframework is het immuunsysteem.
3. Dit is geen eenmalig incident. Het is knooppunt #6 in een supply-chain-golf van 9 maanden die niet afzwakt.

Laatst bijgewerkt: 20 mei 2026. We checken dit artikel op 27 mei 2026 opnieuw met nieuwe IoCs, adviezen van leveranciers en eventuele door GitHub bevestigde extensie-attributie.

Als je team hulp nodig heeft bij het controleren van je VS Code-extensieoppervlak, je PAT- en tokenhygiëne, of bij het opbouwen van een allowlistbeleid op organisatieniveau, vraag een gratis consultatie aan. We zijn al sinds de Vercel-inbreuk in april diep in developer-endpoint-security gedoken, en het bovenstaande stappenplan is wat we op dag één met klanten uitvoeren.