The NuGet gap Shai-Hulud exposed — and what we built to close part of it)

Abel Solutions — Fri, 24 Jul 2026 13:44:04 +0000

In September 2025, security researchers disclosed Shai-Hulud: a self-propagating worm that spread through the npm ecosystem by stealing maintainer credentials and using them to publish malicious versions of legitimate packages. CISA issued an alert within the week. By the time the dust settled, reporting put the number of poisoned packages above 500, including widely used libraries like @ctrl/tinycolor. The mechanism was the interesting part: compromised packages scanned the developer or CI environment for npm tokens, GitHub personal access tokens, and cloud credentials, then used whatever they found to publish more malicious versions — automated propagation, not a single actor manually re-uploading. A second wave, reported in late November 2025, showed the technique hadn't gone away.

None of that is .NET's problem, directly. But it raised an honest question for anyone shipping C# for a living: if the equivalent happened to a popular NuGet package tomorrow — a maintainer's account compromised, a malicious version pushed under a trusted name — what, exactly, would stop it from landing in your build the same day?

What NuGet actually has

To answer that fairly, it's worth listing what already exists, because it's more than "nothing."

Package signing. Authors can sign packages, and every package accepted onto nuget.org is automatically repository-signed. Verification is available via dotnet nuget verify, and starting with the .NET 8 SDK, signature verification is enabled by default using a certificate trust list Microsoft ships with the SDK. This establishes provenance and integrity — the package you're restoring is the bit-for-bit artifact that account uploaded, unmodified in transit.
Package ID prefix reservation. Organizations can reserve an ID prefix after a domain-verification process; once reserved, nuget.org rejects any new package under that prefix from a different account. This is a real defense against someone else publishing packages under your reserved namespace — an impersonation control, not an anti-typosquatting one (it doesn't stop a similarly-named-but-different prefix like Newtonsoft.Jso).
Trusted Publishing (OIDC). For CI-driven releases, nuget.org now supports exchanging a short-lived GitHub Actions OIDC token for a single-use, ~1-hour NuGet API key — removing the need for long-lived publish secrets sitting in CI, which is exactly the kind of credential Shai-Hulud went looking for on the npm side.

All of that is real, and none of it is nothing. It's also all aimed at the same layer: proving who published this and that it wasn't tampered with in transit. Signing answers "is this the artifact that account uploaded." It does not answer "should I trust code from a brand-new version of this package the moment it lands."

The gap: nothing gates on trust, and nothing gates on time

Two things are true at once, and neither is a NuGet-specific failing — npm has the equivalent gaps, just a different attack surface (install-time scripts by default, versus automatic build-time hooks for .NET). The ecosystems evolved different defenses on different timelines.

First: a signed, ID-verified package can still be malicious. Signing proves identity and integrity, not intent. If an attacker compromises the account that owns a reserved prefix, or if a malicious actor legitimately owns the identity they're publishing under, every defense above passes cleanly.

Second — and this is the part with a documented track record in .NET specifically — NuGet packages can carry executable logic that runs during build, not just at runtime. MSBuild supports inline tasks and .targets/.props files shipped inside a package's build/ folder. For PackageReference projects, those files get referenced through generated .nuget.g.targets/.props during restore, but the code inside them only executes when MSBuild subsequently evaluates and builds the project — restore alone doesn't run it. (Legacy install.ps1/init.ps1 scripts are a separate, older mechanism scoped to packages.config projects and the Visual Studio Package Manager; they don't apply to PackageReference projects at all, and they don't fire on dotnet restore either.) Researchers documented real campaigns exploiting the build-time mechanism — the "IAmReboot" wave in 2023 used malicious .targets files that fired, in ReversingLabs' own words, "every time package A is built." That's actually a sharper contrast with Shai-Hulud than a restore-time claim would be: npm's payload runs at install time, shipped as a postinstall hook that npm install executes automatically with no opt-out short of --ignore-scripts. NuGet's equivalent mechanism fires one step later in the pipeline — a dotnet build against a poisoned dependency can still execute attacker code before a single line of your own application code compiles, just not at the restore step itself.

And there's no cooldown anywhere in the pipeline. A version published ninety seconds ago restores exactly the same as one published two years ago. Nothing in the default toolchain treats "brand new" as a signal worth pausing on — and plenty of documented malicious-package campaigns, on NuGet and npm alike, get caught by security researchers days to weeks after publication, not before.

What NuGate does about it

We built NuGate as a dependency age gate. That's the whole scope, and we kept it that way deliberately: the build fails if any resolved package version — direct or transitive — was published less than a configurable number of days ago (seven, by default), unless it's explicitly allowlisted.

It ships as two pieces. NuGate.Tool is a dotnet CLI (nugate check) meant to run in CI between restore and build — gating before the next build ever runs, so a malicious .targets file in a freshly restored package never gets the chance to execute. That directly targets the build-time-execution gap above. NuGate.Build is an MSBuild task added as a single PackageReference in Directory.Build.props, gating every build in a repo including developers' own machines, hooked in after package assets resolve and before compilation starts. A thin GitHub Action wraps the CLI for workflow use.

The age comes from nuget.org's immutable catalog created timestamp — not the registration published field, which nuget.org resets to a sentinel value when a version is unlisted. A version that gets pulled after a compromise is discovered is flagged as a violation regardless of its age, closing that particular loophole. Failures are closed by default: if the nuget.org API is unreachable and age can't be determined, that counts as a violation rather than a silent pass. Config lives in a single nugate.json — minimum age, enforce vs. warn mode, an allowlist with optional expiry dates so exceptions don't quietly become permanent, and prefix exemptions for internal packages that never touch nuget.org.

Equally important is what it doesn't do. NuGate does not detect malware, does not scan package contents, and does not prevent attacks. A compromised package that's thirty days old passes the gate exactly the same as any other dependency, by design. A cooldown shrinks the window in which a freshly poisoned version can reach a build — it does not close that window, and it says nothing about what's inside the package. Anyone evaluating it should read it as a narrow, boring control, not a security product.

Where to find it

We've released NuGate as open source, Apache-2.0, under the AbelSolutions-io GitHub organization. It installs from NuGet — NuGate.Tool for CI, NuGate.Build for the MSBuild integration. Issues and questions are welcome on the repo. There's a small landing page with a longer explanation of the cooldown model at nugate.dev if you want more than this post covers.

No pricing, because there isn't any.

DEV Community: Abel Solutions

The NuGet gap Shai-Hulud exposed — and what we built to close part of it)

What NuGet actually has

The gap: nothing gates on trust, and nothing gates on time

What NuGate does about it

Where to find it