GitHub hackades via ett VS Code-tillägg (maj 2026): 60-minutersplanen varje utvecklare bör köra ikväll

GitHub hackades via ett VS Code-tillägg (maj 2026): 60-minutersplanen varje utvecklare bör köra ikväll

Den 20 maj 2026 bekräftade GitHub att ungefär 3 800 av sina interna källkodsrepo:s exfiltrerades via ett skadligt VS Code-tillägg installerat på en anställds arbetsstation. Om du använde en GitHub PAT eller npm-token i VS Code de senaste 14 dagarna spelar nästa 60 minuter roll. Det här är planen: vad som faktiskt hände, om du är drabbad, och vad du bör rotera först.

Vad du behöver veta direkt

• Vad hände: GitHubs produktion i sig bröts inte — en anställds VS Code installerade ett förgiftat tillägg (mycket troligt Nx Console v18.95.0) som exfiltrerade PAT:ar och dumpade ~3 800 interna repo:s.
• Kunddata: Inte drabbad. Det komprometterade materialet är GitHubs interna källkod, inte kundkod eller kundkonton.
• Vem är i riskzonen: Alla som installerade ett VS Code-tillägg någon gång mellan ungefär 18 maj kl 12:36 UTC och 12:47 UTC (den elva minuter långa fönstret), eller alla som använder långlivade GitHub PAT:ar inne i VS Code.
• Vad du gör nu: Rotera GitHub PAT:ar först, npm-token sedan, AWS/molnnycklar tredje — hela planen finns i avsnittet "Vad utvecklare måste göra" nedan.

TL;DR: De 6 sakerna att göra inom nästa timme

Det snabbaste sättet att begränsa skadan från github hackades vscode tillägg-händelsen är att rotera de uppgifter ett förgiftat tillägg kan komma åt, granska vad som är installerat på din dator, och kontrollera GitHub-org-loggen för perioden 18–20 maj UTC. Sex åtgärder, rangordnade efter påverkan, i rätt ordning.

1. Återkalla varje GitHub Personal Access Token som skapats eller använts i VS Code de senaste 30 dagarna.
2. Rotera npm-token via npm token revoke och återutfärda med 2FA + trusted publishing.
3. Skanna din dator efter IoC:er från GHSA-c9j4-9m59-847w (sökvägar, processer; kommandon nedan).
4. Granska code --list-extensions --show-versions och avinstallera allt du inte kan motivera.
5. Lås tilläggsversioner i devcontainer.json och inför en org-nivå-tillåtelselista.
6. Kontrollera GitHub-org:ens granskningslogg efter okända repo-pushar mellan 18–20 maj UTC.

Har du bara tid för två saker: gör #1 och #3. Resten kan vänta en timme.

Hackades GitHub egentligen? Vi reder ut rubrikerna

Nej, GitHubs produktionsinfrastruktur bröts inte den 20 maj 2026. En enda GitHub-anställds arbetsstation komprometterades efter att den anställde installerade ett skadligt VS Code-tillägg (mycket troligt Nx Console v18.95.0). Angriparen, som kallade sig TeamPCP (spårad som UNC6780), exfiltrerade ungefär 3 800 av GitHubs interna källkodsrepo:s. Kundkod, kundkonton och GitHubs produktionstjänster är inte drabbade.

Så här ser en renare bild ut av vad som hände respektive inte hände:

Varför spelar det här inramningen roll? För att slutsatsen inte är "github hackades." Slutsatsen är att utvecklarens arbetsstation nu är det mjuka underlaget i varje teknikorg. Varje hemlighet ditt team äger — GitHub PAT:ar, npm-token, AWS-nycklar, Vault-sessioner, AI-leverantörers API-nycklar — sitter på en laptop med i princip noll EDR-täckning. Ett enda förgiftat tillägg som körs i din IDE ärver alltihop.

GitHubs talesperson, citerad i Bleeping Computer, bekräftade "komprometterad anställds slutpunkt"-framing och "inga kunddata"-linjen. Help Net Security lade till TeamPCP-attributionen. Den tekniska beviskedjan för tillägget finns i säkerhetsnotisen GHSA-c9j4-9m59-847w.

GitHub.com bröts inte. En GitHub-anställd bröts. Håll det perspektivet när du läser resten.

Vad som faktiskt hände: tidslinje för intrånget i maj 2026

Intrånget maj 2026 utspelade sig i fyra steg under ungefär 48 timmar. Ett förgiftat tillägg publicerades den 18 maj kl 12:36 UTC, togs bort elva minuter senare, upptäcktes av GitHub nästa dag och offentliggjordes den 20 maj. Den komprimerade tidslinjen, med källor:

Det elva minuter långa fönstret är den märkligaste detaljen. Det tyder på att angriparen roterade tillägg för att undvika marketplace-detektering — samma mönster som Koi Security dokumenterade i GlassWorm-OpenVSX-masken från oktober 2025. TeamPCP / UNC6780 har tidigare gjort anspråk på 2026-intrång mot Trivy, KICS, LiteLLM, TanStack och MistralAI. Samma grupp, samma spelbok, olika mål.

Förra månaden var det Vercels env-variabler. I dag är det GitHubs repo:s. Mönstret vi bevittnat under 9 månader fortsätter att expandera i räckvidd. Se vår genomgång av Vercel-intrångets åtgärder för systerincidenten.

Tillägget som troligen var orsaken: Nx Console v18.95.0 (och varför GitHub inte bekräftar)

GitHub har inte formellt namngivit tillägget som var inblandat i kompromisset av anställdes slutpunkt. Forensiska bevis pekar starkt mot Nx Console v18.95.0, men det är mycket troligt, ej bekräftat. Vi uppdaterar det här inlägget om GitHub offentligt namnger ett annat tillägg. Behandla resten av det här avsnittet som bästa tillgängliga attribution, inte fastslaget faktum.

Fyra omständighetsbevis pekar mot Nx Console:

1. Tidsöverensstämmelse: Fönstret i GHSA-c9j4-9m59-847w (18 maj, 12:36–12:47 UTC) faller inuti det fönster GitHub anger för intrånget mot den anställdes slutpunkt.
2. Forensisk IoC-överlappning: StepSecurity:s publicerade analys av Nx Console-nyttolasten (sökvägar, processer som __DAEMONIZED, nätverksslutpunkter) stämmer med artefakterna på den komprometterade slutpunkten enligt Wiz:s rapport.
3. TeamPCP:s attributionsmönster: TeamPCP / UNC6780 har varit aktiva inom VS Code supply chain-utrymmet (Trivy, KICS, LiteLLM, TanStack, MistralAI under 2026) med en konsistent nyttolaststruktur.
4. Det elva minuter långa borttagningsfönstret: Kännetecknande för supply chain-attacker där angriparen kontrollerar publiceringsögonblicket men marketplace fångar det snabbt.

Installerade du inte Nx Console är du fortfarande inte ur skottlinjen. Det bredare attackmönstret (__DAEMONIZED-processer, IMDS-missbruk, exfiltrering av ~/.claude/settings.json) generaliseras till vilket förgiftat tillägg som helst. Triaget i nästa avsnitt gäller oavsett vilket tillägg du misstänker.

Är du drabbad? Triaget på 5 minuter

Tre snabba tester. (1) Installerade eller auto-uppdaterade du ett VS Code-tillägg mellan 18 maj kl 12:36 och 12:47 UTC? (2) Finns några IoC-filer från GHSA-c9j4-9m59-847w på din dator just nu? (3) Har du använt en GitHub PAT inne i VS Code de senaste 14 dagarna? Kör alla tre på under fem minuter.

Test 1 — Tilläggsgranskning

# Lista alla installerade tillägg med versioner
code --list-extensions --show-versions

# Kontrollera specifikt för Nx Console v18.95.0
code --list-extensions --show-versions | grep -i "nrwl.angular-console\|nx-console"

Allt som auto-uppdaterades mellan 17 och 18 maj förtjänar en extra titt. Ser du Nx Console på exakt 18.95.0 är du ett troligt träff. Den patchade versionen är 18.100.0. Avinstallera eller hoppa direkt till planen nedan.

Test 2 — IoC-skanning

# Kontrollera efter artefakter från den daemoniserade autentiseringsupptagningsprocessen (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

# Indikator för IMDS-missbruk (AWS-autentiseringsupptagning)
# Kontrollera shellhistorik efter oväntat curl mot 169.254.169.254
grep -E "169\.254\.169\.254|metadata\.google\.internal" ~/.zsh_history ~/.bash_history 2>/dev/null

En ren maskin bör inte ge något träff på __DAEMONIZED-grep, inga .daemonized-filer och inga IMDS-träffar i din shellhistorik. Om något av det dyker upp: anta att datorn är komprometterad och behandla varje uppgift den berört de senaste 30 dagarna som bränd.

Test 3 — PAT-exponering

