TL;DR
- 2026’s supply chain breaches share one pattern: stolen credentials make valid, authenticated API calls that gateways and WAFs never flag.
- Nx Console (May 2026) is the clearest example: a poisoned VS Code extension led to 3,800 exfiltrated GitHub repositories via legitimate API access.
- CISA linked it to Megalodon, a parallel campaign harvesting CI/CD secrets through malicious GitHub Action workflows, same mechanism, different vector.
- Gateways check if a call is valid. They don’t check if it fits how that identity normally behaves, which is exactly the gap stolen tokens exploit.
- Closing it means baselining developer tools, CI/CD systems, and AI agents as API clients, AppSentinels’ focus.
The Part of a Supply Chain Attack That Actually Does the Damage
Most coverage of software supply chain attacks focuses on the entry point: the poisoned package, the compromised maintainer account, the malicious commit. That’s the part that makes headlines, but it’s rarely the part that causes the damage. A malicious package sitting on a developer’s machine doesn’t exfiltrate anything by itself. The damage happens in the second stage, when the code that got in starts making API calls with credentials it found lying around, to services that have no reason to question a request that looks completely normal.
That second stage is an API security problem, and it’s largely an unmonitored one. Once a workstation, a CI/CD runner, or an agentic tool is compromised, everything that follows is a sequence of authenticated API requests, to GitHub, to AWS, to a secrets manager, to a package registry. Each of those requests, taken alone, is indistinguishable from legitimate developer activity, because it’s made with a legitimate credential. That’s the mechanism worth understanding, because it’s the same one showing up across a growing list of 2026 incidents.
The Pattern in Practice: What Happened at GitHub
In May 2026, Nx Console, a VS Code extension with more than 2.2 million installs, briefly shipped a poisoned update. What followed shows exactly how the entry point and the actual breach are two different things:
- The poisoned update spread fast and quietly. It was live on the Marketplace for about 18 minutes before researchers flagged it, but VS Code’s auto-update pipeline had already pushed it to an estimated 6,000-plus machines, far more than the 28 downloads the Marketplace’s own counter recorded.
- One of those machines belonged to a GitHub employee. The extension didn’t need to break into anything. It read GitHub, AWS, npm, and other credentials already sitting in local config files and active sessions.
- The credentials were then used to make ordinary-looking API calls. Real tokens, real endpoints, during a normal work window, indistinguishable from a developer’s own traffic.
- GitHub assessed that those calls led to roughly 3,800 exfiltrated internal repositories.
- The incident is tracked as CVE-2026-48027. CISA added it to its Known Exploited Vulnerabilities catalog on May 27, 2026, with a federal remediation deadline that has since passed.
The credential theft was the entry point. The API calls that followed were the breach.
This Isn’t an Isolated Case
The same second-stage pattern shows up repeatedly across 2026’s supply chain activity, which is why it’s worth treating as a category rather than a single incident.
- The credential source was itself a supply chain compromise. The developer credentials used to publish the poisoned Nx Console build were obtained through an earlier attack on the TanStack npm ecosystem, tracked as CVE-2026-45321. That attack, in turn, relied on the same mechanism: a stolen publishing token used to make legitimate-looking package registry calls.
- CISA has now linked a second, parallel campaign. In the same advisory that covered Nx Console, CISA described a campaign called Megalodon, in which a threat actor injected malicious GitHub Action workflows into public repositories to harvest CI/CD secrets and cloud credentials. The mechanism is identical to the IDE extension case: valid credentials, used through an automated pipeline, making API calls that fit the shape of normal CI/CD traffic.
- The threat actor behind Nx Console, tracked as TeamPCP or UNC6780, has a documented pattern of doing this repeatedly, with prior compromises linked to security and developer tooling including Trivy, Checkmarx’s KICS, LiteLLM, and other packages. Each compromise follows the same two stages: get a credential in, then let that credential’s API access do the work. The stolen GitHub data itself was listed for sale on a cybercrime forum, with reported asking prices ranging from $50,000 to over $95,000.
Three different vectors, an IDE extension, a CI/CD workflow, and a package registry, and the same second-stage mechanism each time. That repetition is the actual signal here, more than any individual CVE.
Why This Keeps Getting Past API Security Tools
Run any of these incidents through a conventional API gateway or WAF and every request passes. The tokens are valid. The endpoints are the ones that get hit constantly. Nothing exceeds a rate limit, and no payload violates a schema. Gateways are built to answer one question: is this individual request well-formed and authenticated? They were never built to answer the question that actually matters in a supply chain attack: does this request fit the pattern of how this identity normally behaves?
That’s the structural gap. A workstation that suddenly starts authenticating to services it has never touched, seconds after an unreviewed extension update, is not something a schema check or a rate limiter will ever catch, because nothing about the individual call is malformed. The same is true for a CI/CD identity that starts reading secrets it has no history of touching. Security teams describing these incidents keep landing on the same phrase: the tools see the requests, they don’t see the story.
Developer Tools and CI/CD Pipelines Are API Clients Now
The reason this pattern keeps repeating is that the assumptions underlying API security haven’t caught up with what’s making API calls. A typical developer workstation authenticates to cloud providers, package registries, and internal platforms constantly, and every IDE extension or CLI tool running on it inherits that access. A typical CI/CD pipeline does the same thing on a larger, more automated scale. None of these are treated as API clients in the way a mobile app or a partner integration is, even though functionally, that’s exactly what they are: authenticated, programmatic consumers of APIs, at a scale and speed no human reviews in real time.
Agentic AI tools sit on top of the same problem. As AI coding assistants and autonomous agents get plugged into the same credentials and API access developers already have, the number of automated identities making API calls on a developer’s behalf keeps growing, while the visibility into whether those calls fit a normal pattern stays flat.
What Actually Needs to Change
Closing this gap isn’t about adding another layer of credential scanning or another marketplace vetting step, though those controls still matter and should stay in place. It’s about watching behavior over time instead of validating requests one at a time.
- Baseline how each identity normally uses its access. A developer workstation, a CI/CD runner, and an AI agent all have a typical pattern of which APIs they call and when. That pattern is the thing worth monitoring, not just whether a given call carries a valid token.
- Flag sequence breaks, not just malformed requests. A credential suddenly reaching services it has never touched, right after an extension update or workflow change it didn’t initiate, is the signal that matters. No single request in that sequence looks wrong on its own.
- Treat every automated identity as an API client, deliberately. IDE extensions, CI/CD workflows, and AI agents all carry the same access a developer has. Extending the same identity and sequence monitoring used for external-facing APIs to these internal, machine-driven clients closes the exact gap the Nx Console and Megalodon incidents both exploited.
This is the layer AppSentinels’ business logic security approach is built to add: baselining how identities and tools actually use API access, then surfacing the moment that pattern breaks, before a stolen credential turns into a multi-thousand-repository breach.
The Lesson Underneath the Headlines
Every incident in this pattern shares the same underlying fact: the credentials were valid, the endpoints were normal, and nothing failed a permission check, because nothing was technically broken. The failure was contextual, not cryptographic. That’s true whether the entry point is a poisoned VS Code extension, a trojanized GitHub Action, or the next automated developer tool that gets compromised.
The perimeter for API security was never just the network edge. It’s the sequence of what a trusted, credentialed identity does once it’s already inside, and until that sequence gets watched as closely as the individual request, this pattern will keep repeating with a different entry point each time.
Ready to see how your own API traffic would hold up to this kind of scrutiny? Book a demo.
Frequently Asked Questions
Why are software supply chain attacks considered an API security problem?
Because the damage in these attacks happens after the initial compromise, when stolen credentials are used to make authenticated API calls to cloud providers, code hosts, and internal platforms. Those calls use valid tokens and hit normal endpoints, so traditional API gateways and WAFs, which check whether individual requests are well-formed, have no basis to flag them as malicious.
What was the Nx Console incident, and how does it fit this pattern?
Nx Console is a VS Code extension with over 2.2 million installs that briefly shipped a poisoned update in May 2026 (CVE-2026-48027). The update harvested developer credentials, which were then used to access GitHub’s internal infrastructure and exfiltrate roughly 3,800 repositories. It’s a clear example of the broader pattern: the entry point was a compromised extension, but the actual breach happened through valid API calls made with stolen credentials.
Is this only a risk in IDE extensions?
No. CISA formally linked the Nx Console case to a separate campaign called Megalodon, in which malicious GitHub Action workflows harvested CI/CD secrets and cloud credentials through the same mechanism. The same risk applies anywhere an automated tool, whether an IDE extension, a CI/CD pipeline, or an AI coding agent, holds API access on a developer’s behalf.
Why don’t API gateways or WAFs catch this kind of attack?
Gateways and WAFs validate individual requests: is the token valid, is the payload well-formed, is the endpoint correct. A stolen credential making calls within its normal permissions passes every one of those checks. What’s missing is behavioral context, whether the sequence and pattern of those calls match how that identity normally acts, which requires monitoring over time rather than per-request validation.
How does AI agent adoption change this risk?
AI coding assistants and autonomous agents typically inherit the same API access and credentials a developer already has, which increases the number of automated identities making API calls without expanding the visibility into whether those calls fit a normal pattern. That makes behavioral, identity-aware monitoring more important as agentic tools take on more of a developer’s day-to-day API activity.
What can security teams do about this today?
Beyond standard hygiene, minimum publisher trust, pinned dependencies, and credential rotation, teams should treat developer tools, CI/CD identities, and AI agents as API clients whose behavior can be baselined. Watching for sequence breaks, such as a credential suddenly reaching services it has no history with, catches the pattern these attacks rely on, even when every individual request looks legitimate.
