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

> Socket detected a coordinated cross-registry campaign on 2026-07-07 12:56 UTC: 13 npm and 4 PyPI packages impersonating the Paysafe / Skrill / Neteller payment SDKs, exposing plausible legitimate APIs but shipping a credential-theft module that harvests `KEY` / `SECRET` / `TOKEN` / `PASS` / `AUTH` / `API` env vars and Paysafe API keys and exfiltrates them to attacker-controlled AWS infrastructure. All npm versions unpublished ~2026-07-08 00:25 UTC.

- Published: 2026-07-07
- Last updated: 2026-07-09
- Severity: critical
- Kind: Typosquat - A package that never had a legitimate version, named to be mistaken for a real one - a misspelling, a lookalike scope, or an impersonated vendor SDK.
- Ecosystems: npm, PyPI
- Scope: 12 packages, 39 compromised versions
- Tags: typosquat, credential-theft, infostealer, dns-exfiltration
- Also known as: Paysafe SDK typosquat campaign, Skrill/Neteller npm+PyPI campaign, Socket payment SDK malware 2026-07
- Detected by: Socket
- Incident ID: multi-2026-07-07-paysafe-skrill-payment-sdk-typosquat

## Affected packages (12)

Only the exact versions listed were named by the source advisories. Other versions are not implicated.

| Package | Ecosystem | Compromised versions |
|---|---|---|
| [paysafe-api](https://dependencywatch.io/package/npm/paysafe-api) | npm | 1.0.0, 1.0.1, 1.0.2, 1.0.3 |
| [paysafe-api](https://dependencywatch.io/package/pypi/paysafe-api) | PyPI | 1.0.0 |
| [paysafe-cards](https://dependencywatch.io/package/npm/paysafe-cards) | npm | 1.0.0, 1.0.1, 1.0.2, 1.0.3 |
| [paysafe-checkout](https://dependencywatch.io/package/npm/paysafe-checkout) | npm | 1.0.0, 1.0.1, 1.0.2, 1.0.3 |
| [paysafe-js](https://dependencywatch.io/package/npm/paysafe-js) | npm | 1.0.0, 1.0.1, 1.0.2, 1.0.3 |
| [paysafe-node](https://dependencywatch.io/package/npm/paysafe-node) | npm | 1.0.0, 1.0.1, 1.0.2, 1.0.3 |
| [paysafe-payments](https://dependencywatch.io/package/npm/paysafe-payments) | npm | 1.0.0, 1.0.1, 1.0.2, 1.0.3 |
| [paysafe-payments](https://dependencywatch.io/package/pypi/paysafe-payments) | PyPI | 1.0.0 |
| [paysafe-sdk](https://dependencywatch.io/package/pypi/paysafe-sdk) | PyPI | 1.0.0 |
| [paysafe-vault](https://dependencywatch.io/package/npm/paysafe-vault) | npm | 1.0.0, 1.0.1, 1.0.2, 1.0.3 |
| [skrill-payments](https://dependencywatch.io/package/npm/skrill-payments) | npm | 1.0.0, 1.0.1, 1.0.2, 1.0.3 |
| [skrill-sdk](https://dependencywatch.io/package/npm/skrill-sdk) | npm | 1.0.0, 1.0.1, 1.0.2, 1.0.3 |

## 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](https://developer.paysafe.com/en/api-docs/payments-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).

## 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. Grep 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. If 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. The canonical Paysafe SDK is [`paysafe-checkout-js`](https://developer.paysafe.com/) 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. Neither 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](https://developer.paysafe.com/en/api-docs/payments-api/) directly, no npm/PyPI SDK required
5. Purge Artifactory / Nexus / Verdaccio / internal PyPI mirror caches: internal mirrors routinely cache tarballs and keep serving the malicious versions after the public unpublish
6. Sandbox / 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. Add 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/*`)

## Check your own dependencies

- Check a package-lock.json against this incident: https://dependencywatch.io/check/package-lock-json
- Check a requirements.txt against this incident: https://dependencywatch.io/check/requirements-txt

The scan runs entirely in the browser; lockfile contents are never uploaded.

## References

- [Coordinated npm and PyPI Campaign Typosquats Popular Secure Payment Apps](https://socket.dev/blog/npm-pypi-campaign-typosquats-popular-secure-payment-apps) - Socket
- [17 npm, PyPI Packages Found Typosquatting Payment SDKs (Paysafe, Skrill, Neteller)](https://www.technadu.com/17-npm-pypi-packages-found-typosquatting-payment-sdks-paysafe-skrill-and-neteller/630575/) - TechNadu
- [Fake Paysafe, Skrill SDKs on NPM and PyPi steal credentials](https://www.bleepingcomputer.com/news/security/fake-paysafe-skrill-sdks-on-npm-and-pypi-steal-credentials/) - BleepingComputer
- [Socket: PyPI and npm payment SDK malware compromises CI/CD](https://www.developer-tech.com/news/socket-pypi-and-npm-payment-sdk-malware-compromises-ci-cd/) - Developer Tech
- [Paysafe Payments API (canonical vendor integration path - no npm/PyPI SDK exists)](https://developer.paysafe.com/en/api-docs/payments-api/) - Paysafe

---

Canonical page: https://dependencywatch.io/incident/multi-2026-07-07-paysafe-skrill-payment-sdk-typosquat
Markdown version: https://dependencywatch.io/incident/multi-2026-07-07-paysafe-skrill-payment-sdk-typosquat.md
Site index for agents: https://dependencywatch.io/llms.txt
DependencyWatch.io is operated by Precursor Security (https://precursorsecurity.com).