Socket’s automated malware scanner caught a coordinated supply-chain campaign on July 7, 2026 that published 17 malicious packages across npm and PyPI, all typosquatting SDKs for three payment processors: Paysafe, Skrill, and Neteller. Thirteen packages landed on npm and four on PyPI; every npm package shipped four rapid-fire versions (1.0.0 through 1.0.3) and was flagged as malware within roughly six minutes of publication — fast enough that most never reached meaningful download counts, but slow enough that CI runners and local dev installs during that window are still at risk.

What Happened

The npm side includes package names like paysafe-checkout, paysafe-vault, paysafe-api, paysafe-node, paysafe-payments, paysafe-sdk, paysafe-kyc, paysafe-js, paysafe-cards, paysafe-fraud, skrill, skrill-sdk, and skrill-payments; the PyPI side includes neteller and three companion packages. None of these are official SDKs — Paysafe, Skrill, and Neteller do not publish first-party packages under these names, which is exactly what makes them attractive typosquat targets for developers integrating payment flows quickly.

Each package fully implements the expected client-facing API surface. Calls like checkout, tokenize, or KYC verification return convincing, well-formed success responses, so a developer testing the integration sees nothing wrong. Underneath, the package scans the process environment for variables whose names contain KEY, SECRET, TOKEN, PASS, AUTH, or API — sweeping up PAYSAFE_API_KEY, AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN, NPM_TOKEN, and any similarly named CI/CD or cloud credential sitting in scope.

The two registries behave differently. The npm packages only trigger exfiltration when a Paysafe API key is actually present in the environment and the fake SDK method is invoked — a gate that limits blast radius but also means the packages can sit dormant and undetected in a dependency tree until the right conditions line up. The PyPI packages skip that gate entirely: exfiltration fires automatically on import, no API key or method call required.

Exfiltrated data — hostname, username, environment secrets, and API usage metadata — is sent to a command-and-control endpoint reached only after multiple decoding stages (XOR, character shifting, reversal) that resolve to a lightweight tunneling/relay host rather than a static IP. The malware also checks for analysis conditions before firing: fewer than two CPU cores, or a hostname/username containing strings like sandbox, analyzer, cuckoo, vmware, or vbox causes it to exit quietly instead of exfiltrating — standard sandbox-evasion logic meant to keep the package looking clean under automated scanning.

Impact

The primary targets are developers and CI pipelines integrating payment processing — fintech backends, e-commerce checkout flows, and KYC/compliance tooling that would plausibly need a Paysafe, Skrill, or Neteller client. Because the stolen secrets include AWS keys, GitHub tokens, and npm tokens (not just payment-provider credentials), a single bad install can cascade into cloud account compromise, source-repository access, or the ability to publish further malicious packages under a stolen npm identity — the same pattern that has fueled prior self-propagating npm worm campaigns. CI runners are especially exposed: a build step that npm installs or pip installs one of these packages while payment or cloud secrets are present in the environment will exfiltrate on the very first run, with no further interaction needed.

Mitigation

  • Audit package.json/package-lock.json and requirements.txt/lockfiles for any of the named packages (paysafe-checkout, paysafe-vault, paysafe-api, paysafe-node, paysafe-payments, paysafe-sdk, paysafe-kyc, paysafe-js, paysafe-cards, paysafe-fraud, skrill, skrill-sdk, skrill-payments, neteller) and remove them immediately if present.
  • Only install official Paysafe, Skrill, and Neteller SDKs from vendor-confirmed package names and repositories — verify publisher identity, not just the package name.
  • Search CI logs for PAYSAFE_API_KEY, AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN, or NPM_TOKEN appearing alongside any of the malicious package names in install logs.
  • Rotate any credential that could have been present in an environment where these packages were installed, including AWS keys, GitHub PATs, and npm publish tokens.
  • Use a registry-scanning tool (Socket, npm audit signatures, or equivalent) in CI to catch typosquats before install rather than after.
  • Pin dependencies and disable auto-install of transitive packages with unreviewed version bumps where feasible.

Sources