GitHub blev hacket via en VS Code-udvidelse (maj 2026): Den 60-minutters nødplan, som alle udviklere bør køre i aften

GitHub blev hacket via en VS Code-udvidelse (maj 2026): Den 60-minutters nødplan, som alle udviklere bør køre i aften

Den 20. maj 2026 bekræftede GitHub, at cirka 3.800 af deres interne kildekoderepositories blev eksfiltreret via en ondsindet VS Code-udvidelse installeret på en medarbejders arbejdsstation. Hvis du har brugt et GitHub PAT eller npm-token inde i VS Code inden for de sidste 14 dage, betyder de næste 60 minutter alt. Dette er planen: hvad der faktisk skete, om du er berørt, og hvad du skal rotere først.

Vigtigste pointer

• Hvad der skete: GitHub.com's produktionssystem blev ikke brudt ind i; en medarbejders VS Code installerede en forgiftet udvidelse (med stor sandsynlighed Nx Console v18.95.0), der eksfiltrerede PAT'er og dumpede ca. 3.800 interne repositories.
• Kundedata: Ikke berørt. De kompromitterede data er GitHubs interne kildekode, ikke kundekode eller konti.
• Hvem er i risiko: Enhver udvikler, der installerede en VS Code-udvidelse mellem cirka 18. maj kl. 12:36 UTC og 18. maj kl. 12:47 UTC (det 11-minutters vindue), eller enhver, der bruger langvarige GitHub PAT'er fra inde i VS Code.
• Hvad du skal gøre nu: Rotér først GitHub PAT'er, derefter npm-tokens og til sidst AWS/cloud-nøgler. Den fulde plan findes i afsnittet "Hvad udviklere skal gøre" nedenfor.

TL;DR: De 6 ting, du skal gøre i den næste time

Den hurtigste måde at begrænse skadeomfanget fra historien om github hacked vscode extension er at rotere de legitimationsoplysninger, en forgiftet udvidelse kan nå, auditere, hvad der er installeret på din laptop, og tjekke din GitHub-org-log for vinduet 18.-20. maj UTC. Seks handlinger, rangeret efter impact, i rækkefølge.

1. Tilbagekald hvert GitHub Personal Access Token, der er oprettet eller brugt i VS Code inden for de sidste 30 dage.
2. Rotér npm-tokens via npm token revoke og udsted nye med 2FA + trusted publishing.
3. Scan din laptop for IoC'er fra GHSA-c9j4-9m59-847w (filstier, processer; kommandoer nedenfor).
4. Auditér code --list-extensions --show-versions og afinstaller alt, hvad du ikke kan retfærdiggøre.
5. Pin udvidelsesversioner i devcontainer.json og håndhæv en org-level allow-list.
6. Tjek din GitHub org-auditlog for ukendte repo-pushes mellem 18.-20. maj UTC.

Hvis du kun har tid til to ting, så gør #1 og #3. Resten kan vente en time.

Blev GitHub faktisk hacket? Lad os rydde op i overskriften

Nej, GitHub.com's produktionsinfrastruktur blev ikke brudt ind i den 20. maj 2026. En enkelt GitHub-medarbejders arbejdsstation blev kompromitteret, efter at medarbejderen installerede en ondsindet VS Code-udvidelse (med stor sandsynlighed Nx Console v18.95.0). Angriberen, der kalder sig selv TeamPCP (sporet som UNC6780), eksfiltrerede cirka 3.800 af GitHubs interne kildekoderepositories. Kundekode, kundekonti og GitHubs produktionstjenester er ikke berørt.

Her er den renere version af, hvad der skete, og hvad der ikke skete.

