Malicious NuGet package targets Stripe

In December 2025, the ReversingLabs research team wrote about a malicious NuGet campaign that targeted developers and packages linked to cryptocurrency platforms such as Coinbase, Binance, Solana and Nethereum.

Following that, the malicious NuGet activity appeared to slow. However, our researchers recently discovered a malicious package that mimics Stripe.net, a NuGet package by the popular online payments platform with more than 70 million downloads. 

The latest incident shows that while the threat actors have shifted away from blockchain-related targets on NuGet, they remain active and focused on the financial sector.

What to know about the development environment

Stripe is a popular, online financial services platform used by businesses to accept payments online, do billing, invoicing and more. Stripe handles the complex parts of moving money, such as processing credit cards, managing subscriptions and keeping transactions secure so that businesses can focus on their work and let Stripe do the heavy lifting for transactions.

To aid developers who want to integrate Stripe’s platform with applications, the company offers an official NuGet package, Stripe.net, which is used by developers to integrate Stripe from apps built with Microsoft’s .NET platform. With more than 74 million downloads since its release, Stripe.net is a helper library that makes it much easier for .NET programmers to communicate with Stripe’s online payments API from their code, abstracting away the complexity of handling raw HTTP requests, authentication, error handling, data serialization and more into a simple, easy to use library which contains all the necessary classes and methods.

If this package were to be compromised by a malicious threat actor, any applications that rely on it could unknowingly expose sensitive payment data, API keys or customer information. They could even manipulate transactions, or gain access to Stripe accounts.

Imposter Package: StripeApi.net

Of course, compromising a package maintained by a large software firm like Stripe isn’t easy. So, rather than targeting the official Stripe.net NuGet package directly, the malicious actors opted for an easier alternative: “typosquatting,”or publishing a similarly named package in the hope of tricking developers looking for the actual Stripe.net package to download and install it. The name of that typosquatting package is StripeApi.Net.

Figure 1: Fake package

The NuGet page for the malicious package is set up to resemble the official Stripe.net package as closely as possible. It uses the same icon as the legitimate package and contains a nearly identical readme, only swapping the “Stripe.net” references to read “Stripe-net.”(Mind the dash!) Links for the project website and repository lead to official Stripe assets, and the tags are identical to those used on the official Stripe.net NuGet page. The package owner's name is “StripePayments” which is another effort to make this package seem legitimate. The only notable difference is that the owner has the default NuGet profile picture - as opposed to the official one, which uses Stripe’s logo.

As seen in the previous NuGet campaign, the StripeAPI.net package also has artificially inflated download counts, with over 180,000 downloads. However, instead of racking up tens of thousands of downloads across dozens of versions, the threat actor took a more subtle approach: splitting up the 180,000 downloads across 506 versions, with each version containing around 300 downloads on average.

A deeper look inside the package

The malicious NuGet package contains DLLs with the same code and behaviors as in the legitimate Stripe package. But it modifies crucial methods to collect and transfer sensitive data back to the threat actor (Figure 2). That was something observed in our previous research on the crypto- focused malicious NuGet campaign.

Figure 2: Modified methods

In Figure 2, the text highlighted in red is malicious code that was added to the legitimate code copied from the Stripe.net NuGet package in the malicious package. Its purpose is straightforward: steal the user's API token when the StripeClient class is initialized. This initialization must happen at some point when developers use this library. By poisoning this method, the threat actors guarantee that the API token will be stolen.

Figure 3: Exfiltration to Supabase

The stolen API token is then forwarded to the “AddApiKeyAsync” function which exfiltrates the token along with a machine ID (a simple user identifier derived from the computer name), sending the data to a legitimate Supabase server. (Supabase is a backend development platform that provides a free tier with a managed PostgreSQL database, making it a convenient option for quickly deploying attacker-controlled data collection infrastructure.)

And, just like that, your API tokens are stolen and your Stripe account compromised.

What is the actual impact of the malicious package?

As noted above, the StripeAPI.net package has over 180,000 downloads. For a legitimate package, a compromise with that number of downloads would be a major issue. However, RL’s research suggests that most — if not all — of the claimed downloads for the StripeAPI.net package are artificial. 

The first version of StripeAPI.net was published around February 16. A stream of “updates” and downloads immediately followed that initial publication. RL’s researchers found and reported the package relatively soon after its initial release, and the NuGet admin team took it down shortly after being notified by RL. As a result, it is unlikely that there were real victims compromised in this attack. 

This conclusion is supported by taking a look inside the Supabase database using the attackers’ API key. No exfiltrated tokens are found in the database, just a test entry (Figure 4.)

Figure 4: Empty Supabase DB 

Third-party risk in the spotlight

Modern software development heavily relies on third-party libraries. They accelerate development, reduce engineering overhead, and provide access to mature, well-tested functionality. However this convenience comes at a cost: the need for developers to trust code that they did not write. That introduces a significant risk of malicious code finding its way into legitimate applications, as the StripeAPI.net package shows.

That is particularly true in cases like this, in which malicious actors copy and preserve code and functions from legitimate libraries. Developers who mistakenly download and integrate a typosquatted library like StripeAPI.net will still have their applications compile successfully and function as intended. Payments would process normally and, from the developer’s perspective, nothing would appear broken. In the background, however, sensitive data is being secretly copied and exfiltrated by malicious actors.

That is precisely what makes this type of attack so dangerous.The malicious logic was inserted into a critical initialization method and the rest of the codebase remained fully functional. The malicious actors behind this supply chain attack took steps to make their package look trustworthy, from mimicking the look of the legitimate Stripe NuGet package to artificially inflating download and version numbers to make a brand new package appear established and widely used.

The increasing frequency of such campaigns requires a shift in thinking by developers. You can not assume that packages you download from popular open source repositories are trustworthy - even if those packages appear to be widely used and actively maintained. In addition to “typosquatting” attacks like this package and the Nethereum campaign, legitimate packages may also be compromised and traffic malicious code into legitimate development pipelines, as the recent Shai-hulud npm malware outbreak showed.

Figure 5: Malicious package on secure.software

Detecting threats like StripeAPI.net is difficult. That’s why tools like Spectra Assure Community are so important. Developers can scan- and check the status of packages found on public repositories before they install them, looking for signs of malware or any security policies that have been violated.

Figure 6: Package details - issues

Indicators of Compromise (IOCs) 

Indicators of Compromise (IoCs) refer to forensic artifacts or evidence related to a security breach or unauthorized activity on a computer network or system. IOCs play a crucial role in cybersecurity investigations and cyber incident response efforts, helping analysts and cybersecurity professionals identify and detect potential security incidents.

The following IOCs were collected as part of ReversingLabs investigation of this software supply chain campaign.

NuGet packages: