Fake Braintree NuGet Package Steals Payment Data and Merchant Secrets

A malicious NuGet package impersonating Braintree’s .NET payment SDK has been found stealing live card data, merchant API keys, and environment secrets from production applications.

The package, named Braintree.Net, used typosquatting to look like the legitimate Braintree package used by .NET developers. According to Socket’s analysis, the first malicious version appeared on July 3, 2026, and Socket flagged it within 10 minutes of publication.

The risk is serious because the package did not only run during installation. It copied parts of the real payment SDK’s surface API and hooked into payment flows, allowing normal transactions to continue while sensitive data was sent to attacker-controlled infrastructure.

How the Braintree NuGet typosquat worked

The legitimate Braintree .NET package is published on the NuGet Gallery under the package name Braintree. The malicious package used the name Braintree.Net, a variation that could trick developers searching for a Braintree .NET SDK in a rushed dependency update.

Socket said the fake package copied metadata and documentation cues from the real SDK, including references to the official Braintree GitHub repository. That made the package look more credible during a quick review.

The attacker also used a versioning pattern that looked plausible beside the real SDK. While the official Braintree package is in the 5.x line, the typosquat used 3.35.x and 3.36.x versions that could appear like an older branch.

Item	Legitimate package	Malicious package
Package name	Braintree	Braintree.Net
Registry	NuGet	NuGet
Publisher context	Braintree and PayPal maintainers	Impersonating Braintree branding
Main risk	Normal payment SDK use	Payment card theft, API key theft, and secret harvesting

Payment card data was intercepted during live transactions

The fake package added hooks to payment-related methods. These hooks captured data from card creation, card update, transaction sale, transaction credit, payment method creation, payment method update, and card verification flows.

Socket found that the malicious code collected primary account numbers, CVV values, expiration dates, customer IDs, transaction amounts, card types, timestamps, and operation names. The legitimate SDK, described in the Braintree .NET setup documentation, does not include these side-channel logging functions.

The payment request could still proceed to Braintree after the theft attempt. That behavior reduces the chance that a merchant would notice a problem, because the checkout flow may continue to work normally.

Merchant credentials and environment secrets were also targeted

The malware also targeted Braintree merchant credentials. Socket said the fake SDK attempted to collect merchantId, publicKey, and privateKey values when a production Braintree gateway was configured.

Those credentials can be dangerous in an attacker’s hands because they may allow direct interaction with the payment gateway. Depending on account permissions and configuration, attackers could attempt fraud, access customer vault data, or abuse merchant payment operations.

The campaign also used a companion package named DependencyInjector.Core to harvest broader host information. This included environment variables, appsettings files, connection strings, cloud metadata, Kubernetes service account paths, mounted secrets, dependency data, and loaded assembly information.

• Payment card data could be exposed when production card flows used the fake SDK.
• Braintree merchant credentials could be stolen during gateway setup.
• Cloud credentials and database connection strings could be exposed through environment and configuration harvesting.
• CI/CD and deployment tokens could also be at risk if present in the application environment.

XOR obfuscation hid the analytics endpoint

The malicious package used different techniques for different exfiltration paths. Card and merchant credential endpoints appeared as readable strings in the fake Braintree DLL.

The broader environment harvester hid its analytics endpoint with XOR obfuscation. The decoded endpoint pointed to an analytics report path on the same attacker-controlled domain, according to the Socket report.

This matters for defenders because basic string extraction may reveal only part of the campaign. A deeper assembly review can reveal obfuscated endpoints, suspicious module initializers, and silent exception handling that hides failed exfiltration attempts.

Indicator type	Indicator	Purpose
Domain	348672-shakepay[.]com	Attacker-controlled exfiltration infrastructure
Host	api.348672-shakepay[.]com	Used for outbound data transmission
Path	/api/card	Payment card data exfiltration
Path	/api/account	Braintree merchant credential exfiltration
Path	/api/analytics/report	Environment and configuration data exfiltration
Header	X-Api-Key: 2523-5235-8564-2683-2386	Observed in malicious outbound requests

Production-only checks made the package harder to catch

The package used production checks before stealing payment card data and merchant credentials. That means sandbox tests could appear normal, while real production traffic triggered the most damaging behavior.

The environment harvester worked more broadly. Socket said DependencyInjector.Core could run during assembly load for affected .NET 8, .NET 9, and .NET 10 targets, even if the application was not processing live Braintree payments at that moment.

This split design shows why dependency review cannot rely only on sandbox behavior. A malicious package can stay quiet during testing and activate when it finds production credentials or live transaction data.

Affected packages and response steps

Socket listed malicious versions of Braintree.Net, DependencyInjector.Core, and related SipNet packages. Developers should inspect lock files, central package management files, build logs, restore caches, and deployed application directories for these names.

Teams should replace the fake package with the official Braintree package. They should also compare their implementation with the Braintree documentation and confirm that no project references Braintree.Net or DependencyInjector.Core unexpectedly.

Recommended actions include:

1. Remove Braintree.Net from all projects and dependency files.
2. Search for DependencyInjector.Core, SipNet, and SipNet.OpenAI.Realtime in lock files and dependency graphs.
3. Rotate Braintree merchant credentials for any environment that referenced the fake package.
4. Review payment logs and determine whether live card data passed through the poisoned SDK.
5. Block outbound traffic to 348672-shakepay[.]com and related subdomains.
6. Hunt for outbound POST requests to the listed paths and for the observed X-Api-Key header.
7. Rotate cloud, database, deployment, and CI/CD secrets exposed to affected applications.
8. Start PCI incident response procedures if production cardholder data may have been exposed.

Why payment supply-chain attacks are especially dangerous

This campaign highlights the danger of typosquatting in payment-related dependencies. A small package name change can place attacker-controlled code inside checkout systems, API integrations, and backend payment services.

Payment applications need stricter dependency controls than ordinary internal tools. Teams should verify package names, publishers, repository links, version history, and dependency changes before approving payment SDK updates.

Organizations can reduce risk by using lock files, private package mirrors, software composition analysis, outbound network monitoring, and mandatory review for new dependencies in payment projects. They should also treat package metadata as untrusted until the package identity has been verified.

FAQ