Notifications
Clear all
Topic starter
19/08/2026 3:31 pm
TL;DR: Eleven malicious NuGet DotnetTool packages disguised as game-cheat utilities staged a Windows payload, inherited cloud configuration through environment variables, and used Google Sheets, Cloudflare Worker, Telegram, and S3 fallback infrastructure for control and telemetry, according to Corgea. This is executable supply-chain risk, not just dependency hygiene: package registries can deliver code execution the moment a tool command is run.
NHIMG editorial — based on content published by Corgea: critical CVE analysis of malicious NuGet tool packages and staged Windows payload delivery
Questions worth separating out
Q: How should security teams handle malicious CLI tools in developer environments?
A: Treat them as code execution, not as low-risk utilities.
Q: Why do package-registry tools create more risk than ordinary libraries?
A: Because a tool package can execute immediately when installed and invoked, while a library usually needs an application to call it.
Q: What breaks when environment variables are used to pass control data into malware?
A: Standard host-based detection often misses the full chain because the downloader only needs to set values and launch a child process.
Practitioner guidance
- Classify CLI tools as executable software assets Require provenance review, allowlisting, and approval for any newly installed DotnetTool package on developer workstations and build hosts.
- Monitor tool-spawned process chains Alert on .NET tools spawning PowerShell, cmd.exe, or unusual child processes, especially when those processes perform DNS-over-HTTPS lookups or fetch binaries from external staging domains.
- Rotate and review workstation-exposed credentials Assume any developer endpoint that executed one of these tools may have exposed browser sessions, cloud keys, package tokens, or secrets entered during runtime.
What's in the full analysis
Corgea's full analysis covers the operational detail this post intentionally leaves for the source:
- Detailed package-by-package indicators for all 11 malicious DotnetTool IDs and their staged behaviours
- Code-level breakdown of the downloader logic, including mutexing, DNS-over-HTTPS resolution, and payload launch paths
- Host artefacts and hunting guidance for Windows developer workstations, package caches, and local tool manifests
- Infrastructure indicators tied to GitHub Releases, Hugging Face, Cloudflare Worker, Selcloud, and Telegram control paths
👉 Read Corgea's analysis of malicious NuGet tools and Windows payload staging →
NuGet tools as code execution: what AppSec teams need to watch?
Explore further
19/08/2026 4:14 pm
Package registries now function as executable trust boundaries: the meaningful question is no longer whether a package is a dependency or a tool, but whether the install path can execute code with the user's authority. That distinction matters because developer utilities frequently sit beside browser sessions, cloud credentials, and source control tokens. For AppSec and IAM teams, the control problem is provenance, execution, and credential containment, not package naming alone.
A question worth separating out:
Q: Who is accountable when a developer tool leads to credential exposure?
A: Accountability sits across endpoint security, identity governance, and the engineering team that approved or installed the tool. If the exposed material includes secrets or delegated access, the issue becomes an identity incident, not just a malware event. Frameworks such as NIST Cybersecurity Framework 2.0 and OWASP Non-Human Identity Top 10 support that shared ownership model.
👉 Read our full editorial: Malicious NuGet tools show how package registries enable code execution