Har du använt en GitHub PAT (klassisk eller finkornig) inne i någon VS Code-terminal, integrerad git eller något tillägg som anropar GitHub API de senaste 14 dagarna — anta att den är komprometterad och gå till rotationsplanen nedan. Det här är standardantagandet; du kan inte granska "var token i minnet medan tillägget var aktivt." Rotera den.

Använder du Claude Code är IoC-listan specifikt utpekad till att inkludera ~/.claude/settings.json. Se vår guide om Claude Code hooks för vad som lagras i den filen och vilka nycklar du bör rotera först.

Utfall. Ger något av dessa tre ett positivt svar: sluta läs berättelsen. Hoppa direkt till planen i nästa avsnitt. Nästa 55 minuter är viktigare än postmortem.

Vad utvecklare måste göra: 60-minutersplanen

Rotera uppgifter i prioritetsordning. Nivå 0 (nästa 30 min): GitHub PAT:ar och npm-token. Nivå 1 (idag): AWS/molnnycklar, 1Password/Vault, GitHub Actions-hemligheter. Nivå 2 (den här veckan): tredjepartsSaaS, OAuth-beviljanden, SSH-nycklar. Nivå 3 (när det passar): skrivskyddade och publika nycklar. Varje nivå motsvarar en specifik minskning av skadornas räckvidd.

DIREKT: Om du tror att du är drabbad

Fick triaget ett positivt svar: gör de här tre sakerna i ordning innan allt annat.

1. Döda daemonen och avinstallera det misstänkta tillägget:

# Döda den skadliga nyttolasten (GHSA-c9j4-9m59-847w)
pkill -f __DAEMONIZED
pkill -f "nx-console.*18.95.0"

# Avinstallera det misstänkta tillägget omedelbart
code --uninstall-extension nrwl.angular-console

1. Dra ur nätverkskabeln om du har bevis på aktiv exfiltrering. Det låter extremt. Det är det. Gör det ändå. Du kan utreda offline.
2. Ring ditt säkerhetsteam eller posta i #security-kanalen på Slack innan du gör något annat. Kör du solo: hoppa till Nivå 0 nedan.

Nivå 0 (Nästa 30 minuter): GitHub + npm

GitHub PAT-återkallning via gh CLI och webgränssnittet:

# Bekräfta vem du är autentiserad som
gh auth status

# Lista app-installationer som token har tillgång till (hjälper dig inventera skadornas räckvidd)
gh api -H "Accept: application/vnd.github+json" /user/installations

# gh CLI kan inte återkalla klassiska PAT:ar direkt — använd webgränssnittet:
#   https://github.com/settings/tokens
# Klicka "Revoke" på VARJE token. Välj inte selektivt "den som nog är OK."

# Återutfärda med finkorniga PAT:ar + ≤90 dagars löptid:
#   https://github.com/settings/personal-access-tokens/new
# Scope ett repo i taget, aldrig hela kontot.

# För org-ägda PAT:ar och installationer:
gh api /orgs/{ORG}/installations

npm-tokenrotation:

# Lista och återkalla varje npm-token
npm token list
npm token revoke <token-id-1>
npm token revoke <token-id-2>

# Kräv 2FA för autentisering och skrivningar
npm profile enable-2fa auth-and-writes

# För CI: migrera till OIDC trusted publishing — inga mer långlivade token
# Dokumentation: https://docs.npmjs.com/trusted-publishers

Underhåller du publicerade paket är din npm-token den enskilt farligaste uppgiften du äger. Rotera den innan AWS.

Nivå 1 (Idag): Moln + Vaults + CI-hemligheter

AWS-åtkomstnycklar kommer härnäst. IoC:erna visar IMDS-missbruk, så varje IAM-användare som rörde den komprometterade slutpunkten är misstänkt:

# Lista åtkomstnycklar för den aktuella IAM-användaren
aws iam list-access-keys --user-name $(aws sts get-caller-identity --query 'Arn' --output text | cut -d/ -f2)

# Deaktivera den gamla nyckeln (ta inte bort ännu — låt arbetsbelastningar misslyckas högljutt först)
aws iam update-access-key --access-key-id AKIA... --status Inactive --user-name <user>

# Skapa en ny nyckel
aws iam create-access-key --user-name <user>

# När den är driftsatt och verifierad, ta bort den gamla nyckeln
aws iam delete-access-key --access-key-id AKIA... --user-name <user>

# Om någon EC2-instans använde IMDSv1, tvinga IMDSv2 omedelbart
aws ec2 modify-instance-metadata-options --instance-id i-... --http-tokens required

