Coordinated npm + PyPI campaign typosquats Paysafe / Skrill / Neteller payment SDKs, exfiltrates keys to AWS

What happened

On 2026-07-07 at 12:56 UTC Socket's AI scanner detected a coordinated cross-registry campaign publishing 13 npm and 4 PyPI packages that impersonate the payment SDKs for Paysafe, Skrill, and Neteller — three gambling and iGaming payment gateways all owned by Paysafe Group. All 17 packages expose plausible legitimate SDK APIs but ship a data-theft module that exfiltrates secrets to attacker-controlled AWS infrastructure. Socket flagged the entire cluster within ~6 minutes of the first publish; npm Security unpublished every affected npm version at 2026-07-08 00:25 UTC (a coordinated take-down window across all 13 names). PyPI retired the 4 PyPI names within 48 hours — all four 404 on pypi.org as of 2026-07-09.

Publishing timeline

Every one of the 13 npm packages was created inside a 55-second window on 2026-07-07 between 12:56:14 UTC (paysafe-api) and 12:57:09 UTC (paysafe-cards). All 13 packages then followed the same publish cadence for four escalating versions:

| Version | Publish window (UTC) | |---|---| | 1.0.0 | 2026-07-07 12:56:14 → 12:57:09 | | 1.0.1 | 2026-07-07 13:04:08 → 13:06:28 | | 1.0.2 | 2026-07-07 13:17:11 → 13:17:44 | | 1.0.3 | 2026-07-07 13:22:43 → 13:23:14 |

The 27-minute end-to-end campaign, tight per-package timing, and identical version arc across every package identify a single operator running a scripted publish loop. npm Security unpublished every 1.0.x version across all 13 names at 2026-07-08 00:25:40 UTC and 00:25:54 UTC — another single-operator sweep, but this one on the defender side.

Malware behaviour

Both ecosystem variants share the same core payload but wire it up differently:

• npm packages expose the full Paysafe API surface. The data-theft module runs lazily: when the SDK is invoked (initClient(), createPayment(), etc.) with a real Paysafe API key, the SDK returns a fake success response but simultaneously enumerates process.env for entries whose key names match a regex of KEY|SECRET|TOKEN|PASS|AUTH|API, harvests the Paysafe API key that was just passed in, and POSTs the collected values plus hostname / username / API-usage metadata to an AWS-hosted collector. Because the fake SDK returns { status: "success", transaction_id: <fake> } payloads, integration tests that check only HTTP status and JSON shape pass — the malware can sit in a Node.js payment integration and appear healthy until real transactions start failing downstream.
• PyPI packages are strictly worse: the data-theft routine is inlined into __init__.py and fires on import, with no requirement that any real Paysafe key be present. Just adding import paysafe_sdk (or the equivalent for the other three PyPI names) to a Python script exfiltrates env-var secrets on the first execution.

Both variants include the same sandbox-detection guard: exfil is skipped when the host reports fewer than 2 CPU cores OR when the hostname / username matches sandbox, analyzer, cuckoo, virus, malware, vmware, or vbox. These indicators are almost never present on real developer workstations or CI runners, so the guard exists solely to evade automated malware sandboxing — production and dev environments are not protected.

Target selection

This is not an opportunistic developer-typo campaign. The targeted namespace is deliberately chosen: engineering teams integrating gambling / iGaming payment gateways (Paysafe, Skrill, and Neteller are the three big regulated gambling-industry cash-in / cash-out providers, and Skrill and Neteller are wholly owned by Paysafe Group). No first-party npm or PyPI SDK exists for any of the three products: Paysafe integrations run against the Paysafe Payments REST API directly, or through the hosted checkout iframe. A developer starting a Node.js or Python integration in July 2026 who searched the public registries for "paysafe" or "skrill sdk" would find no first-party official listing — and would then plausibly install paysafe-sdk, paysafe-node, paysafe-payments, or paysafe-checkout on the assumption they were community wrappers.

Coverage caveat

