GitHub Lost 3,800 Private Repos to a Single Extension. Your EDR Won’t Catch the Next One Either.

Key Takeaways

• GitHub lost 3,800 private repos to a single trojanized VS Code extension — proof that endpoint and network controls don’t see what happens inside an authenticated session.
• Extensions don’t bypass MFA; they operate after it. Once installed, they inherit session tokens, cookies, and active-tab permissions, and update silently in the background.
• Active extension hygiene — continuous discovery, permission-change monitoring, and automated enforcement across every browser — is the control that closes the gap your EDR can’t see.
  

GitHub — the company that hosts the source code for 90% of the Fortune 100 and 180 million developers — was recently compromised. Not by a nation-state zero-day. Not by an infrastructure exploit. By one employee installing a poisoned VS Code extension.

The trojanized version of the Nx Console extension was enough to exfiltrate roughly 3,800 internal repositories before the device was isolated and the extension was pulled from the marketplace. GitHub has since linked the incident to the broader TanStack npm supply-chain campaign, and the TeamPCP group — the same crew behind earlier supply-chain hits on PyPI, NPM, and Docker — claimed credit on a cybercrime forum, asking $50,000 for the haul.

Point is… if you wrote a check last month for “endpoint security” and you’re not asking hard questions about extension hygiene today, you’re funding the wrong control plane.

A few weeks ago I wrote about the “Verified” lie — the 1-million-user “Save image as Type” extension that turned out to be malicious despite its 4.2-star rating and verified badge on both the Chrome and Edge stores. The Nx Console incident is the same pattern, executed against arguably the most security-aware engineering organization on earth. Different store. Different victim. Same architecture. Same blind spot.

The Cognitive Dissonance Has a Name

When a security team approves a new SaaS whiteboard, it triggers weeks of due diligence. Legal review. SOC2 audit. Compliance questionnaire. Procurement sign-off.

When a developer installs a browser or IDE extension that lands directly inside the authenticated work session — with permissions to cookies, scripts, active tabs, session tokens, and clipboard contents — the gate is one click and a checkbox.

The asymmetry is the story. Procurement frameworks were designed for software that sits outside the user’s session and asks for access. Extensions sit inside the session by default. They inherit the keys at install time and then update themselves silently in the background. The check-box review at install is the last security event in the extension’s lifecycle, and it’s the wrong one to focus on.

Extensions Don’t Pick the Lock. They Inherit the Keys.

An extension isn’t a backdoor. It’s a wide-open front entry that the user holds open.

Once the install completes, the extension operates after MFA, after TLS termination, after the session is authenticated and the data is decrypted. From inside that envelope, three things happen automatically:

• It can read the session. Session cookies, OAuth tokens, anything in the page DOM, anything the user types. To the extension, that’s all in-scope data.
• It can act as the user. Outbound requests carry the user’s identity. To the SaaS app on the other end, an exfiltration looks like normal authenticated traffic. To the network, it looks like a legitimate session talking to a legitimate destination.
• It can update silently. Browsers and IDEs update extensions in the background. The extension that earned the user’s trust on Tuesday is not the extension running on their machine Friday.

The GitHub engineer who installed the trojanized Nx Console almost certainly had EDR/XDR on the device, code-scanning plugins in the environment, and enterprise network monitoring on the traffic. None of it mattered, because none of it was looking at the right layer.

Why Your Endpoint and Network Stack Are Structurally Blind to This

EDR is built to protect the device OS. It watches process behavior, file system changes, memory operations. A browser or VS Code process is a legitimate user-mode process running a legitimate user’s session — and once an extension is inside that session, its exfiltration looks like normal HTTPS traffic from a normal authenticated user.

Network controls are built to protect the perimeter. They see destinations, IPs, ports, and increasingly TLS metadata. They don’t see what’s happening inside the session — the extension that’s running, the permissions it’s holding, the scripts it’s executing, the destinations it’s reaching from inside an authenticated user’s browser.

Securing the device and the network are still valid controls. They’re just looking at the wrong layer for this threat. Credentials, SaaS data, AI prompts, file movements, repository access — all of it lives inside the authenticated session, above where EDR and network tools are positioned to inspect.

This is the architectural point: The enforcement point isn’t broken. What’s missing is visibility inside the session — above the packet, past the process, where the user and the extension are actually interacting with the app.

What Active Extension Hygiene Actually Looks Like

Manual quarterly audits are dead on arrival. Extensions update in the background, between audits. Hygiene that runs at the speed of procurement can’t defend against a threat that runs at the speed of background sync.

The framework I laid out in the previous piece still holds — Discover, Review, Control, Monitor, Repeat — but the operative word is continuously. Discovery is the precondition for everything else, and most organizations can’t tell you, today, every extension installed across every browser and IDE in their environment, with the permissions each one is currently requesting and the version each one is currently running.

That’s not a process gap. That’s a visibility gap. And it’s the one Red Access is built to close.

The platform discovers and inventories every extension across Chrome, Firefox, Safari, and Edge — active, disabled, and even those installed in private sessions — including extension ID, developer, store reputation, permissions, signing status, version, and risk score.

It correlates extension presence with the network traffic those extensions are actually generating, so a quiet “volume booster” that suddenly starts beaconing to a new domain or asking for scripting and all_urls becomes a policy event, not a footnote in a quarterly report.

And it does this agentlessly, on any browser, on managed and unmanaged devices alike — which matters, because the contractor working on a personal laptop is exactly the user a managed-browser strategy doesn’t reach.

This is Session Detection and Response. EDR watches the browser. SDR watches what happens inside it — any browser, even the desktop apps that are really just browsers in disguise.

The Real Question

The Nx Console breach is the proof of concept attackers were running on a quieter scale for years. GitHub had the budget, the team, and the threat model to catch this — and they got caught anyway, because the architecture of how extensions inherit session permissions doesn’t bend to budget.

Your extension policy is either active or it’s aspirational. There is no third option.

If you want a one-page checklist for running your first real Extension Audit — the same one I shared after the “Verified” piece — download it here.

If you’d rather see what an active inventory looks like across your own environment, we can show you in an afternoon.

Get the full checklist: