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.
Editorial analysis by NHI Mgmt Group, based on content published by Corgea: “Five malicious IR.* NuGet packages impersonate Chinese .NET libraries”.
By the numbers:
- The campaign reportedly published 224 total versions across the five package IDs.
Key questions
Q: What breaks when a NuGet package can execute code during assembly load?
A: The assumption that restore is a passive supply-chain step breaks.
Q: Why do build and developer hosts make supply-chain credential theft worse?
A: They often hold the broadest mix of secrets in one place, including cloud tokens, registry credentials, SSH keys, browser passwords, and signing material.
Q: What are the signs that a NuGet package impersonation campaign is active?
A: Watch for unfamiliar package IDs that resemble internal libraries, exact-version installs of unlisted packages, suspicious outbound traffic from build jobs, and unexpected files created in locations that mimic legitimate vendor activity.
Practitioner guidance
- Audit NuGet package IDs and versions Search manifests, lockfiles, package caches, mirrors, and build logs for IR.DantUI, IR.Infrastructure.Core, IR.Infrastructure.DataService.Core, IR.iplus32, and IR.OscarUI, then remove any matching artifact from trusted paths.
- Block unlisted package installs by default Require explicit approval for unlisted external packages and unfamiliar package IDs that mimic internal libraries, especially where exact-version installs can bypass search visibility.
- Purge affected restore environments Clear local and shared NuGet caches on developer machines and CI hosts that restored the malicious packages, then reimage or rebaseline hosts that loaded the assemblies.
Bottom line: Malicious NuGet packages can turn ordinary restore activity into code execution when assemblies load, which makes package identity part of the attack surface.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
21/08/2026 5:12 pm
Package identity has become a security control, not just a supply-chain label. This campaign worked because the malicious packages looked like real .NET libraries and could still be installed by exact version even when unlisted from search. Dependency review that stops at reputation or hash comparison misses the governance problem: restore systems trust the package namespace before any code is executed. Practitioners should treat package admission as part of access governance, especially where build systems hold reusable credentials.
A few things that frame the scale:
- 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, according to the Ultimate Guide to NHIs.
- 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
A question worth separating out:
Q: How should teams respond when a build host restored a malicious package?
A: Treat the host as compromised, remove the package from every trusted cache and mirror, and rotate any secrets that were reachable from that machine. Then review restore logs and outbound network telemetry for evidence of package-triggered execution. The goal is containment before the stolen credentials can be reused elsewhere in the environment.
👉 Read our full editorial: Malicious NuGet packages turn routine restores into credential theft