Socket's public write-up describes 13 npm packages total. DependencyWatch has confirmed 9 of the 13 npm names via direct npm registry queries against the exact 12:56-12:57 UTC 2026-07-07 publish window (all with 1.0.0–1.0.3 versions and the 2026-07-08 00:25 UTC coordinated unpublish). The remaining 4 npm names in Socket's count are not yet publicly enumerated; a lockfile that grep-hits any paysafe-*, skrill-*, or neteller-* name not in the canonical @paysafe/* scope and not on the confirmed-legitimate list (skrill-upload, @paysafe-group/paysafe_sdk_nodejs) should be treated as suspect pending vendor confirmation. On PyPI, Socket named paysafe-sdk and paysafe-api explicitly; a third, paysafe-payments, is corroborated in later coverage. All three 404 on PyPI as of 2026-07-09. The fourth PyPI name is not yet publicly enumerated.

Attribution

Socket has not named a threat actor. The infrastructure pattern (AWS-hosted collector, dual npm+PyPI publish, coordinated cross-registry timing, sandbox-detection guard tuned for AV/EDR bypass) is consistent with a mid-tier commercial threat actor rather than a state-linked APT. No overlap with the DPRK PolinRider / Contagious Interview cluster (targets developer workstations, not payment integrations) or the TeamPCP Mini Shai-Hulud cluster (targets npm token theft for worm propagation, not env-var exfil).

Affected packages (12)

Impact

• Any host that installed one of the fake SDKs should be treated as compromised — the payload exfiltrates env vars matching KEY, SECRET, TOKEN, PASS, AUTH, or API regexes to AWS infrastructure. Real-world exposure: AWS access keys, GitHub PATs, npm publish tokens, Paysafe API credentials, hostname, username, and API-usage metadata
• The npm packages present a fully-shaped Paysafe/Skrill/Neteller API surface — initClient(), createPayment(), verifyMerchant(), getSettlement(), etc. — but return fake success responses instead of talking to Paysafe backends. Any integration test that only checked HTTP-status-200 would have passed against the trojaned SDK, so the malware could sit undetected in a Node.js payment integration until real transactions failed
• On npm, the data-theft path is gated by the presence of a Paysafe API key in env or config: exfil only fires once the fake SDK is invoked with a real merchant key. Any dev / CI environment that fed the SDK a real Paysafe test or production key had that key stolen the first time the SDK ran
• On PyPI, the theft routine is embedded in __init__.py and fires on import — no Paysafe key required. Just installing and importing any of the 4 PyPI names exfiltrates env-var secrets universally, making PyPI exposure strictly worse than npm
• The malware includes a sandbox-detection guard: it skips exfil when the host reports fewer than 2 CPU cores OR when the hostname / username contains sandbox, analyzer, cuckoo, virus, malware, vmware, or vbox. Real developer workstations and CI runners almost always fail these checks — the guard exists only to evade automated sandboxing, so it does NOT protect production or dev environments
• All 13 npm packages published four malicious versions (1.0.0 → 1.0.3) in a ~27-minute publish burst on 2026-07-07 between 12:56 and 13:23 UTC. All four npm versions were caught by Socket's AI scanner within ~6 minutes of publication and unpublished by npm Security at 2026-07-08 00:25 UTC — but the CDN cached tarballs remain live briefly and any lockfile hit is a compromise
• PyPI packages shipped one malicious version each (1.0.0). PyPI 404s on all four names as of 2026-07-09 — packages fully retired, but any pip-cache hit or private-mirror copy is still live
• This is not a "developer typo" campaign — it targets engineering teams actively integrating gambling / iGaming / payment gateway providers. Anyone building a Paysafe, Skrill, or Neteller integration in July 2026 who searched npm/PyPI for a Node/Python SDK could plausibly have picked one of these fakes over the vendor's official integration path

What to do

1. 1Grep every package.json, package-lock.json, yarn.lock, pnpm-lock.yaml, requirements.txt, poetry.lock, Pipfile.lock, and private-mirror manifest for the exact names in the packages map below. Any single hit is a supply-chain incident
2. 2If ANY of the 13 npm or 4 PyPI names appears in your lockfiles: rotate every AWS access key, GitHub PAT, npm publish token, Paysafe / Skrill / Neteller API key, and any environment variable matching *KEY*, *SECRET*, *TOKEN*, *PASS*, *AUTH*, or *API* that was reachable from the build host or dev workstation
3. 3The canonical Paysafe SDK is paysafe-checkout-js via the vendor's hosted checkout, or Paysafe's GitHub-published paysafe_sdk_nodejs under the @paysafe-group scope. There is no legitimate paysafe-api, paysafe-payments, paysafe-node, paysafe-vault, paysafe-cards, paysafe-js, or paysafe-checkout package on the public npm registry — every version of those names is malware
4. 4Neither Skrill nor Neteller publishes a first-party npm or PyPI SDK. If you resolved skrill-payments, skrill-sdk, or any neteller-* package on npm, or paysafe-sdk, paysafe-payments, or paysafe-api on PyPI: your integration was built on stolen intent — Paysafe (the parent for Skrill and Neteller) integrations go through the Paysafe Payments API directly, no npm/PyPI SDK required
5. 5Purge Artifactory / Nexus / Verdaccio / internal PyPI mirror caches: internal mirrors routinely cache tarballs and keep serving the malicious versions after the public unpublish
6. 6Sandbox / EDR triage indicators: outbound connections from node or python processes to AWS S3 / EC2 hosts they don't normally talk to; env-var enumeration paths matching the six regex fragments above; sandbox-detection probes reading /proc/cpuinfo, os.cpus(), or hostname/username in the first seconds of import or require()
7. 7Add a review gate for any package with paysafe, skrill, or neteller in its name — no legitimate first-party SDK for any of the three products exists on npm or PyPI as of 2026-07-09; every current such package is either the retired malware or a legitimate but unrelated squat (e.g. the pre-existing paysafe PyPI test package, skrill-upload, or the paysafe-group scoped npm packages under @paysafe/*)

References

• Coordinated npm and PyPI Campaign Typosquats Popular Secure Payment Apps

  socket.dev
  Socket
• 17 npm, PyPI Packages Found Typosquatting Payment SDKs (Paysafe, Skrill, Neteller)

  technadu.com
  TechNadu
• Fake Paysafe, Skrill SDKs on NPM and PyPi steal credentials

  bleepingcomputer.com
  BleepingComputer
• Socket: PyPI and npm payment SDK malware compromises CI/CD

  developer-tech.com
  Developer Tech
• Paysafe Payments API (canonical vendor integration path — no npm/PyPI SDK exists)

  developer.paysafe.com
  Paysafe