1Password CLI: logga ut från alla enheter (op signout --all), återskapa sessiontoken och granska senaste vault-åtkomst via 1Password:s webb-granskningslogg efter allt som körde från den komprometterade slutpunkten.

HashiCorp Vault: återkalla din användartoken (vault token revoke -self) och be en admin utfärda en ny med kortare TTL.

GitHub Actions-hemligheter: om någon roterad uppgift också finns i Actions, uppdatera den. Använd gh secret set GITHUB_PAT --body <new-pat> per repo, eller org-nivåns gränssnitt för org-hemligheter.

Anthropic och OpenAI API-nycklar: IoC-listan för GHSA-c9j4-9m59-847w pekar specifikt ut ~/.claude/settings.json som ett upptagsningsmål. Återkalla och återutfärda din API-nyckel i Anthropic-konsolen och eventuella OpenAI-nycklar du någonsin lagrat i den filen.

Nivå 2 (Den här veckan): SSH + OAuth + Lösenordsvalv

SSH-nycklar rör sig långsammare men är ändå i omfånget. Tillägget hade läsåtkomst till ~/.ssh/:

# Granska befintliga SSH-nycklar (när genererades de?)
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

# Skapa en ny Ed25519-nyckel
ssh-keygen -t ed25519 -C "rotated-$(date +%Y%m%d)" -f ~/.ssh/id_ed25519_new

# Ladda upp den publika nyckeln till GitHub
gh ssh-key add ~/.ssh/id_ed25519_new.pub --title "rotated-$(date +%Y%m%d)"

# Ta bort den gamla nyckeln från GitHub via webgränssnittet, verifiera sedan att SSH fortfarande fungerar
ssh -T [email protected]

Webbläsarens lösenordshanterare och OS-nyckelring: rotera lösenord som tillägget rimligen kan ha sett via urklipp — det vill säga lösenord du kopierade till urklipp medan tillägget var aktivt.

Nivå 3 (När det passar): Granskning + verifiering

Granska GitHub-org-loggen för kompromisskällan. Det kräver org-admin:

# Hämta push-händelser för fönstret 18–20 maj
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}'

# Snabba kontroller av misstänkta commits (oväntade författare, stora diff:ar)
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}'

# Uppdatera OAuth-beviljanden
gh auth refresh -s admin:org -s admin:public_key

Visar granskningsloggen pushar från kompromissfönstret som du inte gjort: eskalera till ditt säkerhetsteam och bevara granskningsloggens JSON. Försök inte "ångra" något i repo:t. Bevara bevisen först.

Vi gick igenom samma nivåbaserade rotationslogik för Vercels env-var-intrång i april: samma form, annat lager.

Ramverket för tilläggsgranskning med 5 frågor (använd det för alltid)

Innan du installerar eller litar på ett VS Code-tillägg: kör det genom fem tester — utgivarens domänålder, versionsfrekvens, package.json-aktiveringshändelser, behörighetsomfång jämfört med förväntat beteende och granskning av öppenkällkods-repo. Nx Console v18.95.0 hade misslyckats på Test #2: ett plötsligt versionshopp efter ett stabilt releaseschema är det klassiska supply chain-tecknet.

1. Utgivarens domänålder. Är utgivarens domän äldre än ett år? Nya utgivare på nyregistrerade domäner bär mer risk. Kontrollera via Visual Studio Marketplace-utgivarsidan eller whois på utgivarens e-postdomän.
2. Versionsfrekvens. Visar versionshistoriken ett normalt schema (en release var 1–4 vecka) eller en plötslig topp (tre releaser på 24 timmar)? Plötslig frekvens är en signal. Nx Console v18.95.0 var en frekvensavvikelse.
3. package.json-aktiveringshändelser. Öppna .vsix-filen (det är ett zip-arkiv) och läs activationEvents. Tillägg som aktiveras på * (alltid på) har den största attackytan. Föredra tillägg som aktiveras på ett specifikt språk eller filnamn.
4. Nödvändiga behörigheter mot förväntat beteende. Begär ett "tema"-tillägg nätverksåtkomst? Behöver ett "snippet"-tillägg filsystemsskrivning? Avvikelser är röda flaggor. Krysskontrollera mot Microsofts dokumentation om tilläggets körtidssäkerhet.
5. Granskning av öppenkällkods-repo. Finns källan på GitHub? Läs de senaste fem commits för misstänkta ändringar: post-install-hooks, base64-kodade blobbar, nätverksanrop till okända domäner.

