Published on gastropod.io - 07-15-2026

Seventeen Packages, Three Payment Brands, Zero Real SDKs: Inside the Paysafe/Skrill/Neteller Typosquat Wave

On July 7, a threat actor sat down and did something almost boring in its simplicity: they published packages named after payment SDKs that don't exist as packages at all, and waited for developers to install the ones that "obviously" belonged to Paysafe, Skrill, and Neteller.

Thirteen packages landed on npm — things like paysafe-checkout, paysafe-node, paysafe-js, and several Skrill-branded names — each pushed through four rapid point releases. Four more went up on PyPI: paysafe-sdk, paysafe-payments, paysafe-api, paysafe-kyc. None of them were official. All seventeen behaved like a working SDK on the surface — a PaysafeClient that read PAYSAFE_API_KEY and PAYSAFE_ENV from the environment, implemented the payment methods a real integration would expect, and returned clean { success: true } responses for every call. Underneath, that same client was scheduling a delayed exfiltration routine that scraped the environment for anything matching KEY, SECRET, TOKEN, PASS, AUTH, or API, fingerprinted the host, and shipped the haul to a command-and-control endpoint tunneled through ngrok — its final address hidden behind three layers of decoding to dodge static analysis.

It's worth noting how deliberately built this was. The malware checked for sandbox and analysis indicators in hostnames and usernames before doing anything, and backed off entirely on machines with fewer than two CPU cores — a strong sign the operator was tuning specifically against automated scanners rather than a curious developer poking at the code by hand. Socket's scanner still caught the npm cluster within about six minutes of publication, but six minutes is plenty of time for a CI job that runs on every push to have already pulled and executed a bad version.

The target selection is the part that should worry payment teams specifically. A developer integrating Paysafe, Skrill, or Neteller almost by definition has payment API keys sitting in their environment — and if that developer's machine or CI runner also holds a GITHUB_TOKEN or NPM_TOKEN, a single compromised install becomes a second attack: the victim's own publishing credentials, now in someone else's hands, ready to poison whatever they maintain next.

Why this one keeps working

Typosquatting payment SDKs isn't new, but this campaign leaned into something that's gotten quietly worse over the last year: there is no canonical, obvious place for a developer to check "is paysafe-node actually Paysafe's package, or is it just a name that sounds right?" You either already know the vendor's real npm scope, or you're trusting whatever autocompletes first. Attackers are betting — correctly, often enough — that most people don't check.

This is one of the scenarios Gastropod will flag automatically: an artifact whose declared identity doesn't match the name or namespace it was actually served under gets caught at intake, before it's pulled into a build. That's true whether it's a public package squatting a private corporate scope or, as here, a public package impersonating a brand it has no relationship to. The check doesn't require knowing about this specific campaign in advance — it's just resolving what a package claims to be against what it actually is, once, and remembering the answer for every place that artifact shows up afterward. If you want to see what that intake flag looks like in practice, we walked through a real one on the product page.

None of that replaces reading your own dependency list carefully, and it won't stop a determined operator from eventually publishing something clean-looking enough to pass. But if your team pulls a lot of payment, KYC, or fintech integrations — and increasingly, whose doesn't — it's worth having something in the path that questions a package's identity before your CI does.

For the technical writeup and the full list of affected package versions, Socket's original analysis is the most complete source; GBHackers has a solid summary with the IOCs laid out separately for anyone doing incident response right now.

If your team touched any of the affected packages between July 7 and detection, treat every credential on that machine as compromised — rotate first, investigate second.