Updated: 8th April 2026
What is a typosquatting attack on a package registry? It is a technique in which an attacker publishes a package with a name deceptively similar to a popular, trusted library – relying on the developer making a typo or not checking the name carefully enough before installation. In February 2026, the ReversingLabs research team discovered a package named StripeApi.Net on the NuGet platform, impersonating the official Stripe.net library (over 74 million downloads). Malicious code injected into an initialisation method intercepted Stripe API keys and exfiltrated them to an external server – with no visible error in the application’s behaviour.
StripeApi.Net attack on NuGet – in brief:
- The malicious package StripeApi.Net was published on NuGet on approximately 16 February 2026 as a counterfeit of the official Stripe.net
- The attack used typosquatting – the name differs from the original by a single word and separator (dot vs dash within the name)
- Malicious code was injected solely into the initialisation method of the
StripeClientclass – mandatory on every use of the library - The stolen API key was exfiltrated via HTTPS to the Supabase platform along with a developer machine identifier
- The package had artificially inflated counters: over 180,000 downloads spread across 506 versions, to appear as a mature library
- No real API keys were actually stolen – ReversingLabs detected and reported the package to NuGet before any real victims were compromised
- This is the second attack on NuGet within 3 months – the December 2025 campaign targeted crypto packages: Coinbase, Binance, Solana
What Is Typosquatting and Why Is It So Effective on Package Platforms?
Typosquatting is the registration of a domain name or – in this case – a package name, deceptively similar to a popular original. The difference is often minimal: one letter, a special character, a different word order. In the case of StripeApi.Net, the difference from the official Stripe.net is the additional word “Api” and a separator change (a dash instead of a dot).
The effectiveness of this technique stems from several factors simultaneously:
- Automated installation – in CI/CD environments, packages are installed based on a configuration file; a single name error replicates across all servers
- Trust in registries – developers treat NuGet, npm or PyPI as trusted sources; they do not verify every package individually
- Time pressure – a developer looking for a library for a quick integration rarely checks the package owner or version history
- Artificial credibility – the attackers inflated the download counter to 180,000 and created 506 versions, to make the package appear as a mature, actively developed project
The StripeApi.Net page on NuGet was prepared carefully: the same icon as the official Stripe.net, a nearly identical README file (only “Stripe.net” was changed to “Stripe-net”), links to official Stripe repositories, identical tags. The only visual difference – no Stripe logo next to the owner account name “StripePayments”.
How Did the Malicious Code in StripeApi.Net Work Technically?
This is the most important part for every CISO and security architect – because it shows precisely how the attackers selected the injection point for the malicious code.
The StripeApi.Net package contained code almost identical to the original Stripe.net library – all classes, methods and business logic copied without modification. The change affected only one method: the initialisation of the StripeClient class.
Why specifically this method?
Because it is mandatory. Every developer who wants to call anything through the Stripe API must first initialise a StripeClient by providing an API key. Without this step, the library is useless. The attackers injected malicious code at precisely this point – guaranteeing that the key would be intercepted on every use of the library.
Step-by-step attack flow:
- The developer installs StripeApi.Net instead of Stripe.net – through a typo or inattention
- In the application code, they initialise
StripeClientwith an API key – a standard, mandatory step - The malicious code intercepts the key at the point of initialisation and passes it to the
AddApiKeyAsyncfunction - The function packages the API key together with a machine identifier (a hash of the computer name) and sends the data via HTTPS to a Supabase instance controlled by the attacker
- The developer sees no error – the application compiles correctly, payments are processed normally
- The API key arrives in the attacker’s database
Why is this particularly dangerous?
The application behaves identically to one using the legitimate package. Tests pass. Payments are processed. From the developer’s perspective, nothing is broken. The malicious logic is hidden in a single initialisation method; the rest of the code is 100% legitimate and functional.
What can an attacker do with a Stripe API key?
A Stripe API key (the so-called “secret key”) grants access to the payment platform’s full API. Depending on the key’s permissions, an attacker may:
- Initiate refunds to accounts under their control
- Retrieve customer data: name, email address, last 4 digits of the card, transaction history
- Create or modify subscriptions and payment plans
- Read webhook data and intercept transaction notifications
- In an extreme case – initiate payouts from the Stripe account balance
How Did the Attacker Make the Package Look Credible – and What Does This Mean for Risk Assessment?
ReversingLabs identified several techniques the attacker used to make the package appear legitimate:
Inflated download counters. The package had over 180,000 downloads spread across 506 versions – roughly 300 downloads per version on average. This deliberate spread was designed to avoid suspicion: a brand-new package with 180,000 total downloads would look suspicious, because new projects do not achieve such numbers immediately. Many versions with a smaller number of downloads each – that looks like natural, long-term growth in popularity.
Replica of the package page. The StripeApi.Net page on NuGet was practically a copy of the official Stripe.net page: the same icon, the same description, the same tags, the same links to Stripe documentation. The attackers were not creating a new identity – they were forging an existing one.
Owner name “StripePayments”. Another credibility element – a developer seeing that name might assume it was an official Stripe account.
Conclusion for CISOs: download counts and version history are not reliable security indicators. Attackers can fabricate them. The only reliable verification is code analysis and cryptographic hash verification.
How to Defend Against Typosquatting Attacks on NuGet and npm?
Below are concrete technical and organisational measures – not generalities.
1. Software Composition Analysis (SCA) with behavioural analysis in the CI/CD pipeline
Standard SCA tools (OWASP Dependency-Check, Snyk, Dependabot) scan dependencies for known CVE vulnerabilities. However, a typosquatting malicious package has no CVE – because it is new. You need tools with behavioural code analysis and package reputation analysis that detect anomalies in code (e.g. unexpected network connections in initialisation methods).
2. Cryptographic package hash verification
Every NuGet package has an SHA1 and SHA512 hash. If your pipeline compares the hash of the installed package against a list of approved hashes – typosquatting is detected immediately, because the malicious package hash will not be on the list. This requires maintaining a register of approved packages and their versions.
IOC for StripeApi.Net: SHA1 050bf5d4cf8fb4964e0e67b4cb46dacf89e7a615 (version 50.4.1)
3. Approved packages policy (allowlist)
Rather than blocking bad packages (the threat list is unknown in advance), define a list of packages permitted in production projects. Every new package requires review and formal approval before being added to the list. This is an organisational process, but one of the most effective.
4. Monitoring outbound traffic from the application (egress)
The malicious code in StripeApi.Net exfiltrated data to Supabase via HTTPS on port 443. A standard firewall will not stop this – HTTPS looks like normal traffic. You need SNI (Server Name Indication) analysis or a TLS proxy that logs outbound connections from application servers and alerts on connections to unknown domains.
5. Isolation of API key permissions in developer environments
API keys used locally by developers should have restricted permissions – e.g. Stripe test mode only, with no access to production customer data. In the event of an attack on a developer’s environment, a stolen test key does not grant access to production.
6. Verifying the package owner before installation
Before installing a package, check: who is its owner on NuGet? Does the owner have an organisation logo? Has the profile existed for a long time? Are other packages by this owner well-known? For StripeApi.Net, the owner “StripePayments” had a default NuGet profile picture – rather than the Stripe logo.
What Are the Regulatory Implications for Companies Using External Libraries in Payment Environments?
The StripeApi.Net incident is not only a security problem – it is a potential compliance problem for every company that processes card payments.
PCI DSS 4.0 – Requirement 6: secure systems and software
Requirement 6.3.3 mandates protection of all software components against new vulnerabilities. Requirement 6.2.4 mandates code reviews. Requirement 12.8 imposes an obligation to manage third-party vendor risk – and a NuGet package is a third-party vendor within the meaning of PCI DSS. If your CI/CD pipeline installs packages without integrity verification and without reputation checking, you may not be meeting these requirements.
DORA – Article 28: ICT third-party risk
DORA, applying to financial institutions in the EU since January 2025, requires management of third-party ICT risk. An open-source library used in an application that processes payments is an ICT provider within the meaning of DORA. The StripeApi.Net attack fits precisely the risk scenario that DORA requires organisations to identify and mitigate.
NIS2 – Article 21: supply chain security
NIS2 requires essential entities to implement cybersecurity risk management measures covering supply chain security. This includes verification of software dependencies used in operational systems.
| Regulation | Requirement | What to check |
|---|---|---|
| PCI DSS 4.0 Req. 6.3.3 | Protection of components against vulnerabilities | Does the pipeline verify package hashes? |
| PCI DSS 4.0 Req. 6.2.4 | Code review for vulnerabilities | Does SCA include behavioural analysis? |
| PCI DSS 4.0 Req. 12.8 | Vendor risk management | Are open-source packages on the vendor register? |
| DORA Art. 28 | ICT third-party risk | Do libraries in payment environments have a risk assessment? |
| NIS2 Art. 21 | Supply chain security | Are there documented dependency verification processes? |
FAQ
How does StripeApi.Net differ from the official Stripe.net?
The official package is Stripe.net (dot as separator, no word “Api”) – over 74 million downloads, owner: Stripe Inc. with an official logo. The malicious package is StripeApi.Net (added word “Api”, capital N in “.Net”) – owner “StripePayments” without a company logo. The difference is minimal and easy to overlook during a quick installation.
Was the official Stripe.net package compromised?
No. The official Stripe.net was not attacked or modified. The attackers created a separate package with a similar name, rather than attempting to take control of the official library. This is a deliberate choice – attacking a popular package maintained by a large company is significantly more difficult.
Were any API keys actually stolen in this attack?
According to ReversingLabs’ analysis – no. The Supabase database controlled by the attacker contained only a test entry. The package was detected and removed from NuGet relatively quickly after publication – before it had reached the production applications of real users.
How do I check whether my .NET application uses the malicious package?
Check the packages.config file or <PackageReference> sections in the project’s .csproj files. Look for an entry named StripeApi.Net (capital N, word “Api” in the middle). If you find it – remove the package immediately, revoke all Stripe API keys used by the application and generate new ones in the Stripe Dashboard. IOC to add to monitoring systems: SHA1 050bf5d4cf8fb4964e0e67b4cb46dacf89e7a615.
Do similar attacks occur on platforms other than NuGet?
Yes – regularly. Analogous campaigns are documented on npm (JavaScript/Node.js), PyPI (Python) and RubyGems (Ruby). In December 2025, ReversingLabs disclosed a similar typosquatting campaign on NuGet targeting crypto packages: Coinbase, Binance, Solana and Nethereum. Supply chain attacks via open-source package registries are a consistent, growing trend.
What tools help detect typosquatting in .NET dependencies?
Tools with behavioural and reputational analysis – such as Spectra Assure (ReversingLabs, which detected this package), Socket.dev or rl-scanner. Standard CVE scanners (Dependabot, Snyk in basic configuration) will not detect a new malicious package that does not yet have a CVE assigned. Code analysis of the package itself is essential, not just its metadata.
Software supply chain security – free consultation
Patronusec supports financial institutions, fintechs and e-commerce businesses in assessing supply chain risk in the context of PCI DSS 4.0, DORA and NIS2 – including maturity assessment of CI/CD pipelines for software dependency verification. Book a short, no-obligation call with our team.