Ett tillägg som aktiveras på * och begär nätverksåtkomst är funktionellt ett fjärrskal med VS Code fastskruvat på det.

Samma granskningsramverk gäller för MCP-servrar, nästa supply chain-angreppsyta i tilläggsklassen. Se vår genomgång av bästa MCP-servrarna 2026 för vilka vi litar på och varför.

Varför det här håller på att hända: supply chain-vågen 2025–2026

Intrånget den 20 maj är en nod i en 9 månader lång bana: Shai-Hulud npm-masken (sept 2025), GlassWorm OpenVSX-masken (okt–nov 2025), Shai-Hulud 2.0 (nov 2025, 25 000+ drabbade repo:s), Mini Shai-Hulud (tidigt 2026), Nx Console (18 maj 2026), GitHub-slutpunktskompromisset (20 maj 2026). Utvecklarens arbetsstation har blivit det nya mjuka underlaget.

• Sept 2025, Shai-Hulud npm-masken. Självpropagerande skadlig kod i populära npm-paket. CISA utfärdade en varning om det utbredda intrånget.
• Okt–nov 2025, GlassWorm. Den första självpropagerande masken som riktade sig mot VS Code-tillägg på OpenVSX. Koi Securitys avslöjande.
• Nov 2025, Shai-Hulud 2.0. Över 25 000 repo:s exfiltrerade. Microsoft Security Blog publicerade inneslutningsguidning.
• Tidigt 2026, Mini Shai-Hulud. TeamPCP-variant. Mindre upprepningar mot Trivy, KICS, LiteLLM, TanStack och MistralAI.
• 18 maj 2026, Nx Console v18.95.0. Mycket trolig angreppsväg för GitHub-slutpunktskompromisset.
• 20 maj 2026, GitHub avslöjar. ~3 800 interna repo:s exfiltrerade. Enligt Wiz:s forensiska Shai-Hulud-serie är IMDS-missbruksmönstret en direkt evolution.

Mönstret är tydligt: utvecklarens laptop innehåller varje hemlighet i org:en (GitHub PAT:ar, AWS-nycklar, vault-token, AI-leverantörers nycklar) och har nästan noll EDR-täckning. Tills den obalansen rättas till fortsätter den här vågen.

Defensiv AI är en del av svaret. Vi gick igenom den vinkeln i vår genomgång av hur AI förhindrar dataintrång tidigare i år.

GitHubs bredare svar: trusted publishing, FIDO 2FA, 90-dagarstoken

GitHub hade redan lanserat fyra supply chain-kontroller före den 20 maj: obligatorisk 2FA för npm-utgivare, ett 90-dagarstak på finkorniga skrivtoken, TOTP-utfasning till förmån för FIDO och passnycklar samt OIDC trusted publishing för GitHub Actions och GitLab CI. Intrånget i maj accelererar en redan pågående migrering; det introducerar inte någon ny policy.

GitHubs övergripande plan för ett säkrare npm supply chain föregår den här incidenten med månader. Ju snabbare du anpassar dig till den, desto mindre blir skadan nästa gång.

Härdning: Hur du överlever nästa gång

Sex framåtblickande åtgärder: lås tilläggsversioner i devcontainer.json, inför en tillåtelselista för tillägg på org-nivå, kör EDR med processinsynlighet för tillägg, hemlighets-skanna varje push, begränsa PAT:ar till ett repo och använd OIDC trusted publishing istället för långlivade token. Ingen av dessa hade förhindrat varenda incident — tillsammans krymper de skadans räckvidd från "allt på laptopen" till "ett 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:

• Lås varje tilläggsversion i devcontainer.json för att ta bort auto-uppdatering.
• Tillåtelselista på org-nivå genom att peka VSCODE_GALLERY_SERVICE_URL mot en intern spegel.
• EDR med IDE-processinsynlighet: Crowdstrike, SentinelOne eller Microsoft Defender for Endpoint med VS Code i omfånget.
• Hemlighets-skanna varje push: pre-commit och vid push-tidpunkten, serversidan.
• Begränsa varje PAT till ett repo: inga *-omfång, någonsin.
• OIDC trusted publishing: inga långlivade npm eller registrytoken i CI.

Förra veckans copy_file_range CVE är en systerhistoria: annat lager, samma lärdom. Gränsen du glömde är den som biter.

Funderar du på AI-kodningsagenter härnäst: tillämpa samma granskningsramverk. De har samma tillförlitlighetsprofil som tillägg. Vår genomgång av bästa AI-kodningsagenter 2026 går igenom vilka agenter som förtjänar det förtroendet.

