GitHub just admitted that one of its own engineers handed attackers the keys to 3,800 internal repositories. The opening move was a poisoned VS Code extension. The rest happened on a laptop.

That’s the story you should be telling your board this week. Not the latest ransomware briefing, not the AI threat report. A single trusted workstation, inside one of the most security-conscious vendors on the planet, lost source code access at scale because the device running the IDE was treated as a productivity tool instead of a privileged system.

The cybersecurity industry keeps talking about supply chain risk as if it’s something that happens to other people. GitHub just demonstrated it happens to the people running the supply chain.

One Laptop, 3,800 Repos

TeamPCP, the group behind the intrusion, got in with an extension. No zero-day required. The employee installed it, the extension did what it was built to do, and the lateral movement followed naturally from the access that workstation already held.

Think about what’s on a senior developer’s machine at a major platform. Cached git credentials with broad scope. Active SSO sessions to internal tooling. Signed-in cloud CLIs. Personal access tokens with longer lifetimes than anyone admits. Maybe a kubeconfig or two. An AI assistant with read access to the codebase.

Call it what it is. That laptop is a privileged jump host that happens to also run Slack.

And the same week GitHub disclosed this, Kaspersky published details of CVE-2026-3102 in ExifTool, where a malicious image alone can compromise a Mac. Different bug class, same target. The endpoint is the soft surface every attacker wants to land on, and the people we hand the loudest privileges to are the ones running the most third-party code.

The Marketplace Trust Problem

Editor extensions are the most aggressive code execution channel most companies allow by default. They run inside the IDE process. They see every keystroke, every open file, every active credential the editor can reach. They auto-update without anyone reviewing the diff.

Most security teams have a list of approved browser extensions. They have an EDR allowlist. They don’t have an approved VS Code extension list, and if they do, nobody enforces it. The marketplace itself does some vetting, which is exactly why people install whatever they want without thinking twice about it.

GitHub’s own employee did the same thing you’d do.

This is a trust-by-default problem dressed up as productivity. Brute-force attempts against your firewall are noisy and slow. An extension running inside a sanctioned process moves at the speed of clipboard access.

What Actually Helps

You can’t ban developers from installing extensions and still expect them to ship code. The fix is to stop treating their laptops like ordinary corporate endpoints and start treating them like the production-adjacent systems they are.

Concrete actions worth taking this quarter:

• Inventory editor extensions across your fleet. Use endpoint telemetry to enumerate VS Code, JetBrains, and Cursor installs by hostname. You probably can’t lock it down yet, but you can’t even start until you can see it.
• Shorten the lifetime of every credential that touches a dev laptop. Personal access tokens, cloud CLI sessions, package registry tokens, signing keys. Rotate aggressively and scope tightly. Long-lived broad-scope tokens are how a single workstation becomes a 3,800-repo breach.
• Segment code-host access. Production write access, signing, and release tagging should not share an SSO session with day-to-day pulls. Require step-up authentication for the privileged actions.
• Monitor outbound traffic from developer endpoints to code hosting and package registries. Unusual download patterns, repo enumeration, and bulk clones from a single host are detectable signals.
• Run new extension installs through a security-reviewed allowlist. Yes, developers will complain. Yes, this is worth the friction.

For incident response, build a playbook specifically for compromised developer endpoints that assumes every credential cached on the device is burned. Treat the response like a stolen domain admin laptop, because functionally that’s what it is. Rotation, session revocation, and audit-log review across every connected SaaS need to happen in parallel, not sequentially.

Defense in depth narrows the blast radius. A poisoned extension is an initial access mechanism. What it gets to depends on identity hygiene, network egress controls, and code-host audit logging. Each layer shaves down what an attacker can do with the foothold.

Security hardening on the workstation helps as well. Application allowlisting, EDR with behavioral threat detection, restricted local admin, and disk-level controls all raise the cost. None of them stop a malicious extension running inside a sanctioned IDE process, which is why the controls upstream of the editor and downstream of the credentials matter even more.

GitHub will issue a postmortem. There will be language about defense in depth and lessons learned. The actual lesson is simpler. The developer laptop is the perimeter now, the credential vault, and the production system rolled into one. Treat it accordingly or stop being surprised when one extension takes down 3,800 repositories.

Sources

• GitHub confirms breach of 3,800 repos via malicious VSCode extension
• GitHub Confirms Hack Impacting 3,800 Internal Repositories
• How an image could compromise your Mac: understanding an ExifTool vulnerability (CVE-2026-3102)