Malicious NuGet Packages Impersonate Popular .NET SDKs

On July 20, 2026, our catalog flagged more than 20 malicious NuGet packages in a single day, most of them named to imitate legitimate .NET libraries. The batch includes fake versions of the Solnet Solana SDK, the Tessa document-management platform, the Stl.Fusion real-time framework, and a run of WPF and WinForms UI toolkits. Every entry is rated critical. This is one of the larger single-day clusters of malicious NuGet packages we have recorded, and it fits a pattern that has been building on NuGet since late 2025: attackers publish a package whose ID differs from a trusted library by a small change, often a .Net suffix, and wait for a developer to paste the wrong name into a project file.

The exact payload for this specific batch has not been detailed in a public vendor report at the time of writing. What we can state with confidence is the set of package IDs, the date they were flagged, and the libraries they impersonate. That is enough to check your own projects and lockfiles right now, which is the part that matters if any of these reached your build.

What happened

Our catalog recorded critical malware findings on 2026-07-20 for a group of NuGet package IDs that mirror well-known .NET components. Grouped by what they impersonate, the packages are:

Blockchain and crypto SDKs:

• solnetplus, solnetall, solnetall.net and solnetunified all echo Solnet, the .NET SDK for the Solana blockchain.
• SharpCashAddr.Core borrows a name associated with Bitcoin Cash address encoding.

Enterprise and document management:

• Tessa.Core, Tessa.Windows.V2, Tessa.Analyzer and Tessa.Postgre.Sql match the naming of the Tessa ECM and document-management platform.
• Syntellect.Winium.Element uses the Syntellect vendor name and the Winium Windows automation project.

.NET frameworks:

• Stl.Fusion.Ext.Services.Net, Stl.Fusion.Ext.Contracts.Net, Stl.Generators.Net and Stl.Rpc.Server.Net.Fx reuse the Stl.Fusion naming, the former name of the ActualLab.Fusion real-time framework.

Desktop UI toolkits:

• WindowsAPICodePack.Net mirrors the widely used Windows API Code Pack shell library.
• WpfLightToolkit.Net, Shade.WPF.Controls, Shade.UI.WinForms, Sanka.UI.WinForms, Sanka.UI2.WinForms and Sanka.UI3.WinForms are WPF and WinForms control packages.

Other:

• OtpCsharp reads as a one-time-password (TOTP) helper for C#.
• Rimworld.References.Net points at RimWorld game modders, who reference the game assemblies to build mods.

Two signals tie the group together. Almost every ID copies a recognizable library base name, and several append .Net, .Net.Fx, or a version fragment to a name that already exists on NuGet. That is impersonation, not accident. We are not attributing this to a named actor without a public analysis, but the shared technique and same-day timing point to coordinated activity rather than 23 unrelated uploads.

The naming trick

NuGet package IDs are global and first-come. If a well-known library ships as Solnet.Wallet, nothing stops another account from publishing solnetplus or solnetall.net. Developers search a package name, skim the results, and copy an ID that looks right. A .Net suffix on a package that is already a .NET package reads as harmless, which is exactly why it works.

This is a cousin of dependency confusion, where a public package with an internal name gets pulled ahead of the private one. Here the bait is a public name that sits next to a real, trusted package in search results. Both problems have the same fix on the consumer side: pin which source is allowed to serve which package ID.

Timeline

• Late 2025: researchers documented NuGet packages impersonating the Nethereum Ethereum library to steal wallet keys, reported by CyberSecurityNews and others in October 2025.
• November 2025: Socket researchers reported NuGet packages carrying time-delayed logic bombs aimed at .NET database code and industrial control systems, covered by Industrial Cyber.
• January 2026: ReversingLabs described NuGet malware built to steal crypto wallet data and OAuth tokens.
• February 2026: ReversingLabs reported a malicious NuGet package targeting Stripe integrations.
• July 20, 2026: our catalog flagged the 23 packages listed above, all rated critical.

The through line is consistent. NuGet has become a steady target for financially motivated crews, with crypto SDK impersonation and credential theft the most common goals.

Who is affected

Any .NET developer or build server that restored one of these IDs is in scope. The crypto-named packages (the Solnet copies and SharpCashAddr.Core) are the clearest risk, because Solana and Bitcoin Cash tooling handles private keys and wallet addresses. A stealer or clipboard hijacker in that path can drain funds.

The enterprise names widen the blast radius. Teams building on the Tessa document platform, on Syntellect tooling, or on the Stl.Fusion / ActualLab.Fusion framework may copy a plausible-looking add-on package without a second look. The UI toolkit names (WindowsAPICodePack, WPF, and WinForms controls) target ordinary desktop app teams. Rimworld.References.Net is aimed at hobbyist modders, who often run whatever a tutorial tells them to install.

