Braintree.net nuget Typosquat
Published on gastropod.io - 07-15-2026
Braintree.Net: A Typosquat That Only Steals Cards Once It Knows You're in Production
Most malicious packages fire the moment they're installed. Braintree.Net, a NuGet package that spent the first days of July impersonating the real Braintree .NET payment SDK, waited for something better: a live transaction.
Socket's scanner flagged the package as potential malware ten minutes after the first malicious version went up on July 3, which is fast by any measure. What took longer to unravel was how deliberately it was built. Braintree.Net isn't a crude copy — it ships real-looking assemblies across five target frameworks, mirrors the actual SDK's public API (BraintreeGateway, CreditCardGateway, TransactionGateway), and even bundles a README lifted from Braintree's own docs, right down to the install instructions that (ironically, or deliberately) tell you to install the real package. A developer can spin up a gateway, run test transactions, and get back plausible-looking results with nothing that reads as broken.
The card-skimming piece only activates in production. A CardOperationLogger hooks into CreditCardGateway.Create and similar transaction methods, and once the gateway is configured for a live environment rather than sandbox, it starts quietly POSTing PAN, CVV, expiration, card type, and customer IDs to an attacker-controlled endpoint dressed up to look like a legitimate telemetry domain. A second hook captures the merchant's actual API keys — merchantId, publicKey, privateKey — the moment they're set, which is enough on its own to let an attacker create transactions, issue refunds, and reach the vault through Braintree's real API. Every outbound call is wrapped in an empty catch block, so a blocked or failed request just fails silently instead of surfacing an error a developer might notice.
There's a second, subtler piece worth knowing about. The package declares a dependency on a companion credential harvester, DependencyInjector.Core (by way of a package called SipNet), but NuGet's default dependency resolution happens to pick a clean version of that dependency unless something in your project — an explicit pin, a floated version range — pulls in a later one. So the malicious transitive path exists, but whether any given install actually walked it depends on resolution details most teams never think to check. And the package's ~14 million reported downloads are mostly theater: roughly 11 million of them come from 120 throwaway placeholder versions published in a single day back in October, inflating the number a rushed developer sees before installing.
The part that's easy to miss under pressure
If your team pulls Braintree, the natural next question is "did we install the real one or the fake one," and that's answerable by checking a package ID. The harder question — the one that actually determines whether you have a problem — is whether your specific dependency graph resolved the transitive harvester or dodged it, and whether that resolution differs between what's in your lockfile, what's cached in CI, and what's actually running in production right now. That's not something a single grep answers.
This is what Gastropod's blast-radius mapping is built for: flattening direct and transitive dependents into edges you can actually query, so "does this specific malicious digest reach us, and through which path" is a lookup against what's already been resolved rather than a fresh audit of every project's dependency tree. Paired with where-seen history, it also answers the quieter question — whether an artifact matching this package showed up anywhere in your estate before you'd even heard the name Braintree.Net. The product page has more on how the dependency graph gets built and queried.
None of that stops someone from building a well-disguised typosquat in the first place — that's a registry moderation problem, not something downstream tooling fixes. But when a payment SDK impersonator turns up with a production-gated payload, the value isn't in reacting faster; it's in already knowing exactly where you stand.
Socket's full technical writeup has the complete indicator list and affected version ranges; GBHackers has a solid condensed summary if you're triaging quickly.
If your project references Braintree.Net or DependencyInjector.Core, treat any merchant API keys and card data handled since installation as compromised, and confirm which version your production build actually resolved before assuming you're clear.