The Safeguard Research team spent the first quarter of 2026 ingesting every newly published version across the five largest open-source ecosystems, scoring each release for malicious intent, and tracking how attacker behaviour shifted against the baseline we established through 2024 and 2025. This post summarises the methodology we used, the numerical findings we trust, and the defensive moves we are recommending to platform and application teams for the rest of the year.
The short version: raw publish volume continues to climb, but the share of clearly malicious packages has stayed within a narrow band. What has changed is sophistication. More samples now survive static triage, more samples are multi-stage, and attackers are increasingly tuning payloads to build systems rather than developer laptops. We think this is the story of 2026 so far.
How did the Safeguard Research team collect and classify the data?
We classified malicious publishes by combining static signals, dynamic sandbox behaviour, and registry metadata into a single per-version score. The data set covers npm, PyPI, RubyGems, Maven Central, and crates.io from 1 January through 31 March 2026.
For every new version, we executed three passes. The first pass is static: we parse install scripts, lifecycle hooks, obfuscated strings, embedded URLs, and anomalous file types. The second pass is dynamic: we install the package inside a disposable container with instrumented network, filesystem, and process hooks, and we record any outbound connections, file reads against known secret paths, and child process spawns. The third pass is metadata: account age, publish cadence, maintainer overlap with known-bad clusters, and registry-side signals such as 2FA status and typo distance to popular names.
A version enters our "confirmed malicious" bucket only when at least two of the three passes agree. This keeps our false-positive rate low enough to publish numbers that platform teams can plan around.
What is the volume picture for Q1 2026?
Confirmed malicious publish counts are consistent with late-2025 levels, in the low thousands per month across all five ecosystems combined, with npm and PyPI carrying roughly three-quarters of the total.
We saw no single week with a month-scale spike, which is a shift from 2023 and 2024 where coordinated campaigns occasionally produced multi-thousand package bursts in a single weekend. Instead, Q1 looked like steady background radiation with occasional bursts of fifty to two hundred related packages tied to a single actor cluster.
The share of confirmed-malicious versions as a percentage of total new publishes sits in the low single digits of a single digit, somewhere between 0.1% and 0.3% depending on ecosystem and week. That ratio has been stable for four consecutive quarters now.
Which attack techniques dominated this quarter?
Typosquatting and starjacking are still the most common static patterns, but the most damaging category was post-install credential harvesting targeted at CI runners.
Typosquats and lookalikes accounted for roughly 45% to 55% of confirmed malicious publishes, depending on the ecosystem. These are cheap to produce and still work against hurried developers. PyPI saw a steady stream of names swapping hyphens for underscores and relying on PEP 503 normalisation quirks. npm saw a mix of scope hijacking attempts and Cyrillic homoglyph variants.
The category that moved the most was CI-aware payloads. We classify a payload as CI-aware when it reads for GITHUB_ACTIONS, CI, GITLAB_CI, or similar environment variables and changes behaviour based on the result. In Q1 2026, CI-aware samples were roughly twice as common as they were a year earlier. Typical behaviour: silent on a developer laptop, aggressive exfiltration of environment variables, OIDC tokens, and cloud credentials when running inside a CI container.
Protestware and sabotage packages, which peaked in 2022 and 2023, are now a minor slice of the data, usually in the low single-digit percentages.
Where are attackers sending exfiltrated data?
Bespoke command-and-control infrastructure is giving way to abuse of legitimate developer services as the exfiltration channel.
In Q1, Discord webhooks, public paste services, and specific Telegram bots remained common low-effort destinations. What grew meaningfully was the use of services that application developers already trust: requestcatcher-style inbound URLs, ephemeral tunnelling services, and abused analytics endpoints. A smaller but notable slice routed stolen data through attacker-controlled GitHub Gists and public repositories, which makes retroactive takedown much slower.
The operational consequence for defenders is that egress allow-listing purely on domain reputation is no longer sufficient. If your build environment can reach a general-purpose HTTPS endpoint on the public internet, it can reach an exfiltration destination.
How long are malicious packages staying live before removal?
Median time-to-takedown has improved meaningfully, but the long tail remains a problem.
Across npm and PyPI we observed median removal times in the sub-24-hour range for flagged-by-automation cases, often inside a handful of hours for ecosystems with mature trust-and-safety pipelines. This is a clear improvement over the multi-day medians common in 2022.
The long tail is the problem. Roughly 10% to 15% of confirmed-malicious versions survived longer than seven days, and a small percentage survived for more than thirty days. These long-lived samples were disproportionately low-download packages whose maintainers had been silently compromised, where nothing about the package naming or obvious install behaviour stood out. Once mirrored into proxies and lockfiles, they can persist in builds long after the registry-side version is removed.
What defensive steps matter most right now?
The highest-leverage moves this quarter are CI environment hardening, egress controls, and replacing version ranges with lockfile-verified installs.
First, treat your CI runners as the crown jewel. Scope cloud credentials issued to jobs to single-use, short-lived, least-privilege. Prefer OIDC federation with narrow audience claims over long-lived access keys. Deny outbound traffic from build steps to anything that is not an explicit dependency mirror, and log every blocked attempt.
Second, pin and verify. Lockfiles, integrity hashes, and signed provenance attestations for anything you ship. Do not install with loose version ranges in CI. A floating minor version is an unreviewed dependency upgrade every build.
Third, quarantine new dependencies. A package that is less than seventy-two hours old, has no prior maintainer history, or has metadata inconsistencies should not land directly in a production build. A simple maturity policy catches a meaningful slice of this quarter's attacks without blocking legitimate updates.
Fourth, monitor for the CI-aware behaviour class specifically. A package that silently probes for CI environment variables during install is rarely benign, and that check is cheap to implement as a gate.
What does this mean for the rest of 2026?
We expect the volume to stay in the current range and the sophistication to continue climbing, especially around CI-targeted payloads, package maintainer account takeovers, and abuse of legitimate developer services as exfiltration channels. The centre of gravity for open-source malware is no longer the developer laptop. It is the build system.
That reframes what "supply chain security" has to mean in practice. A scanner that only looks at your merged source code and your production runtime is blind to the window where most of the damage now happens.
How Safeguard.sh Helps
Safeguard.sh scores every dependency update for known malicious patterns, CI-aware payloads, and maintainer anomalies before the update reaches your build. Our research telemetry feeds the same detection engine our customers run, so the techniques described here are already gated by default. When a new typosquat or compromised version appears, Safeguard surfaces it against the specific services and CI pipelines you run, with the evidence and the patch path in one place. Platform teams use us to enforce dependency maturity policy, block suspicious install-time behaviour, and keep a clean, attested inventory of what actually shipped. If the trend lines in this post worry you, that is the problem we exist to solve.