GitHub Breach Response Developer Security Supply Chain Security VS Code Incident Response

GitHub Breach: What Happened, What to Check, and What to Do Next

A GitHub security incident is making news. Here's the 10-minute checklist your team can run today to audit tokens, OAuth apps, and CI/CD secrets.

centrexIT
9 min read

Consider this a public service announcement. GitHub confirmed today that attackers gained access to roughly 3,800 of its internal repositories after a company employee installed a poisoned Visual Studio Code extension. Our phones started ringing the way they always do when a platform that runs underneath everyone’s code shows up in the news. So instead of a hot take, we are publishing the checklist we are walking our own clients through right now. Use it. Share it with your dev team. We will keep the language plain.

What happened

Based on GitHub’s own May 20 disclosure: a GitHub employee’s device was compromised by a malicious Visual Studio Code extension. The attackers used that foothold to exfiltrate approximately 3,800 GitHub-internal repositories. GitHub detected the activity on May 19, contained the compromised endpoint, removed the poisoned extension from the VS Code Marketplace, and began rotating its highest-impact credentials overnight. The threat group TeamPCP (tracked by Google Threat Intelligence as UNC6780) has claimed responsibility and is reportedly attempting to sell the stolen material on a cybercrime forum.

GitHub has stated there is no current evidence that customer repositories, customer organizations, or customer enterprises were affected, and that the activity appears limited to GitHub’s own internal repositories. The investigation is ongoing and that picture may change.

A few details worth knowing as you read the rest of this post:

  • GitHub has not named the specific VS Code extension involved. That matters because blocking a malicious extension depends on knowing which one it is.
  • TeamPCP is not new. Researchers have linked the group to a string of 2026 supply-chain attacks against developer tooling, including Trivy, Checkmarx, Bitwarden CLI, TanStack, and LiteLLM. This is what they do.
  • A separate VS Code extension was backdoored the day before. Nx Console, which has roughly 2.2 million installs, was briefly compromised on May 18. The community caught it in about eleven minutes, but auto-update windows mean a lot of machines pulled the bad version anyway.

Why this matters more than the average breach

GitHub sits underneath the software supply chain. When the platform that holds your code, your build pipelines, and your deployment automation has an incident, the question is not just “was our data exposed?” The question is “could someone push code into our production environment using stolen credentials before anyone noticed?”

That is the supply-chain risk angle, and it is the one that turns a developer-tooling story into a board-level conversation. A compromised CI/CD pipeline is how attackers move from a breach headline to your customers’ data without ever touching your firewall.

This incident sharpens that conversation in a specific way. The initial vector was not a stolen password or a phished credential. It was an extension on a developer’s laptop. VS Code extensions, by design, have full access to everything on the developer’s machine: credentials, cloud keys, SSH keys, source code in progress. Most endpoint detection tools do not see what extensions are doing because the extensions are running inside a trusted application the user installed on purpose.

The AI angle makes it sharper. A lot of organizations have wired up GitHub Copilot, Cursor, Claude Code, or other AI coding assistants in the last 18 months. Those integrations hold tokens too. If your AI tooling has read or write access to your repositories, those access paths are part of the audit you need to run today.

The 10-minute checklist (do this today)

This is what we are walking clients through. None of it requires a security team. A competent developer or IT admin can run it in under an hour.

1. Audit installed VS Code extensions across the team. This is the new item, and given the vector of this breach, it is the first one. Open VS Code → Extensions panel. Review what is installed on each developer’s machine. Remove anything nobody actively uses, anything from an unfamiliar publisher, and anything you cannot quickly justify. Verify auto-update settings and consider whether you want a short review window between a publish and an auto-install.

2. Review active GitHub sessions. Go to GitHub Settings → Sessions. Sign out anything you do not recognize. Do this for every account with admin or write access to your organization.

3. Rotate personal access tokens (PATs). Settings → Developer settings → Personal access tokens. Revoke any token you cannot immediately justify. Reissue the ones you need with the minimum scope and an expiration date.

4. Audit OAuth applications. Settings → Applications → Authorized OAuth Apps. Revoke anything you do not actively use. Anything you do use, note for follow-up — those tokens may need to be rotated by the vendor.

5. Check for exposed secrets in repos. Run GitHub’s secret scanning (it is free for public repos and included in GitHub Advanced Security for private ones). Look for AWS keys, database credentials, API keys, and anything that looks like a password.