One property of NuGet makes cleanup harder than a single project. Restored packages land in the global packages cache under ~/.nuget/packages, so one bad restore on a shared build agent can persist for other jobs until the cache is cleared.

How NuGet supply chain attacks work

NuGet does not run arbitrary lifecycle scripts the way npm historically did, so the mechanics differ from an npm postinstall stealer. Malicious NuGet packages generally reach code execution in one of three ways: they ship an MSBuild .targets or .props file that runs during build, they include tooling that executes as part of the developer workflow, or, most simply, they put the payload in the library itself so it runs the moment your code calls the referenced assembly. The last option matters here because a crypto SDK is imported specifically to sign transactions and touch keys.

We do not have a confirmed, public breakdown of the payload in this July 20 batch. Based on the well-documented NuGet campaigns of the past year, the common outcomes are wallet key and seed theft, clipboard hijacking that swaps a destination address at paste time, and exfiltration of tokens or environment variables. Treat any restore of these IDs as a possible secret exposure until you can prove otherwise.

How to check if you are affected

Search your repositories for the exact package IDs. Project references live in .csproj, .props, Directory.Packages.props, and legacy packages.config files.

grep -rIn -E "solnetplus|solnetall|solnetunified|SharpCashAddr\.Core|Tessa\.(Core|Analyzer|Windows\.V2|Postgre\.Sql)|Syntellect\.Winium\.Element|Stl\.(Fusion|Generators|Rpc)|WindowsAPICodePack\.Net|WpfLightToolkit\.Net|Shade\.(WPF|UI)|Sanka\.UI|OtpCsharp|Rimworld\.References\.Net" \
  --include=*.csproj --include=*.props --include=*.config --include=packages.lock.json .

List what actually restored into a project, including transitive dependencies:

dotnet list package --include-transitive

Check the global cache on developer machines and build agents:

ls ~/.nuget/packages | grep -iE "solnet|sharpcashaddr|tessa|syntellect|stl\.|windowsapicodepack|wpflighttoolkit|shade\.|sanka\.|otpcsharp|rimworld"

If nothing matches, you are almost certainly clear. If a name shows up, do not assume the version was benign; move to remediation.

Remediation

Remove the offending PackageReference and restore from a clean, known-good source. Then clear the caches so a poisoned copy cannot be reused:

dotnet nuget locals all --clear

Rebuild from a lockfile so you get deterministic restores going forward. Turn on lockfiles per project and enforce them in CI:

dotnet restore --use-lock-file
dotnet restore --locked-mode

Stop the impersonation class of attack with package source mapping in nuget.config. This pins each package ID pattern to an approved feed so a public impostor cannot slip in:

<packageSourceMapping>
  <packageSource key="nuget.org">
    <package pattern="Solnet.*" />
    <package pattern="*" />
  </packageSource>
  <packageSource key="internal">
    <package pattern="YourCompany.*" />
  </packageSource>
</packageSourceMapping>

If any crypto-related package restored on a machine that holds wallet keys, treat those keys as compromised. Move funds to a fresh wallet, rotate API tokens and OAuth credentials that the affected process could read, and review outbound network logs from build agents around the time of the restore. Report the packages to NuGet so they are pulled from the gallery, and check the maintainer account behind the legitimate library you meant to install to confirm it was not the one abused.

FAQ

Is the Solnet NuGet package safe to use?

The genuine Solnet packages (for example Solnet.Wallet on nuget.org) are the real Solana .NET SDK and are not part of this incident. The problem is the look-alikes: solnetplus, solnetall, solnetall.net, and solnetunified. Confirm the exact package ID and publisher before you restore anything Solana-related.

How do I know if I installed one of these malicious NuGet packages?

Grep your project files and lockfiles for the IDs listed above, run dotnet list package --include-transitive, and look in ~/.nuget/packages on every developer machine and build agent. A single hit means you should clear caches, rebuild from a clean source, and rotate any secrets the build could access.

Does NuGet run install scripts like npm does?

Not in the same way. NuGet with PackageReference does not run arbitrary install-time scripts, but packages can still execute code through MSBuild .targets and .props files during build, through bundled tooling, or simply when your application calls into the malicious assembly at runtime. Do not assume a NuGet package is inert just because it did not print anything during restore.

What should I do if one of these packages reached my build server?

Assume the agent handled secrets. Clear the NuGet caches with dotnet nuget locals all --clear, remove the package reference, rebuild from a locked restore, and rotate credentials, signing keys, and wallet material that the build process could read. Then add package source mapping so an impostor ID cannot resolve from the public feed again.