Hvorfor betyder denne framing noget? Fordi takeaway'en ikke er "github hacked." Takeaway'en er, at udviklerendepunkter nu er den bløde underbug i enhver engineering-organisation. Hver hemmelighed, dit team ejer (GitHub PAT'er, npm-tokens, AWS-nøgler, vault-sessioner, AI-udbydernøgler), ligger på en laptop med lidt eller ingen EDR-dækning. En enkelt forgiftet udvidelse, der kører i din IDE, arver det hele.

GitHubs egen talsmand, citeret i Bleeping Computer, bekræftede framingen om medarbejder-endpointet og linjen om "ingen kundedata". Help Net Security tilføjede TeamPCP-attributionen. Den tekniske kæde af beviser for udvidelsen findes i rådgivningen GHSA-c9j4-9m59-847w.

GitHub.com blev ikke brudt ind i. En GitHub-medarbejder blev. Hold den ramme i hovedet, mens du læser resten.

Hvad der faktisk skete: Tidslinje for bruddet i maj 2026

Historien om github breach 2026 udfoldede sig over fire faser i løbet af cirka 48 timer. En forgiftet udvidelse blev publiceret den 18. maj kl. 12:36 UTC, fjernet 11 minutter senere, opdaget af GitHub dagen efter og offentligt offentliggjort den 20. maj. Den kompakte tidslinje med kilder:

Det 11-minutters vindue er den mærkeligste detalje. Det tyder på, at angriberen roterede udvidelser for at undgå marketplace-detektion, samme mønster som Koi Security dokumenterede i GlassWorm OpenVSX-ormen i oktober 2025. TeamPCP / UNC6780 har tidligere hævdet kompromitteringer i 2026 mod Trivy, KICS, LiteLLM, TanStack og MistralAI. Samme gruppe, samme playbook, andre mål.

I sidste måned var det Vercels env-vars. I dag er det GitHubs repos. Det mønster, vi har set udvikle sig over 9 måneder, flytter fortsat skadeomfanget udad. Se vores gennemgang af Vercel-brudresponsen for den søsterhændelse.

Udvidelsen, der sandsynligvis er skyldig: Nx Console v18.95.0 (og hvorfor GitHub ikke bekræfter)

GitHub har ikke formelt navngivet den udvidelse, der var involveret i kompromitteringen af medarbejder-endpointet. Retsmedicinske beviser peger stærkt på Nx Console v18.95.0, men dette forbliver meget sandsynligt, ikke bekræftet. Vi vil opdatere dette indlæg, hvis GitHub offentligt navngiver en anden udvidelse. Betragt resten af dette afsnit som den bedst tilgængelige attribution, ikke erklæret faktum.

Fire stykker circumstantielle beviser aligner Nx Console med GitHubs offentliggørelse:

1. Timing-match: Vinduet i rådgivningen GHSA-c9j4-9m59-847w (18. maj, 12:36-12:47 UTC) ligger inde i vinduet for kompromittering af GitHub-medarbejder-endpointet i GitHubs egen offentliggørelse.
2. Overlap af retsmedicinske IoC'er: StepSecuritys publicerede analyse af Nx Console-payloaden (filstier, processer som __DAEMONIZED, netværksendepunkter) matcher de artefakter, der blev set på det kompromitterede endpoint ifølge Wiz' writeup.
3. TeamPCP-attributionsmønster: TeamPCP / UNC6780 har været aktiv i VS Code-forsyningskæderummet (Trivy, KICS, LiteLLM, TanStack, MistralAI i 2026) med en konsistent payload-struktur.
4. Det 11-minutters fjernelsesvindue: Karakteristisk for forsyningskædeangreb, hvor angriberen styrer publiceringstidspunktet, men marketplace'en hurtigt fanger det.

Hvis du ikke installerede Nx Console, er du stadig ikke sikkert ude af skoven. Det bredere angrebsmønster (__DAEMONIZED-processer, IMDS-misbrug, eksfil af ~/.claude/settings.json) generaliseres til enhver forgiftet udvidelse. Triagen i næste afsnit gælder uanset hvilken udvidelse, du mistænker.

Er du berørt? Den 5-minutters triage

Der er tre hurtige tests. (1) Installerede eller auto-opdaterede du en VS Code-udvidelse mellem 18. maj kl. 12:36 og 12:47 UTC? (2) Findes nogen af IoC-filerne fra GHSA-c9j4-9m59-847w på din laptop lige nu? (3) Har du brugt et GitHub PAT inde i VS Code inden for de sidste 14 dage? Kør alle tre på under fem minutter.

Test 1, Udvidelsesaudit

# List all installed extensions with versions
code --list-extensions --show-versions

# Specifically check for Nx Console v18.95.0
code --list-extensions --show-versions | grep -i "nrwl.angular-console\|nx-console"

Alt, der auto-opdaterede sig mellem 17. og 18. maj, fortjener et andet kig. Hvis du ser Nx Console på præcis 18.95.0, er du en sandsynlig match. Den patched version er 18.100.0. Enten afinstaller den, eller gå direkte til planen nedenfor.

Test 2, IoC-scan

# Check for the daemonized credential-harvest process artifacts (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 abuse indicator (AWS credential harvest)
# Check shell history for unexpected curl to 169.254.169.254
grep -E "169\.254\.169\.254|metadata\.google\.internal" ~/.zsh_history ~/.bash_history 2>/dev/null

En ren maskine bør returnere ingenting for __DAEMONIZED-greppet, ingen .daemonized-filer og ingen IMDS-træffere i din shell-historik. Hvis nogen af disse lander, så antag at laptoppen er kompromitteret, og behandle hver legitimationsoplysning, den har rørt ved inden for de sidste 30 dage, som brændt.

Test 3, PAT-eksponering

Hvis du har brugt et GitHub PAT (klassisk eller finmaskeret) inde i enhver VS Code-terminal, integreret git eller enhver udvidelse, der kalder GitHub API'en inden for de sidste 14 dage, så antag at det er kompromitteret, og fortsæt til rotationsplanen nedenfor. Dette er den konservative standard; du kan ikke auditere "var tokenet i hukommelsen, mens udvidelsen var aktiv". Rotér det.

Hvis du bruger Claude Code, inkluderer IoC-listen specifikt ~/.claude/settings.json. Tjek vores Claude Code hooks-guide for, hvad der gemmes i den fil, og hvilke nøgler der skal roteres først.

Konklusion. Hvis nogen af disse tre giver et positivt resultat, skal du stoppe med at læse narrativet. Hop direkte til planen i næste afsnit. De næste 55 minutter betyder mere end post-mortem-analysen.

Hvad udviklere skal gøre: Den 60-minutters nødplan

Rotér legitimationsoplysninger i prioritetsrækkefølge. Tier 0 (næste 30 min): GitHub PAT'er og npm-tokens. Tier 1 (i dag): AWS / cloud-nøgler, 1Password / Vault, GitHub Actions-secrets. Tier 2 (denne uge): tredjeparts SaaS, OAuth-grants, SSH-nøgler. Tier 3 (når det passer): read-only og offentlige nøgler. Hvert tier kortlægges til en specifik reduktion af skadeomfanget.

LIGE NU: Hvis du tror, du er ramt

Hvis din triage kom tilbage positiv, skal du gøre disse tre ting i rækkefølge før noget andet.

1. Dræb daemonen og afinstaller den mistænkte udvidelse:

# Kill the malicious payload (GHSA-c9j4-9m59-847w)
pkill -f __DAEMONIZED
pkill -f "nx-console.*18.95.0"

# Uninstall the suspect extension immediately
code --uninstall-extension nrwl.angular-console

1. Træk netværkskablet ud af din laptop, hvis du har beviser for aktiv eksfiltrering. Lyder ekstremt. Det er det. Gør det alligevel. Du kan genundersøge offline.
2. Ring til dit sikkerhedsteam eller post i #security Slack, før du kører noget andet. Hvis du er alene, så spring til Tier 0 nedenfor.

Tier 0 (Næste 30 minutter): GitHub + npm

Tilbagekaldelse af GitHub PAT via gh CLI'en og webindstillings-UI'en:

# Confirm what you're authenticated as
gh auth status

# List app installations the token has access to (helps inventory blast radius)
gh api -H "Accept: application/vnd.github+json" /user/installations

# The gh CLI cannot revoke classic PATs directly — use the web UI:
#   https://github.com/settings/tokens
# Click "Revoke" on EVERY token. Do not selectively keep "the one that's probably fine."

# Re-issue with fine-grained PATs + ≤90-day expiration:
#   https://github.com/settings/personal-access-tokens/new
# Scope one repo at a time, never the whole account.

# For org-owned PATs and installations:
gh api /orgs/{ORG}/installations

Rotering af npm-token:

# List and revoke every npm token
npm token list
npm token revoke <token-id-1>
npm token revoke <token-id-2>

# Force 2FA on auth and writes
npm profile enable-2fa auth-and-writes

# For CI: migrate to OIDC trusted publishing — no more long-lived tokens
# Docs: https://docs.npmjs.com/trusted-publishers

Hvis du vedligeholder publicerede pakker, er dit npm-token den enkelt farligste legitimationsoplysning, du ejer. Rotér det før AWS.

Tier 1 (I dag): Cloud + Vaults + CI Secrets

AWS access keys kommer næst. IoC'erne viser IMDS-misbrug, så enhver IAM-bruger, der har rørt det kompromitterede endpoint, er mistænkelig:

# List access keys for the current IAM user
aws iam list-access-keys --user-name $(aws sts get-caller-identity --query 'Arn' --output text | cut -d/ -f2)

# Deactivate the old key (don't delete yet — let workloads fail loudly first)
aws iam update-access-key --access-key-id AKIA... --status Inactive --user-name <user>

# Create a new key
aws iam create-access-key --user-name <user>

# Once deployed and verified, delete the old key
aws iam delete-access-key --access-key-id AKIA... --user-name <user>

# If any EC2 instance was using IMDSv1, force IMDSv2 immediately
aws ec2 modify-instance-metadata-options --instance-id i-... --http-tokens required

1Password CLI: log ud af alle enheder (op signout --all), regenerer sessionstokens, og auditér nylig vault-adgang via 1Passwords web-auditlog for alt, der kørte fra det kompromitterede endpoint.

HashiCorp Vault: tilbagekald dit brugertoken (vault token revoke -self) og få en admin til at udstede et nyt med en kortere TTL.

GitHub Actions secrets: hvis en roteret legitimationsoplysning også findes i Actions, skal du opdatere den. Brug gh secret set GITHUB_PAT --body <new-pat> per repo, eller UI'en på org-niveau for org-secrets.

Anthropic og OpenAI API-nøgler: IoC-listen GHSA-c9j4-9m59-847w nævner specifikt ~/.claude/settings.json som et høstmål. Tilbagekald og genudsted din Anthropic console API-nøgle og enhver OpenAI-nøgle, du nogensinde har gemt i den fil.

Tier 2 (Denne uge): SSH + OAuth + Password Vaults

SSH-nøgler bevæger sig langsommere, men er stadig inden for scope. Udvidelsen havde filesystem-read på ~/.ssh/:

# Audit existing SSH keys (when were they generated?)
for key in ~/.ssh/id_*; do
  if [ -f "$key" ]; then
    echo "Key: $key"
    stat -c '%y' "$key" 2>/dev/null || stat -f '%Sm' "$key"
  fi
done

# Generate a new Ed25519 key
ssh-keygen -t ed25519 -C "rotated-$(date +%Y%m%d)" -f ~/.ssh/id_ed25519_new

# Upload public key to GitHub
gh ssh-key add ~/.ssh/id_ed25519_new.pub --title "rotated-$(date +%Y%m%d)"

# Delete the old key from GitHub via web UI, then verify SSH still works
ssh -T [email protected]

Browser-passwordmanager og OS-keychain: rotér enhver adgangskode, som udvidelsen plausibelt kunne have set via clipboard. Realistisk eksponering er adgangskoder, du kopierede til clipboard, mens udvidelsen var aktiv.

Tier 3 (Når det passer): Audit + Verificér

Auditér din GitHub org-log for kompromitteringsvinduet. Dette kræver org-admin:

# Pull push events for the May 18-20 window
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 suspicious commits (unexpected authors, large 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}'

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

Hvis auditloggen viser pushes fra kompromitteringsvinduet, som du ikke har lavet, skal du eskalere til dit sikkerhedsteam og bevare auditloggen JSON. Prøv ikke at "fortryde" noget i repoet. Bevar beviserne først.

Vi dækkede den samme tiered-rotationslogik for Vercel env-var-bruddet i april: samme form, andet lag.

5-spørgsmåls udvidelsesaudit-framework (brug dette for evigt)

Før du installerer eller stoler på en VS Code-udvidelse, skal du køre den gennem fem tests: publisher-domænealder, versionshastighed, package.json-aktiveringsbegivenheder, tilladelsesscope vs. forventet adfærd og open-source repo-audit. Nx Console v18.95.0 ville have fejlet Test #2: et pludseligt versionsspring efter en stabil release-cadence er det klassiske forsyningskædetegn.

1. Publisher-domænealder. Er publisherens domæne ældre end et år? Nye publishere på nyregistrerede domæner bærer mere risiko. Tjek via Visual Studio Marketplace publisher-side eller whois på publisher-e-mailens domæne.
2. Versionshastighed. Viser versionshistorikken normal cadence (én release hver 1-4 uge) eller et pludseligt spike (tre releases på 24 timer)? Pludselig hastighed er et signal. Nx Console v18.95.0 var en hastighedsanomali.
3. package.json aktiveringsbegivenheder. Åbn .vsix-filen (det er en zip) og læs activationEvents. Udvidelser, der aktiveres på * (always-on), har det største angrebsareal. Foretræk udvidelser, der aktiveres på et specifikt sprog eller filnavn.
4. Påkrævede tilladelser vs. forventet adfærd. Anmoder en "theme"-udvidelse om netværksadgang? Har en "snippet"-udvidelse brug for filesystem-write? Uoverensstemmelser er røde flag. Krydstjek mod Microsofts dokumentation om udvidelseskørselssikkerhed.
5. Open-source repo-audit. Ligger kilden på GitHub? Læs de sidste fem commits for mistænkelige ændringer: post-install hooks, base64-kodede blobs, netværkskald til ukendte domæner.

En udvidelse, der aktiveres på * og beder om netværksadgang, er funktionelt en remote shell med VS Code hæftet til sig.

Det samme audit-framework gælder for MCP-servere, den næste udvidelsesklasse i forsyningskædens overflade. Se vores gennemgang af bedste MCP-servere 2026 for, hvilke vi stoler på, og hvorfor.

Hvorfor dette bliver ved med at ske: Bølgen af forsyningskædeangreb 2025-2026

GitHub-bruddet den 20. maj er én knude i en 9-måneders bue: Shai-Hulud npm-orm (sept. 2025), GlassWorm OpenVSX-orm (okt.-nov. 2025), Shai-Hulud 2.0 (nov. 2025, 25.000+ berørte repos), Mini Shai-Hulud (tidligt 2026), Nx Console (18. maj 2026), GitHub-endpoint-kompromittering (20. maj 2026). Udviklerendepunkter er blevet den nye bløde underbug.

• Sept. 2025, Shai-Hulud npm-orm. Selvpropagerende malware i populære npm-pakker. CISA udsendte en alarm om den udbredte kompromittering.
• Okt.-nov. 2025, GlassWorm. Den første selvpropagerende orm, der målrettede VS Code-udvidelser på OpenVSX. Koi Security-offentliggørelse.
• Nov. 2025, Shai-Hulud 2.0. Over 25.000 repos eksfiltreret. Microsoft Security Blog publicerede inddæmningsvejledning.
• Tidligt 2026, Mini Shai-Hulud. TeamPCP-variant. Mindre skala gentagelser mod Trivy, KICS, LiteLLM, TanStack og MistralAI.
• 18. maj 2026, Nx Console v18.95.0. Meget sandsynlig vektor for GitHubs endpoint-kompromittering.
• 20. maj 2026, GitHub offentliggør. Ca. 3.800 interne repos eksfiltreret. Ifølge Wiz' Shai-Hulud retsmedicinske serie er IMDS-misbrugsmønsteret en direkte evolution.

Mønsteret er klart: udviklerlaptops holder hver hemmelighed i organisationen (GitHub PAT'er, AWS-nøgler, vault-tokens, AI-udbydernøgler) og har tæt på nul EDR-dækning. Indtil den ubalance vender, fortsætter denne bølge.

Defensiv AI er ét stykke af svaret. Vi dækkede denne vinkel i vores gennemgang af hvordan AI forhindrer databrud tidligere på året.

GitHubs større respons: Trusted Publishing, FIDO 2FA, 90-dages tokens

GitHub havde allerede været i gang med at rulle fire forsyningskædekontroller ud før den 20. maj: obligatorisk 2FA for npm-publishere, et 90-dages loft på granular write-tokens, TOTP-deprecering til fordel for FIDO og passkeys, og OIDC trusted publishing for GitHub Actions og GitLab CI. Maj-bruddet accelererer en allerede igangværende migration; det introducerer ikke en ny politik.

GitHubs bredere plan for en mere sikker npm-forsyningskæde går måneder tilbage før denne hændelse. Jo hurtigere du aligner med den, jo mindre bliver dit skadeomfang næste gang.

Hardening: Hvordan du overlever den næste

Seks fremadskuende træk: pin udvidelsesversioner i devcontainer.json, håndhæv en org-level udvidelses-allow-list, kør EDR med synlighed over udvidelsesprocesser, secret-scan hvert push, scope PAT'er til ét repo, og adoptér OIDC trusted publishing i stedet for langvarige tokens. Ingen af disse ville have forhindret hver hændelse, men sammen reducerer de skadeomfanget fra "alt på laptoppen" til "ét repo".

{
  "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 sagt:

• Pin hver udvidelsesversion i devcontainer.json for at dræbe auto-update.
• Allow-list på org-niveau ved at pege VSCODE_GALLERY_SERVICE_URL mod et internt spejl.
• EDR med IDE-processynlighed: Crowdstrike, SentinelOne eller Microsoft Defender for Endpoint med VS Code i scope.
• Secret-scan hvert push: pre-commit og push-time, server-side.
• Scope hver PAT til ét repo: ingen * scopes, nogensinde.
• OIDC trusted publishing: ingen langvarige npm- eller registry-tokens i CI.

Sidste uges Linux copy_file_range CVE er en søsterhistorie: andet lag, samme lektie. Den trust-grænse, du glemte, er den, der bider.

Hvis du overvejer AI-kodningsagenter næste gang, skal du anvende det samme audit-framework. De har samme trust-profil som udvidelser. Vores gennemgang af bedste AI-kodningsagenter 2026 gennemgår, hvilke agenter der optjener den tillid.

Ofte stillede spørgsmål

Blev GitHub hacket?

Nej, ikke i den betydning, de fleste overskrifter antyder. GitHub.com's produktion blev ikke brudt ind i. En GitHub-medarbejder installerede en ondsindet VS Code-udvidelse på deres arbejdsstation, hvilket eksfiltrerede cirka 3.800 af GitHubs interne kildekoderepositories. Kundekode, kundekonti og GitHubs produktionstjenester er ikke berørt.

Hvilken VS Code-udvidelse var faktisk involveret?

GitHub har ikke formelt bekræftet udvidelsens navn. Retsmedicinske beviser fra StepSecurity, Wiz og GHSA-c9j4-9m59-847w peger med stor sandsynlighed på Nx Console v18.95.0, publiceret den 18. maj kl. 12:36 UTC og fjernet 11 minutter senere. Vi behandler dette som "meget sandsynligt, ikke bekræftet", indtil GitHub navngiver det.

Er Nx Console sikker at bruge nu?

Den patched version er 18.100.0. Hvis du har en ældre v18.95.0 installeret, skal du afinstallere med det samme, køre IoC-scannet i vores triage-afsnit og kun geninstallere fra den officielle Nrwl-publisher i version 18.100.0 eller nyere. Verificér publisher-domænet før geninstallation og pin versionen i devcontainer.json.

Blev kundedata berørt af GitHub-bruddet?

Nej. Ifølge GitHubs officielle udtalelse via Bleeping Computer blev kundekildekode, kundekonti, OAuth-tokens og GitHub-hostede produktionsdata ikke tilgået. De kompromitterede data er GitHubs interne kildekode fra medarbejder-endpointet. Behandle dette som en medarbejder-laptop-hændelse, ikke et platformbrud.

Hvordan ved jeg, om mit GitHub PAT blev stjålet?

Det gør du ikke med sikkerhed. Den konservative antagelse: hvis du brugte et GitHub PAT inde i VS Code inden for de sidste 14 dage, skal du behandle det som kompromitteret og rotere det. Tjek din GitHub-auditlog via gh api /orgs/{ORG}/audit-log for ukendte push-begivenheder mellem 18.-20. maj UTC, og tilbagekald og genudsted derefter tokenet.

Hvad er TeamPCP og UNC6780?

TeamPCP er en trusselsaktørgruppe; UNC6780 er det sporings-ID, der er tildelt af incident-response-leverandører. De har offentligt krævet attribution for GitHub-bruddet. Samme gruppe har hævdet kompromitteringer i 2026 mod Trivy, KICS, LiteLLM, TanStack og MistralAI, et konsistent mønster for målretning af VS Code- og npm-forsyningskæden.

Er VS Code-udvidelser sandboxed?

Nej, ikke meningsfuldt. VS Code-udvidelser kører i IDE'ens Node.js-proces med brugerens fulde filesystem- og netværksprivilegier. De kan læse hver fil i din hjemmemappe, inklusive SSH-nøgler, ~/.aws/credentials, ~/.claude/settings.json og proceshukommelse via /proc/*/mem på Linux. Microsoft dokumenterer runtime-sikkerhedsmodellen og dens begrænsninger i de officielle udvidelsesdocs.

Påvirkede dette GitHub Codespaces eller CI-runners?

Ingen beviser hidtil. Kompromitteringen var en medarbejderarbejdsstation, ikke GitHub-hostet infrastruktur. Codespaces, GitHub Actions-runners og kunde-vendt CI-infrastruktur rapporteres ikke som berørt. Vi vil opdatere dette indlæg, hvis nye IoC'er ændrer det billede.

Bundlinjen

Tre ting at tage med sig:

1. GitHub.com blev ikke hacket. En medarbejders VS Code-arbejdsstation blev. Lektien generaliseres til enhver udvikler.
2. Rotér nu, audit-framework for evigt. 60-minutters planen er patchen; 5-spørgsmåls audit-frameworket er immunsystemet.
3. Dette er ikke en engangsforeteelse. Det er knude #6 i en 9-måneders forsyningskædebølge, der ikke sænker farten.

Sidst opdateret: 20. maj 2026. Vi vil sweep dette indlæg den 27. maj 2026 med nye IoC'er, leverandørrådgivninger og eventuel GitHub-bekræftet udvidelsesattribution.

Hvis dit team har brug for hjælp til at auditere jeres VS Code-udvidelsesoverflade, jeres PAT- og tokenhygiejne eller opbygge en org-level allow-list-politik, få en gratis konsultation. Vi har været dybt fokuserede på udvikler-endpoint-sikkerhed siden Vercel-bruddet i april, og planen ovenfor er det, vi kører med klienter fra dag ét.