Between May 18 and May 19, 2026, the software supply chain experienced one of the most intense 48-hour attack waves ever recorded. Five distinct attacks targeted every layer of the development pipeline: a poisoned VS Code extension with 2.2 million installs, multiple compromised GitHub Actions, hijacked npm packages spreading via a self-replicating worm, and a trojanized PyPI package owned by Microsoft. The campaign culminated in GitHub itself disclosing that approximately 3,800 of its internal source code repositories were exfiltrated.
These are not theoretical risks. Microsoft and GitHub, two of the most security-mature organizations on the planet, were compromised through their software supply chains. Traditional security tooling (SCA scanners, SAST, EDR agents, CNAPP platforms) did not prevent these breaches. These tools were built for a different threat model. They scan source code for known vulnerabilities or monitor production infrastructure for anomalies. They do not monitor what happens inside a CI/CD runner at runtime. They do not track which VS Code extensions are installed on developer laptops. They do not detect when a trusted GitHub Action's tags are silently replaced with malicious imposter commits.
Stopping these attacks requires a solution built from first principles for the software supply chain, one that understands how developers build, how pipelines run, and where secrets flow.
The 48-Hour Timeline
The sheer density of incidents in this window is what makes the situation so alarming. Here is what unfolded.
These incidents follow a pattern that has been building for months. The node-ipc compromise on May 14 hit a package with 10 million weekly downloads. The Trivy GitHub Action compromise and Checkmarx KICS compromise in March demonstrated the same imposter commit technique now being used at scale. The adversaries have a proven, repeatable playbook, and they are accelerating.
The Entire Pipeline Is Under Attack
What makes this wave different from previous supply chain incidents is the diversity of attack vectors. These are not just malicious npm packages. The attackers targeted every stage of the software development and delivery pipeline, from the IDE on a developer's laptop to the CI/CD runner that deploys to production.
Consider the range of tools targeted in this wave alone. On one end, a VS Code extension, something that runs on individual developer laptops and has nothing to do with CI/CD or package registries. On the other end, a self-replicating npm worm that uses stolen tokens to propagate itself across the ecosystem. In between: imposter commits in GitHub Actions, trojanized PyPI packages published using compromised credentials for an official Microsoft SDK. The common thread is not the vector. It is the objective: steal credentials, exfiltrate secrets, and establish persistent access across the software supply chain.
The diversity matters because it exposes a fundamental gap in how most organizations think about supply chain security. If your strategy is built around a single control, whether that is a secure registry, a package scoring system, or a set of GitHub checks, you are only covering one layer of a multi-layer attack surface. A secure registry would not have stopped the Nx Console VS Code extension compromise. Package scoring would not have flagged actions-cool/issues-helper, which was a legitimate, trusted GitHub Action before its tags were hijacked. None of these controls operate at the CI/CD runtime layer where credentials are actually stolen from process memory.
Why Traditional Tools and Point Solutions Fall Short
The effectiveness of these supply chain attacks is not because attackers are using exotic techniques. It is because the attacks happen in environments that traditional security tools were never designed to monitor.
SCA (Software Composition Analysis) tools scan your dependency manifests for known CVEs. They are valuable, but they are reactive. A compromised package that has not yet been reported as a CVE, like durabletask during the 35-minute window between publication and discovery, sails right through. SAST tools analyze your source code, not the code running inside your CI/CD runner at build time. EDR agents protect production servers and employee laptops, but they do not run on ephemeral GitHub Actions runners. CNAPP platforms monitor cloud workloads, not the pipelines that deploy to them.
The same gap applies to point solutions that focus narrowly on one aspect of supply chain security. Package scoring and secure registries are useful controls for the dependency layer. They can flag suspicious npm or PyPI packages and enforce cooldown periods before new versions are consumed. But they represent one layer of defense for one attack vector. They do not provide:
Runtime security for CI/CD pipelines. When a compromised GitHub Action spawns a Python process that reads /proc/pid/mem to extract secrets from the Runner.Worker process, no package scanner or registry policy can detect or block that behavior. You need a runtime security agent on the CI/CD runner itself, one that monitors process behavior, enforces network egress policies, and can terminate jobs when anomalous activity is detected.
Visibility into developer machines. When a poisoned VS Code extension runs on a developer's laptop, stealing tokens from GitHub, npm, AWS, and 1Password, no CI/CD-focused tool has visibility into that environment. You need an agent that inventories IDE extensions, detects malicious behavior on developer workstations, and provides real-time search across your fleet when a new compromise is announced.
Ecosystem-wide threat intelligence and automated response. When a compromise is discovered, the first question is: "Are we affected?" If your tooling only covers package dependencies, you cannot answer that question for GitHub Actions, IDE extensions, or CI/CD runtime behavior. You need a platform that provides a unified view across all these vectors and can automatically block known compromised components before they execute.
The lesson from these 48 hours is clear: securing the software supply chain requires defense in depth across the full pipeline, not a single checkpoint at the registry layer.
StepSecurity's Research: Near Real-Time Detection, Community-Wide Impact
StepSecurity's threat intelligence team is consistently among the first in the industry to discover, analyze, and publicly report software supply chain compromises. The team uses a purpose-built combination of AI-powered monitoring and runtime analysis to detect breaches in near real-time. This approach, powered by the same Harden Runner telemetry and ecosystem monitoring that protects customers, enables StepSecurity to identify compromises as they happen rather than after they have already spread.
In this wave alone, StepSecurity published detailed analysis of the Nx Console VS Code extension compromise, the actions-cool/issues-helper GitHub Action compromise, the Microsoft durabletask PyPI attack, and the latest Shai-Hulud worm campaign, in each case being one of the first companies to report the incident with full technical details and IOCs. Earlier this year, StepSecurity was among the first to report on the axios npm compromise, the Trivy GitHub Action compromise, and earlier waves of the Shai-Hulud campaign. Several of these reports have been credited and cited by maintainers, CISA, and the broader security community.
This research is not just thought leadership. It feeds directly into the StepSecurity platform. When the threat intelligence team publishes IOCs for a new compromise, those indicators are immediately available in the Threat Center, integrated into Compromised Actions policies, and used by Harden Runner to block exfiltration to known malicious domains. The time between discovery and automated protection across all customer environments is measured in minutes.
How StepSecurity Covers the Full Pipeline
The StepSecurity platform was built from the ground up to secure the software supply chain end to end. Rather than focusing on a single layer, it provides independent security controls at every stage of the development and delivery pipeline. These controls work together so that even if an attacker bypasses one layer, they are caught at the next. Here is how each control maps to the attacks from the past 48 hours.
The matrix above tells the story. No single column covers every row. But every row has multiple checkmarks. That is defense in depth in practice. Here is what each control does.
Dev Machine Guard provides two critical detection capabilities for developer workstations. First, it maintains a real-time inventory of IDE extensions and developer tools across your fleet. When a dev tool compromise like the Nx Console extension is announced, you can immediately search whether any developer in your organization has the affected version installed. This is the control that addresses the attack vector that breached GitHub, and it is one that no CI/CD-only solution can replicate. Second, it inventories npm, Python, and other open-source packages installed on developer machines, so when a compromised package like durabletask or a Shai-Hulud worm target is identified, you can determine exposure across your developer environment before those packages ever reach a build pipeline.
Harden Runner is the runtime security agent for GitHub Actions. It monitors process behavior and enforces network egress policies on CI/CD runners. In block mode, it prevents credential exfiltration by dropping connections to any domain not on the allowlist. In audit mode, it flags anomalous connections and process behavior. When the compromised actions-cool action or the Shai-Hulud worm attempts to read /proc/pid/mem and POST stolen secrets to an attacker-controlled domain, Harden Runner detects and blocks that behavior at runtime. This is the layer that package scanners and secure registries cannot provide.
Compromised Actions Policy acts as a pre-execution gate. Once the StepSecurity Threat Center identifies a compromised GitHub Action, the policy automatically cancels any workflow run that references it, across your entire organization. This provides immediate protection in the window between discovery and when individual teams update their workflow files.
Threat Center delivers real-time notifications when new supply chain compromises are identified. It integrates with SIEM platforms (Splunk, Sentinel) and notification channels so the right people on your team are alerted the moment a new incident is published.
Secure Registry (Beta) acts as a proxy between your builds and public package registries. By applying a cooldown policy, freshly published package versions are held back until they have been evaluated, preventing the scenario where a malicious version is pulled and installed within minutes of publication, as happened with Microsoft's durabletask.
Package Search scans your default branch and open pull requests for known compromised npm, PyPI, and other open-source packages. When a malicious package version is identified, Package Search flags every repository in your organization that references it, covering both code that is already merged and code that is in review. For the Shai-Hulud worm and the durabletask compromise, this provides immediate visibility into which repositories have the affected dependency in their lockfiles or manifests.
GitHub Checks enforce cooldown period verification, pwn request detection, and script injection analysis on every pull request, catching supply chain risks before they reach your main branch.
The diagram below shows how these controls map to the attack lifecycle. Click any layer to see how it applies to the incidents from the past 48 hours.
What We Expect Next
Based on the pattern we are seeing, we anticipate more incidents in the coming days and weeks. The adversaries behind these attacks, particularly TeamPCP and the actors operating the Shai-Hulud worm, have demonstrated a playbook that is effective and scalable. They compromise a trusted package or action, inject credential-stealing malware, exfiltrate secrets, and then use those stolen credentials to compromise additional packages, creating a self-reinforcing cycle.
The techniques are sophisticated and evolving: imposter commits in GitHub Actions, WAV steganography for hiding payloads, DNS tunneling for exfiltration, dangling orphan commits in legitimate repositories for payload hosting, and process memory reading for extracting masked secrets. Each new incident introduces a variation that tests whether defenders are relying on signatures or on fundamental security controls.
The fact that Microsoft and GitHub were both impacted in this wave should remove any doubt about whether software supply chain attacks are a real and present threat. These are organizations with world-class security teams, and they were compromised through vectors that their existing security infrastructure was not designed to cover.
Take Action Now
For StepSecurity Enterprise Customers
We strongly recommend confirming the following capabilities are enabled in your environment:
1. Threat Center Notifications. Set up notification channels and confirm the right people on your team are receiving Threat Center alerts, so you hear about newly identified compromises the moment they are published.
2. Dev Machine Guard. Ensure coverage across your developer machines so you can immediately search whether any compromised IDE extension, npm package, or Python package is installed in your environment.
3. Compromised Actions Policy. Enable automatic blocking of workflow runs that reference any GitHub Action known to be compromised.
4. Harden Runner. Deploy on your GitHub Actions workflows to detect and block credential exfiltration from CI runners. If you are currently in audit mode, consider moving to block mode for your most sensitive workflows.
5. Secure Registry (Beta). If you use JFrog or Google Artifact Registry, configure Secure Registry as the upstream for npm and apply a cooldown policy so freshly published packages are not pulled immediately.
6. GitHub Checks. Enable StepSecurity GitHub checks for cooldown period enforcement, pwn request detection, and script injection analysis.
If you need help enabling any of these or want us to review your current configuration, reach out to your StepSecurity contact. We are actively monitoring the situation and will share updates as more details emerge.
For the Community: Get Started for Free
You do not need to be an enterprise customer to start protecting your projects today. StepSecurity offers free community resources that use the same detection capabilities behind the incidents described in this post.
Harden Runner is free for open-source repositories. It provides runtime security, network egress monitoring, and anomaly detection for your GitHub Actions workflows at no cost. If you maintain open-source projects, adding Harden Runner to your workflows gives you immediate visibility into suspicious network connections and process behavior on your CI runners.
Dev Machine Guard offers a free version that gives you visibility into IDE extensions and packages installed on your developer machines. When the next compromise is announced, you can instantly check whether your environment is affected.
StepSecurity Blog is a free source of supply chain threat intelligence. We publish detailed technical analysis with indicators of compromise, affected versions, and remediation steps for every major software supply chain incident. Bookmark the blog or follow us on X to stay informed as new compromises are discovered.
For organizations that need full coverage across their entire pipeline, including Compromised Actions Policy, Threat Center, Secure Registry, and org-wide incident response, request a demo to see how the StepSecurity platform can protect every layer of the development pipeline.
We are actively monitoring the situation and will share updates as new incidents emerge.
