New: Major version 1.0 officially released
New: Major version 1.0 officially released
New: Major version 1.0 officially released
New: Major version 1.0 officially released
New: Major version 1.0 officially released
Learn how Endura Security collects, processes, protects, and retains personal information across our website, products, services, and recruiting.
May 21, 2026
6 Min Reads
Endura Security
There is a comforting story the software industry likes to tell itself about supply chain security: if we know what we use, verify where it came from, and pin the important things, we can reduce the problem to inventory and provenance. The last two weeks broke that story. The newest wave of software supply chain attacks did not arrive as one poisoned package waiting to be found by a scanner. It moved across the entire software delivery system: a VS Code extension on a developer workstation, GitHub Actions with silently replaced tags, npm packages carrying a self-replicating worm, a Microsoft-owned PyPI package, and finally GitHub's own internal repositories. The breach was not a component. The breach was the build environment. That distinction matters. A component is something you can list in an SBOM. A build environment is where credentials, source code, package managers, cloud accounts, deployment permissions, AI tools, and developer trust all collide. Attackers have stopped treating those pieces as separate targets. They now treat them as one connected system. Defenders need to do the same.
Between May 18 and May 19, 2026, researchers reported one of the densest supply chain attack waves in recent memory. The incidents were varied, but the objective was consistent: steal credentials, use those credentials to reach the next trusted system, and keep the chain moving. The wave included a poisoned Nx Console VS Code extension with more than two million installs, compromised GitHub Actions, a self-replicating npm campaign, and three malicious versions of Microsoft's durabletask package on PyPI. GitHub later confirmed that an employee device was compromised through a poisoned VS Code extension and that approximately 3,800 internal repositories were exfiltrated, while stating there was no evidence that customer repositories outside the affected internal repositories were broadly exposed. Independent analysis of the durabletask incident reported that versions 1.4.1, 1.4.2, and 1.4.3 were published to PyPI on May 19 using a compromised PyPI API token rather than the project's normal GitHub release workflow. That is not a dependency management problem. That is a software delivery control problem.
Look at the layers involved:
The common thread is not npm. It is not PyPI. It is not VS Code. It is not GitHub Actions. The common thread is runtime access to secrets inside trusted development and build environments.
The TanStack compromise is the most important signal in this wave because it punctures a dangerous assumption. On May 11, malicious versions were published across dozens of @tanstack/* packages. The alarming part was not simply the number of artifacts. It was how they were published. Researchers reported that the packages were published by TanStack's legitimate release pipeline using its trusted OIDC identity after attacker-controlled code hijacked the runner mid-workflow. The packages could carry valid SLSA provenance because the build system really did build and publish them. The certificate was not forged. The trust boundary had moved underneath it. This is the uncomfortable lesson: provenance can be accurate and still be insufficient. A provenance attestation answers important questions. Did this artifact come from the expected project? Was it built through the expected pipeline? Which identity published it? Those are valuable controls, and organizations should keep investing in them. But provenance does not answer the question that mattered during this wave: what did the artifact, action, extension, or build step actually do when it ran? Did it read /proc/<pid>/mem from the GitHub Actions runner? Did it scan ~/.aws/credentials, ~/.npmrc, ~/.ssh/, .env, or 1Password-related files? Did it make outbound connections to a domain no build step had ever contacted before? Did it spawn bun, python, curl, or a downloaded binary from a script that should have performed a routine install? Those are runtime questions. Static controls cannot answer them after the code has already been trusted into execution.
For years, software supply chain security focused on open-source dependencies because dependencies were the obvious ingestion point. That was never wrong. It is just no longer complete. The newest attacks are aimed at the convenience layer developers rely on to move faster. Unit 42's ongoing npm threat analysis describes the same larger shift: wormable propagation, infrastructure-level persistence, and multi-stage payloads are becoming part of the new baseline.
This layer exists because it makes engineering teams productive. It automates the repetitive work, smooths the workflow, and removes friction. Attackers love it for the same reason. Anything that reduces friction for developers can reduce friction for malware once trust is established. The poisoned VS Code extension is a perfect example. An extension does not have to look like a dependency to be part of your supply chain. If it runs in the environment where code is written, reviewed, committed, signed, built, or deployed, it is part of the supply chain. If it can reach credentials, it is a supply chain risk. If it can shape the output of software delivery, it is a supply chain dependency whether or not it appears in a package manifest.
Modern supply chain programs are much better than they were a few years ago. SBOMs are more common. Dependency scanners are better. Package reputation systems are improving. Sigstore, SLSA, and OIDC-based publishing have raised the floor for many ecosystems. These controls matter. But the May 2026 wave shows that attackers have adapted around them. They are not only sneaking malicious code into unknown packages. They are compromising trusted tools, hijacking legitimate release pipelines, replacing mutable tags, and abusing the runtime privileges of systems that already passed the trust checks. That creates a gap between artifact trust and execution trust. Artifact trust asks whether the thing appears legitimate before it runs. Execution trust asks whether the thing behaves within a defined boundary while it runs. Most organizations have invested heavily in artifact trust. Far fewer can enforce execution trust inside CI/CD runners, build hosts, and developer tool environments. That is the gap attackers are exploiting.
Consider the behaviors repeatedly reported across recent campaigns:
Those behaviors are not subtle at the kernel level. They are only subtle when your controls stop at the manifest, repository, registry, or attestation layer.
The old supply chain question was: "Do we depend on the compromised package?"
The new question is: "What could the compromised component reach when it executed?"
That question is harder, and it is more important. A malicious package installed in a clean sandbox with no secrets and no network access is annoying. The same package running in a CI/CD job with npm publish rights, cloud credentials, GitHub tokens, SSH keys, and deployment permissions is a business-level incident. This is why credential rotation has become the default cleanup recommendation after these attacks. It is also why credential rotation alone is not enough. Rotation is what you do after you assume the attacker got what they wanted. Runtime enforcement is how you prevent the credential from leaving in the first place.
The uncomfortable truth is that many build environments still contain far more authority than any single build step should have. A test job can see publish tokens. A package install can reach cloud credentials. A linter can make unrestricted outbound network connections. A GitHub Action can run arbitrary code while secrets are present in process memory. A VS Code extension can live beside local source code, terminal access, AI agent configs, and cloud profiles. Attackers are not guessing. They are mapping exactly where the secrets live and building malware to harvest them at runtime.
Endura's eBPF-based platform is built around the premise that supply chain defense cannot stop at inventory. It has to observe and enforce what software is allowed to do while it runs.
That is why the latest attack wave maps directly to Endura's value. These incidents were not primarily about vulnerable code patterns. They were about unauthorized runtime behavior:
~/.npmrc, ~/.ssh/, ~/.aws/credentials, Kubernetes configs, environment files, password-manager artifacts, or developer tool configs.
Endura operates below the compromised component, below the package manager, below the action, below the extension, and below the script. At the kernel level, intent does not matter. The behavior does.
A policy can say that during npm install, processes may connect to the package registry but not arbitrary external hosts. A policy can say that a documentation build may read the repository but not ~/.ssh/id_rsa. A policy can say that a test step may execute known interpreters but not a downloaded binary in a temporary directory. A policy can say that no build process may read another process's memory. When that line is crossed, the kernel enforces the decision before the secret leaves.
That is the difference between knowing you were exposed and preventing the exposure from becoming a breach.
The practical response is not to abandon SBOMs, SLSA, signatures, or dependency scanning. Those controls are necessary. They are just not sufficient. The more strategic response is to update the operating model for software supply chain defense:
1. Treat developer tools as production-grade attack surface. IDE extensions, AI coding assistants, MCP servers, local package caches, and helper CLIs deserve the same scrutiny as build infrastructure because they often hold the same credentials.
2. Stop relying on mutable trust. Pin GitHub Actions to immutable commit SHAs where possible. Apply cooldown periods to new package releases. Review newly published versions with extra skepticism, especially when automatic updates are enabled.
3. Separate credentials by job, not just by team. A build step should not receive publish tokens unless it publishes. A test step should not receive cloud deployment credentials. Package installation should not run in the same authority zone as production release.
4. Enforce runtime behavior in CI/CD. Every build should have explicit expectations for file access, network access, process execution, and memory access. Anything outside those expectations should be blocked or at least surfaced immediately with process ancestry.
5. Make blast radius measurable. When the next compromise is announced, the first question should not take days of manual repository and laptop checks. Security teams need fast answers: where did this component execute, what did it access, what network connections did it make, and which credentials were reachable?
The latest supply chain breaches are not random spikes in a noisy ecosystem. They are evidence of a structural shift. Attackers are no longer satisfied with poisoning a package and hoping someone installs it. They are targeting the systems that build, sign, publish, extend, automate, and accelerate software delivery. That means the point of control has moved. It is no longer enough to ask whether a package is known, signed, scanned, or attested. The decisive question is what that package, action, extension, or agent is allowed to do once it is trusted enough to run. Endura Security was built for that question. Inventory tells you what is present. Provenance tells you where it came from. Runtime enforcement tells you whether it is behaving like software you intended to run, or like an attacker wearing your build system's badge. The build is now the breach surface. It is time to secure it like one.
Learn how Endura Security's eBPF-based platform provides runtime enforcement across your CI/CD pipelines and production workloads. Request a demo to see how kernel-level policy enforcement blocks credential theft, unauthorized network connections, anomalous process execution, and runtime behavior that static supply chain controls miss.
Ready to put this into practice?
