SUMMARY: Since September 2025, a related — but not identical — family of credential- and identity-abuse techniques has hit a widening set of open-source tools, culminating in a breach of GitHub’s own internal systems. Some of these incidents are demonstrably connected; others merely share tactics or timing. This piece is explicit throughout about which is which.
- A related family of credential- and identity-abuse techniques, not one single reused exploit, appears across at least a dozen open-source compromises since September 2025 — some confirmed as connected, others linked only by shared tactics or timing
- Read together, the incidents show attackers moving toward higher-value targets over time — a scanning tool, a CI pipeline, a developer’s own editor, and finally GitHub’s internal systems — though not every step is proven to have directly caused the next
- Culminated in a trojanized VS Code extension, reportedly live for somewhere between 11 and 18 minutes depending on the source, that GitHub says led to roughly 3,800 internal repositories being accessed
- npm’s strongest architectural fix shipped two days after GitHub disclosed its own breach, with full rollout not scheduled to complete until 2027.
A Trojanized Extension, an Employee’s Laptop, and 3,800 Repositories
On May 18, 2026, a malicious version of Nx Console — a Visual Studio Code extension with more than 2.2 million installs — was published to the Visual Studio Marketplace at 12:36 p.m. UTC, carrying a verified-publisher badge, the kind of tool developers install without a second thought. Hidden inside was a payload that ran automatically the moment a developer opened any workspace, fetching and executing a credential stealer.
How long the malicious version stayed live depends on which account you read. Nx’s own postmortem and several independent write-ups put the Visual Studio Marketplace exposure at about 11 minutes; GitHub’s own CISO, in a later statement, described it as live for “just 18 minutes”. The discrepancy hasn’t been publicly reconciled — it may come down to differing start/end points, or which registry (Marketplace vs. the Open VSX registry, where exposure ran longer) each source was measuring. Either way, it was long enough: the malicious extension reportedly landed on the device of an employee at GitHub — the company that hosts and runs npm, the huge shared library of free, reusable code that most JavaScript software is built from. Two days later, GitHub confirmed what a group calling itself TeamPCP was already claiming on a hacking forum: attackers had accessed roughly 3,800 of GitHub’s internal repositories and claimed to be offering the data for sale at a floor price of $50,000.
GitHub has said customer repositories and account data were not affected, and that assessment has held up as the investigation continued. The Hacker News reported that the trojanized extension was designed to harvest credentials from 1Password vaults, AI coding tool configurations, npm, GitHub, and AWS access from any workspace a developer opened it in. The same malware family and threat-actor branding have been tied, with varying degrees of confidence, to at least a dozen other compromises since March — in some cases through reused infrastructure or shared malware code, in others only through similar tactics or rough timing, a distinction this piece tries to preserve throughout rather than collapse into a single narrative.
Why This Isn’t Just Another Breach Story — and Where the Evidence Gets Thinner
Cybersecurity journalism produces a steady stream of “package X was compromised” stories, and it is easy to read each one as a discrete event with a discrete fix: rotate the token, patch the pipeline, move on.
Read together, several of these incidents point toward a shared underlying assumption in how software registries work: that anything capable of authenticating as a trusted maintainer is treated as one. That reading is well supported for some of the incidents below, where the same threat actor, malware, or infrastructure is directly documented. For others, the connection is looser: shared tactics, overlapping timing, or a common technique lineage, without public evidence of a single coordinating actor or campaign. Treat the throughline that follows as this piece’s evidence-based interpretation of a pattern, not as a proven, unified conspiracy — and note that this piece focuses on one attack lineage among several that occurred in the same period; other significant supply-chain incidents, and mitigations that worked, sit outside its scope.
The Precedent: Shai-Hulud
The current cycle has a clear starting point. In September 2025, researchers at ReversingLabs discovered a self-replicating worm called Shai-Hulud spreading through npm via compromised maintainer accounts, ultimately touching hundreds of packages and millions of downloads. In response, GitHub — which operates npm — announced it would require two-factor authentication (a second, live proof of identity beyond just a password, like a code sent to your phone) for local publishing, and cap token lifetimes at seven days. It also pushed harder on “trusted publishing,” a scheme that lets CI/CD systems — the automated pipelines that build, test, and ship software without a person clicking “publish” each time — authenticate with short-lived, cryptographically scoped credentials instead of long-lived tokens.
Security researchers largely welcomed the changes. Contrast Security co-founder Jeff Williams told ReversingLabs that moving from long-lived tokens toward short-lived, workflow-bound credentials removed one of the main tools attackers reach for once they compromise an account or pipeline. He also flagged a limit, though: credential hardening alone does nothing about malicious insiders or maintainers compromised through some other channel entirely.
That caveat turned out to matter.
Twelve Days in March: A Chained Set of Compromises
Between March 19 and March 31, 2026, five widely used open-source projects were compromised in rapid succession: Aqua Security’s Trivy vulnerability scanner, Checkmarx’s AST GitHub Action, the AI-proxy library LiteLLM, the Telnyx communications SDK, and the HTTP client Axios — a project downloaded over 100 million times a week, among the most widely used packages in the JavaScript ecosystem. Independent analysis from DreamFactory and threat research from Zscaler’s ThreatLabz both mapped a similar underlying mechanism across most of these incidents, though the two writeups emphasize different pieces of it and aren’t identical accounts.
Four of the five — Trivy, Checkmarx, LiteLLM, and Telnyx — are attributed to a group tracked as TeamPCP. The group first exploited a misconfigured GitHub Actions workflow (an automated script that runs routine jobs, like building or testing code, without human involvement) in Trivy’s own repository to steal a maintainer’s access token — a long-lived digital key that lets software, not just a person, prove it’s allowed to publish updates. According to DreamFactory’s analysis, Aqua Security’s credential rotation after the breach was discovered was incomplete. That let TeamPCP hijack 75 release tags (the labels marking which version of the code is the official, downloadable one) and compromise images on Docker Hub, a widely used distribution hub for pre-built software packages. The same analysis reports this reportedly infected more than a thousand cloud environments — an estimate this piece could not independently verify against Aqua Security’s own numbers.
From there, the stolen CI/CD credentials were reportedly reused to authenticate as a legitimate publisher on PyPI, the Python-language equivalent of npm, pushing malicious versions of LiteLLM. One of those versions used a Python .pth file — a legitimate, obscure packaging feature that executes automatically on every Python process startup — to harvest cloud tokens and SSH keys without the LiteLLM package itself needing to be imported. Telnyx was compromised through a similar chain of stolen access days later. Researchers characterize this sequence as a chained credential handoff, each theft funding the next, though not every individual credential in the chain has been publicly confirmed as coming from the prior breach rather than a separate access point.
Worth sitting with regardless of how tightly linked each step turns out to be: the first target was a vulnerability scanner, a tool organizations install specifically to catch this kind of threat, running with the elevated CI/CD permissions that made it valuable to attackers in the first place.
The Axios compromise, on March 30, has not been attributed to TeamPCP and looks operationally distinct — Zscaler’s writeup describes it as attributed to a North Korean threat actor, using a cross-platform remote-access trojan (malware that lets an attacker remotely control an infected computer as if sitting at the keyboard) built for macOS, Windows, and Linux. The malware was reportedly staged for eighteen hours before release and designed to self-delete and replace its own manifest — the file listing what a package contains and does — to frustrate forensic review. Rather than exploiting a misconfigured pipeline, the attacker reportedly took over the lead maintainer’s npm account directly and manually published two malicious versions, bypassing the project’s automated GitHub Actions publishing pipeline and, with it, any protection from trusted publishing’s identity checks. The registry’s strongest available defense at the time only protects packages published through the automated pipeline; an attacker who owns the human maintainer’s account can simply not use that pipeline at all.
Whether the Axios operator and TeamPCP are connected remains, as far as public reporting shows, unresolved — different sources attribute the two campaigns to different actors, and that inconsistency is worth flagging rather than smoothing over.
The Escalation: From Packages to the Registry’s Own Operator
TeamPCP did not stop in March. In April, the group reportedly backdoored a malicious npm package impersonating the Bitwarden CLI — the command-line tool for the popular password manager. To be precise: this was a lookalike package published to npm under a name resembling the official one, as Palo Alto Networks’ Unit 42 documented; Bitwarden’s own infrastructure and legitimate package were not themselves breached.
Then, on May 11, the group carried out a materially different kind of attack. Rather than stealing a maintainer’s long-lived credentials, it chained three separate weaknesses in TanStack’s own GitHub Actions automation — a workflow trigger that let a forked pull request run with write access, a poisoned build cache, and a short-lived identity token extracted directly from the automation runner’s own memory — to hijack TanStack’s legitimate, already-trusted publishing pipeline. The Hacker News reported that the resulting malicious packages, spreading under the name “Mini Shai-Hulud,” carried valid cryptographic proof that they were built by TanStack’s own trusted pipeline — because they genuinely were — and propagated into packages tied to Mistral AI’s official SDK and others, ultimately touching more than 170 packages across npm and PyPI. No long-lived maintainer credentials were stolen in this wave; a short-lived identity token was extracted instead, which is itself a form of credential, just a narrower and shorter-lived one. The attackers made the legitimate system vouch for their code rather than stealing a key to it — arguably a harder problem to defend against than classic credential theft.
Then, on May 18, the group compromised Nx Console. According to OX Security researcher Nir Zadok, as quoted by The Hacker News, this happened after the attackers first breached one of the extension’s own contributors — reportedly connected to the earlier TanStack compromise — then used that access to push the trojanized update. A VS Code extension runs with the same operating-system-level privileges as the editor itself: no sandbox (no isolated, restricted zone limiting what it’s allowed to touch, the way a phone app is typically walled off from the rest of the device), no permission prompt, full access to whatever tokens and keys happen to be sitting on that machine. When it reached a GitHub employee’s laptop, it did what it was built to do, and what was there was a path into roughly 3,800 of GitHub’s own repositories.
Multiple independent outlets — Help Net Security, Sophos, Security Affairs, and Varonis — corroborate the core facts as GitHub itself disclosed them: an employee device compromised through the extension, roughly 3,800 internal repositories accessed, and no evidence to date of customer-facing impact. TeamPCP — tracked separately by Google’s Threat Intelligence Group under the internal designation UNC6780 — has claimed credit and is reportedly seeking a buyer. GitHub said it rotated affected credentials in order of impact and began an internal incident-response investigation. GitHub’s CISO later confirmed Nx Console as the specific extension involved, but the company still has not detailed, as of publication, the precise internal path from one compromised employee device to repository-level access on GitHub’s systems.
Root Cause: One Reading of Why the Defenses Kept Falling Short
It’s tempting to read this as a story about one unusually persistent threat actor. This piece reads it differently, as analysis rather than an established fact the reporting itself asserts: across the incidents above, the recurring failure point is that registries and CI/CD tooling have, for years, optimized for automation convenience over verifying a human was actually present.
Long-lived publish tokens exist because rewriting every CI/CD pipeline to use short-lived, workflow-bound credentials is expensive and disruptive. “2FA-bypass” granular access tokens — a special category of npm credential created specifically to let automated pipelines skip the live two-factor check, on the premise that an automated pipeline can’t hold up a phone — exist for the same reason: requiring a live authentication challenge on every automated publish would break existing release pipelines. GitHub’s own engineering team acknowledged this trade-off directly in a public changelog post: a leaked bypass token, the post notes, can be used to change an account’s email, mint new tokens, add a maintainer, and publish malicious versions “with no human present.” That description lines up closely with what happened to Trivy and LiteLLM, and in a different form, to Axios.
npm’s response, made generally available on May 22 — two days after GitHub disclosed its own breach — is called staged publishing. Under the new model, a package uploaded by an automated pipeline sits in a holding queue until a human maintainer separately authenticates with two-factor authentication and explicitly approves it. That’s a real architectural change, not just a policy reminder: a stolen automation token alone can no longer push a package live. It arrived, though, after eight months and multiple documented compromises built on exactly the gap it closes, and the older, weaker path isn’t fully closed yet. According to GitHub’s own engineering changelog, the ability of legacy 2FA-bypass tokens to perform sensitive account actions is scheduled — as announced, and subject to change — to be shut off in early August 2026, with their ability to publish directly at all scheduled to disappear around January 2027.
What Remains Unknown
Several load-bearing questions in this story do not yet have public answers. GitHub has confirmed Nx Console as the extension involved in its breach, but has not detailed the exact internal path from the compromised employee device to repository-level access — the developer-device link is reported by The Hacker News and echoed elsewhere, but GitHub’s own public statements have stopped short of that level of technical detail. Whether the Axios operator and TeamPCP are the same actor, coordinating actors, or entirely unrelated groups that struck in the same twelve-day window remains contested across the sources reviewed for this piece. GitHub’s assessment of “no customer impact” is explicitly described by the company as based on an ongoing investigation, so it isn’t yet possible to treat that finding as final. And several of the numerical estimates in this piece — the “more than a thousand cloud environments,” the exact minute count the malicious extension was live, the precision of “a dozen” linked compromises — come from third-party security-vendor analysis rather than from GitHub, Aqua Security, or npm directly, and should be read with that provenance in mind.
It’s also worth being explicit about scope: this piece traces one lineage of related incidents. Other significant software supply-chain attacks occurred during the same period and are not covered here, and some mitigations — 2FA enforcement, trusted publishing, staged publishing — have measurably reduced certain attack paths even as others opened up. A narrative built entirely around escalation risks making the defenses look more uniformly ineffective than the fuller record supports.
Why It Matters Beyond This Incident
The specific packages named in this piece — Trivy, LiteLLM, Axios, Nx Console — will fade from the headlines. The pattern connecting several of them, read as this piece’s interpretation rather than a settled finding, looks like a credential model built around a convenient assumption: that a token is a reliable stand-in for a person. The attackers behind these incidents didn’t need novel exploits to test that assumption. They needed persistence, a handful of misconfigured pipelines, and eight months to move from a vulnerability scanner to, eventually, the company that runs the registry itself.
Staged publishing, disallowed bypass tokens, and mandatory live 2FA at the moment of publish are real, structural improvements, not just advisories telling developers to be more careful. But this wave is a reasonable prompt to reconsider how the industry judges “fixed.” A defense that closes the exact gap the last attacker used, arriving after the next attacker has already moved to a different link in the chain, is still catching up rather than getting ahead. Organizations that want to get ahead of the next version of this story might reasonably start by asking whether their own automation still assumes a token is a person, before an incident measured in minutes answers that question for them.
