Socket: 17 fake Paysafe, Skrill, Neteller SDKs on npm and PyPI

Socket’s threat research team disclosed a cluster of 17 malicious packages — 13 on npm, 4 on PyPI — that present themselves as SDKs for the Paysafe, Skrill, and Neteller payment products and, on install, exfiltrate developer credentials to a command-and-control endpoint hosted on AWS. BleepingComputer picked the report up on 2026-07-08.

The npm side of the cluster: paysafe-checkout, paysafe-vault, neteller, skrill-payments, paysafe-js, paysafe-api, paysafe-node, paysafe-cards, paysafe-fraud, paysafe-kyc, skrill, skrill-sdk, and paysafe-payments. On PyPI: paysafe-kyc, paysafe-payments, paysafe-sdk, and paysafe-api. Two of the names appear on both registries — a small detail, but the sort of thing you build a lockfile audit around, because a developer who has already accepted the npm name is more likely to accept the PyPI one on faith.

These are not typosquats. None of the impersonated vendors — Paysafe Group, its Skrill brand, or Neteller — publishes an official first-party SDK under any of these names, and the packages do not lean on a close-to-legitimate typo. They present as first-party integrations for a legitimate product that has no first-party integration to compete with. Developers doing an honest npm search paysafe or pip search paysafe (or, more realistically, an LLM-assisted search) get a plausible-looking result set and no easy tell.

On install, the payload harvests Paysafe API keys, AWS access keys, GitHub tokens, npm tokens, the hostname, the username, and metadata about the developer’s API usage. That last item is the interesting one — usage metadata tells the operator which of the stolen credentials are worth attacking first, and it turns the compromised developer into a persistent enumeration source rather than a one-shot credential dump. The specific C2 URL was not disclosed in the Socket writeup as reported.

Why this is worth the audit cycle

The payment-SDK impersonation surface is narrower than the typosquat surface but harder to defend. A typosquat targeting axios or requests gets caught by any half-serious registry monitor because the impersonated name is already load-bearing. A package claiming to be the “official Paysafe SDK” on a registry where no official Paysafe SDK exists has nothing to be compared against — the absence of a legitimate package is not something registry-side tooling reads as a signal, and neither, in practice, do most developers.

This fits alongside the HalluSquatting research we covered earlier today. Both attacks exploit the same underlying condition: developers ask for packages by descriptive name (“a Paysafe SDK,” “a package that does X”), a registry namespace is open to anyone who wants to claim that name, and there is no first-party authority answering “no, we don’t publish one, don’t trust that.” The AI-hallucinated-package variant makes it worse because the LLM confidently recommends the plausible-sounding name; the payment-SDK variant works even without an LLM, because a developer under deadline will accept a plausible name from a search box.

The other cluster of recent supply-chain work to hold this against is the DPRK-linked polyfill / npm rollup and Contagious Interview campaigns, which had a similar credential-harvesting shape but targeted developers via namespace hijack rather than plausible-name occupation. There is no reported attribution for this Paysafe/Skrill cluster; treat that as an open question, not an attribution.

What to do

If your build ingests any of the 17 names above — check package-lock, pipfile.lock, and any developer machines that might have installed a one-off — pull them out, rotate the Paysafe API keys, AWS keys, and GitHub/npm tokens that were reachable from the affected environments, and treat the metadata leak as an assumption that whoever set this up now knows what you use those keys for. Removal status from npm and PyPI is not stated in the report; assume the names may reappear under adjacent handles until the registries confirm otherwise.

If your build does not ingest any of these — the durable defense is a lockfile-level allowlist keyed to package publisher, not name. That defense is unglamorous and has been recommended for years. It works.