Notifications
Clear all
Topic starter
21/08/2026 4:55 pm
TL;DR: Five malicious NuGet packages published under a single account hid a Reactor-protected infostealer that activates when assemblies are loaded, putting .NET developer workstations, build hosts, and internal mirrors at risk according to Corgea. The campaign shows why package identity, restore-time trust, and credential scoping now matter as much as signature checks and hash-based blocking.
NHIMG editorial — based on content published by Corgea: malicious NuGet packages impersonating .NET libraries and stealing credentials
By the numbers:
- The campaign reportedly published 224 total versions across five package IDs, with most older versions unlisted but still installable by exact version.
Questions worth separating out
Q: What breaks when a malicious package executes at module load time?
A: Install-time scanning can miss the abuse because the payload does not need a lifecycle hook.
Q: Why do developer build hosts increase the impact of package supply-chain attacks?
A: They often hold the exact assets attackers want: SSH keys, cloud tokens, signing material, registry credentials, and cached service secrets.
Q: What do security teams get wrong about package hash blocking?
A: Hash blocking is useful, but it does not solve package identity risk when the same malicious package name is republished in multiple versions or hidden through unlisting.
Practitioner guidance
- Hunt for the affected package IDs across the full software estate Search dependency manifests, lockfiles, package caches, internal registries, and build logs for IR.DantUI, IR.Infrastructure.Core, IR.Infrastructure.DataService.Core, IR.iplus32, and IR.OscarUI, then treat any host that restored or loaded them as compromised.
- Purge and re-seed package caches after exposure Remove local and shared NuGet caches that contain the package, then rebuild from a verified upstream or internally signed source so old binaries cannot be reintroduced through cached artifacts.
- Rotate every secret reachable from affected developer and CI hosts Reset cloud keys, package registry tokens, GitHub tokens, SSH keys, browser-saved credentials, and wallet material that may have been accessible from the infected environment, and assume session theft even if no exfiltration alert fired.
What's in the full analysis
Corgea's full analysis covers the operational detail this post intentionally leaves for the source:
- Exact package IDs, publisher patterns, and versioning behaviour that help defenders build detection logic
- Indicators of compromise including host paths, domains, and network endpoints observed in the campaign
- Remediation workflow details for removing packages, purging caches, and resetting credentials at scale
- Cross-platform loader behaviour on Windows, Linux, and macOS builders that affects CI triage
👉 Read Corgea's analysis of malicious NuGet packages targeting .NET developers →
NuGet supply chain abuse: what .NET teams need to check now?
Explore further
21/08/2026 5:12 pm
Package identity, not just package content, is now a governance control. This campaign works because the attacker preserved a believable library identity while changing the payload beneath it. That undermines dependency trust models that rely on name familiarity or simple signature checks. For .NET teams, package approval must become a lifecycle control that covers new IDs, unlisted versions, and mirror hygiene, not only vulnerability scanning.
A question worth separating out:
Q: How should security teams respond when a build may have run malicious dependency code?
A: Treat it as a potential credential incident, not just a software issue. Revoke exposed tokens, rotate any secrets available to the build host, inspect package provenance, and review source control and registry activity for follow-on abuse. Build compromise often becomes identity compromise very quickly.
👉 Read our full editorial: Malicious NuGet packages turn routine restores into credential theft