Vanliga frågor

Hackades GitHub?

Nej, inte i den mening som de flesta rubriker antyder. GitHubs produktion bröts inte. En GitHub-anställd installerade ett skadligt VS Code-tillägg på sin arbetsstation, vilket exfiltrerade ungefär 3 800 av GitHubs interna källkodsrepo:s. Kundkod, kundkonton och GitHubs produktionstjänster är inte drabbade.

Vilket VS Code-tillägg var inblandat?

GitHub har inte formellt bekräftat tilläggets namn. Forensiska bevis från StepSecurity, Wiz och GHSA-c9j4-9m59-847w pekar mycket troligt mot Nx Console v18.95.0, publicerat 18 maj kl 12:36 UTC och borttaget elva minuter senare. Vi behandlar detta som "mycket troligt, ej bekräftat" tills GitHub namnger det.

Är Nx Console säkert att använda nu?

Den patchade versionen är 18.100.0. Har du en äldre v18.95.0 installerad: avinstallera omedelbart, kör IoC-skanningen i triageavsnittet och installera om enbart från den officiella Nrwl-utgivaren på version 18.100.0 eller senare. Verifiera utgivardomänen innan du installerar om och lås versionen i devcontainer.json.

Drabbades kunddata av GitHub-intrånget?

Nej. Enligt GitHubs officiella uttalande via Bleeping Computer berördes inte kundkällkod, kundkonton, OAuth-token eller GitHub-hostad produktionsdata. Det komprometterade materialet är GitHubs interna källkod från anställdas slutpunkt. Behandla detta som ett anställd-laptop-incident, inte ett plattformsintrång.

Hur vet jag om min GitHub PAT stals?

Det vet du inte med säkerhet. Standardantagandet: om du använde en GitHub PAT inne i VS Code de senaste 14 dagarna, behandla den som komprometterad och rotera den. Kontrollera din GitHub-granskningslogg via gh api /orgs/{ORG}/audit-log efter okända push-händelser 18–20 maj UTC, återkalla sedan och återutfärda token.

Vad är TeamPCP och UNC6780?

TeamPCP är en hotaktörsgrupp; UNC6780 är spårnings-ID:t som tilldelats av incidentrespons-leverantörer. De har offentligen tagit på sig attributionen för GitHub-intrånget. Samma grupp har gjort anspråk på 2026-intrång mot Trivy, KICS, LiteLLM, TanStack och MistralAI — ett konsistent VS Code- och npm supply chain-målinriktningsmönster.

Är VS Code-tillägg sandboxade?

Nej, inte i någon meningsfull bemärkelse. VS Code-tillägg körs i IDE:ns Node.js-process med användarens fulla filsystem- och nätverksbehörigheter. De kan läsa varje fil i din hemkatalog, inklusive SSH-nycklar, ~/.aws/credentials, ~/.claude/settings.json och processminne via /proc/*/mem på Linux. Microsoft dokumenterar körtidssäkerhetsmodellen och dess begränsningar i den officiella tilläggsdokumentationen.

Drabbades GitHub Codespaces eller CI-runners?

Inga bevis hittills. Kompromisset gällde en anställds arbetsstation, inte GitHubs infrastruktur. Codespaces, GitHub Actions-runners och kundvänlig CI-infrastruktur rapporteras inte som drabbade. Vi uppdaterar det här inlägget om nya IoC:er förändrar bilden.

Slutsatsen

Tre saker att ta med sig:

1. GitHub.com hackades inte. En anställds VS Code-arbetsstation hackades. Lärdomen gäller varje utvecklare.
2. Rotera nu, granskningsramverk för alltid. 60-minutersplanen är patchen; 5-frågornas granskningsramverk är immunförsvaret.
3. Det här är inte en engångshändelse. Det är nod #6 i en 9 månader lång supply chain-våg som inte mattas av.

Senast uppdaterad: 20 maj 2026. Vi ser över det här inlägget den 27 maj 2026 med nya IoC:er, leverantörernas riktlinjer och eventuell GitHub-bekräftad tilläggsattribution.

Behöver ditt team hjälp med att granska era VS Code-tillägg, din PAT- och tokenhygien eller att bygga en tillåtelselistepolicy på org-nivå: boka en kostnadsfri konsultation. Vi har fokuserat intensivt på säkerhet för utvecklarslutpunkter sedan Vercel-intrånget i april, och planen ovan är vad vi kör med klienter dag ett.