6. Review deploy keys and SSH keys. Settings → SSH and GPG keys at the user level, and Deploy keys at the repository level. Remove anything stale.

7. Audit GitHub Actions secrets. If you use GitHub Actions, those workflow secrets are valuable to an attacker. Verify the list, rotate anything sensitive, and confirm no workflow is logging secrets to console output.

8. Enable or verify 2FA across the org. Organization settings → Authentication security. Require 2FA for all members. If you are already doing this, confirm no one has been grandfathered out.

9. Check your CI/CD provider integrations. If you use CircleCI, Jenkins, GitLab, or a deployment platform connected to GitHub, review the tokens those services hold. Rotate them as a precaution.

10. Review AI assistant access. Copilot, Cursor, and similar tools maintain their own connections. Verify the scope, and if any tool has write access, consider whether it actually needs it.

11. Document what you checked. Five sentences in a shared document. Date, who reviewed what, what was rotated. If this incident grows, you will be glad you have it.

If you only have ten minutes, do items 1, 3, 7, and 9. The extension audit, the PAT rotation, the Actions secrets, and the CI/CD provider tokens are the four that map most directly to how this specific breach unfolded.

What we are telling clients about the bigger picture

Incidents like this one are why we keep pushing the same message: in a software-driven business, the developer toolchain is the production environment. The same controls you would put on a server — least privilege, MFA, token rotation, audit logging — apply to GitHub, npm, your CI/CD platform, your IDE extensions, and every AI tool you have wired into the pipeline.

The new twist in 2026 is that the developer’s laptop has become the soft entry point. A poisoned IDE extension is a low-visibility, high-trust attack vector. Traditional endpoint protection does not catch it well, because the malicious code is running inside a trusted application the user chose to install. That gap is what TeamPCP has been exploiting all year, across Trivy, Checkmarx, Bitwarden CLI, TanStack, LiteLLM, and now GitHub itself.

Most organizations we onboard have never done a full audit of who and what holds tokens to their source control, let alone what is running inside their developers’ IDEs. Not because they are careless — because the tooling sprawls quietly. A developer leaves; their PATs stay. A vendor integration gets set up for a 30-day trial; the OAuth token never gets revoked. An extension gets installed for one project and stays on the machine for three years.

The people-first part of this work is unglamorous. Someone has to own the inventory. Someone has to schedule the quarterly review. Someone has to be the person developers call when they are not sure whether to rotate a token or whether an extension is safe. That is the work — and it is the work AI does not do for you, no matter how amplified the rest of the stack gets.

Two minutes to find out where you stand: take our cybersecurity readiness assessment.

Common Questions

Should we assume our code was stolen?

Not necessarily. GitHub’s current statement is that the activity was limited to GitHub-internal repositories and there is no evidence customer repositories were accessed. That said, assume credentials connected to your account may have been exposed if any of your team’s machines run VS Code extensions with broad scope. Credential theft is the more immediate concern, because credentials get reused fast.

Do we need to change every password?

No — focus on GitHub-related credentials first: PATs, OAuth tokens, SSH keys, Actions secrets, and any password that has been reused across GitHub and another system.

Is GitHub Enterprise affected the same way?

GitHub Enterprise Cloud customers should treat this with the same urgency as GitHub.com users. GitHub Enterprise Server (self-hosted) has different exposure depending on the incident specifics — review GitHub’s official advisory for your deployment type.

Should we pause deployments?

If you can audit your CI/CD secrets and confirm no unauthorized workflow runs occurred in the past 72 hours, no. If you cannot confirm that quickly, a deployment freeze for 24 hours while you audit is reasonable.

What if we find evidence of unauthorized access?

Stop, document, and call your incident response provider before you remediate. Cleaning up evidence before it is preserved makes the investigation harder.

Which VS Code extension was used in the breach?

As of publication, GitHub has not publicly named the specific extension. Until they do, the safest assumption is that any extension with broad permissions could be a candidate, and the right move is to audit your full extension list now rather than wait.

Want to talk through your specific situation? Schedule a free 30-minute cybersecurity consultation — no pressure, no pitch.

Sources

Found this helpful? Share it with your network.
Twitter LinkedIn
Written by
centrexIT

The centrexIT team brings decades of combined IT expertise, helping San Diego businesses thrive with secure, reliable technology solutions.

Meet Our Team