Discovered: April 3, 2025
Published: April 7, 2025
Safety’s research team has discovered an npm package published by Cashfree, a large Indian payment processing company, that leaks credit card data to an ngrok endpoint. The package looks the same as a legitimate react native package from Cashfree, and was published to Cashfree’s official npm namespace, making it easy to mistake for the legitimate package. After discovering this package, Safety contacted NPM and Cashfree's security team, who promptly removed the credit card leaking package from the npm registry.
On April 3 Safety’s malicious package detection systems flagged a package named @cashfreepayments/react-native-cashfree-cn-sdk as potentially malicious. This system analyzes all Python, Java, and JavaScript open source packages for malicious behavior seconds after they are released. Noticing this package was published in the company’s official NPM account, and that it appeared to involved payment processing, my ears perked up and I took a deeper look.
The react-native-cashfree-cn-sdk library appears to be a mobile SDK, or software development kit, that enables companies to integrate with the Cashfree payment gateway system. In essence, it provides the API integration to companies to take payments through a company named Cashfree Payments.
Credit card leaking payload found in package
There are four times in the source code of this package where you’ll see the payload. This is the example from src/Card/CFCardComponent.js:
The code snippet above isn’t called directly in the application, nor is it passed to an exfil path like a HTTP POST, so initially, I didn’t understand how the payload was being used. However, this package appears to be a credit card payment processing SDK (software development kit). SDK’s like this one are typically used by customers of a service to add functionality to their applications from the vendor. So, this SDK sends the credit card information and payment details to an ngrok tunnel.
The ngrok tunnel has been offline so I haven’t been able to test to see what API endpoints or other functionality it might support.
The package author
This package was published by a known npm user. That npm user has access to a scoped namespace in npm @cashfreepayments.
This scoped namespace is actually serving a number of legitimate packages for the organization Cashfree Payments who receives tens of thousands of downloads each week.
It is rare to see a confirmed and validated email address attached to a package leaking credit card data via ngrok, especially from a business that appeared to be the legitimate domain (cashfree.com).
Typical “look-a-like” style attacks involve the threat actors simply creating a malicious package that pretends to be linked to a legitimate GitHub project. In these cases the threat actors will use gmail or proton or some other anonymous email service, and are not published to the legitimate organization’s namespace.
Cashfree.com business
Cashfree.com is a large payment processing company started in 2015 and based in Bangalore, India. They have approximately 900 employees, and do have a security team, including a CISO.
Cashfree’s website claims they have processed more than $80B USD in transactions, and have served 600M bank accounts and 8M businesses. In 2024, they claimed to process $5B US every month, and they received a $53m investment in February of this year to take their technology global.
Cashfree software engineers involved
There are several developers at Cashfree that deploy packages to the npm registry, however it was one particular developer who wrote and deployed the package in question. We don’t know the intent of the developer and whether this was a mistake or malicious, or if they were hacked or subject to an npm account takeover attack. In the interest of caution we are going to call the package publisher “cashfree-dev1” to protect their identity.
Technical analysis
Many of the Cashfree npm packages have similar names:
- @cashfreepayments/cashfree-browser-data
- @cashfreepayments/cashfree-js
- @cashfreepayments/deviceintel-js-sdk
- @cashfreepayments/react-native-cashfree-cn-sdk - this is the package in question
- cashfree-elementjs
- cashfree-payout
- cashfree-pg
- cashfree-pg-api-contract
- cashfree-pg-capacitor
- cashfree-pg-sdk-javascript
- cashfree-pg-sdk-nodejs
- cashfree-verification
- cordova-plugin-cashfree-pg
- payments-icons-library
- react-native-cashfree-pg-sdk
- react-native-cashfree-prepaid-cards
The problem with so many similar names is that it's easier for different versions to get used by customers if it’s not obvious which one is the right one to use.
The credit card leaking package “@cashfreepayments/react-native-cashfree-cn-sdk” looked similar to the legitimate “react-native-cashfree-pg-sdk” package. For example the readme was almost identical:
When I looked at the README markdown files, I verified with diff that the only difference was the name of the package had a “cn” instead of “pg”, and was missing the GitHub flair images at the top. Otherwise the two readme’s were identical, as was the package root.
So, this means that the new credit card leaking “@cashfreepayments/react-native-cashfree-cn-sdk” was derived from the older “react-native-cashfree-pg-sdk” package. This would be confusing to npm users as the scoped part of the package @cashfreepayments indicates legitimacy.
If you were a customer looking to integrate with Cashfree to do payment processing, which package would you select?
@cashfreepayments/react-native-cashfree-cn-sdk
react-native-cashfree-pg-sdk
You’d probably go with the scoped version, right? The fact that the package was scoped could cause customers to use that package thinking it was the official version. This has the hallmarks of “insider threat typo-squatting” attack, but also could have been a mistake on the developer’s behalf, where an internal testing build was published mistakenly.
The package author leaves more clues…
Interestingly, if we look at the source code artefacts in the npm packages, both packages include development artifacts from two Cashfree developers.
In particular there are remnants of their Xcode environment in the package files, and even include Xcode binary project files. This is an important clue, because, among other things, it lets us see that both developers started with the same codebase: react-native-cashfree-pg-sdk.
My comparison of the credit card leaking and benign codebases tells us that cashfree-dev1 used the pg version of the sdk to create their cn credit-card-leaking version. After comparing the two code bases, any differences that exist in the new react-native-cashfree-cn-sdk were likely introduced by cashfree-dev1.
Analyzing and comparing the source code
If we go back to the benign react-native-cashfree-pg-sdk package we’ll see that it has 778 average weekly downloads and includes 140 files in the package tarball.
We also see the GitHub link in the Repository field to the right. The repo URL is https://github.com/cashfree/react-native-cashfree-pg-sdk.
If you download the credit card leaking tarball for the @cashfreepayments/react-native-cashfree-cn-sdk npm package we can compare against the source code we just pulled from GitHub.
Let’s circle back to that credit card leaking payload that we saw before in the src/Card/CFCardComponent.js file. The payload can be found in the doPayment variable starting on line 186:
If we compare the same doPayment variable in the benign react-native-cashfree-pg-sdk repository it does not include the same payload.
This payload is interesting, as it is not directly called in the application and there is no POST or other action present. The README that comes with the package, explains the intent of the SDK: it is for companies who are building their own payment apps to use to integrate with the Cashfree system.
In the case of a customer building their own iOS payment app, when they use the credit card leaking SDK, when their app calls the CFPaymentGatewayService function, which will run on the end user's phone and silently deliver the credit card details to the ngrok endpoint.
Example exploit scenario for this attack
Cashfree’s website lists Zomato, Shell, and CRED as customers.
Imagine that you are a global travel retailer and you want to start selling your products to the Indian market. You have a mobile app for both iOS and Android and you want to add Cashfree to your mobile app so you can take payment from customers directly on their mobile devices in India.
To integrate with Cashfree, you read the documentation and see that you need to import the Cashfree react native package into your codebase. You may search the package name on npm, and could easily end up selecting the credit card leaking package instead of the legitimate one (remember there is only a two letter difference). The package works as you expect, because it has all of the same functionality as the legitimate package. You complete the integration and push your update to the respective app stores.
As your app gains usage and purchases from Indian customers, each credit card used by your users is silently delivered to a ngrok endpoint. This is an example of a true software supply chain threat which ultimately ends up targeting regular consumers who are running legitimate apps on their individual personal mobile devices.
Responsible disclosure, and outcomes
After identifying this software supply chain threat, I immediately contacted npm to request the package's removal and reached out to the Cashfree security team through both LinkedIn and email. The Cashfree team promptly responded saying they would investigate the issue and later that day the Cashfree team removed the package from the npm registry.
Cashfree’s response to our research
First, Cashfree removed the package in question within a day of me alerting them. Additionally, Cashfree responded to my outreach relatively quickly, which was encouraging.
Their official response is that this new package was part of their initial development work, and used only for testing purposes. They go on to claim that at no time was there any impact on customers, and that the package was strictly confined to internal testing.
While I appreciate the response I want to point out that even if this was an accident it is nevertheless a dangerous outcome. Using this new package could have exfiltrated customer credit card data.
This is a common misunderstanding that I run into which is why I’m taking the time to address it here: Using public npm packages to test functionality is not following security best practices, since any package, no matter its intent, can become dangerous once it’s available on the public registry. npm offers private packages, or you can manage your own package registry, both of which provide teams the ability to build npm packages that only their teams have access to.
Paul McCarty, Head of Research at Safety
Source code scanning tools do not protect you from open source threats
Unfortunately, most development teams aren’t protected from this kind of threat. There are hundreds of thousands of malicious packages in existence that can steal data, or compromise applications, and many dev teams think they’re protected, when they aren’t. Traditional SCA scanners such as Synk would not have protected against this threat since it was not a CVE or traditional vulnerability.
Many malicious software packages deliver their malicious payloads when they are installed.
Since scanners such as dependabot can only scan for packages that have already been installed they cannot protect against this increasingly common attack. Even worse, security tools like anti-virus and endpoint detection and response (EDR) tools don’t flag these malicious packages as bad either, so this makes the gap in coverage even worse.
Safety’s comprehensive supply chain security and governance
Safety protects your people and AI-assistants from software supply chain threats, not just your codebases.
Safety verifies and secures every package before installation, proactively protecting your developers from malicious package attacks that scanners and endpoint antivirus tools such as Crowdstrike do not. Safety integrates with existing package managers and tools, so that your developers are protected without needing to change their workflows or tools.
We analyze every open-source package globally so that our customers are immediately protected from new malicious packages within minutes of them appearing in public registries. In this case Safety would have blocked use of this dangerous Cashfree package days before it was removed from NPM.
Safety’s MCP integrates directly with AI coding assistants and ensures AI-assistants don’t write code that uses vulnerable or malicious open-source packages.
Safety’s compliance and governance delivers a consistent layer of open source observability and governance across your organization, streamlining compliance and regulatory demands such as SOC2 and FEDRAMP.
