Researchers found 17 fake Paysafe, Skrill and Neteller packages on npm and PyPI that steal API keys and CI tokens from developer and build machines. Nothing was breached at the payment firms. The exposure came through a poisoned dependency, which shows why the package registry is a supplier.
Researchers found 17 malicious software packages that impersonate the Paysafe, Skrill and Neteller payment kits, published to two open-source registries (npm for JavaScript and PyPI for Python) on 7 July 2026. Any developer who installed one and ran it risked handing over the secrets on their machine or build server: Paysafe API keys, Amazon Web Services (AWS) keys, and GitHub and npm access tokens. Nothing was breached at Paysafe, Skrill or Neteller. The exposure came through a poisoned dependency, a component pulled into other people's code. The lesson: your suppliers include every open-source package your build trusts, and one fake can drain the credentials that reach everything downstream.
What happened
The application security firm Socket reported the campaign on 7 July 2026, and BleepingComputer covered it on 8 July 2026. Socket's scanner found 17 packages published almost simultaneously, 13 on npm and 4 on PyPI. Each carried a name that mimics a real payment SDK (software development kit, the prebuilt code developers use to add a feature), such as paysafe-node, skrill-sdk and paysafe-payments. The packages returned fake success responses so an integration looked normal, while searching the environment for any variable whose name contained KEY, SECRET, TOKEN, PASS, AUTH or API. Matches were sent to an attacker-controlled command-and-control server (the machine that collects stolen data). Socket says the harvested secrets would in practice include the Paysafe API key, the AWS secret key, and GitHub and npm tokens. The npm code ran only when a Paysafe key was present; the PyPI code ran on install regardless. The malware also skipped machines that looked like security sandboxes. npm flagged the packages as malicious within six minutes. The identity of the actor is not confirmed, and Socket believes it is capable and may return.
Why it matters for third-party risk
This is the dependency-as-supplier pattern. A payment integration is assembled from third-party code, and the registry is the supply route. When a developer installs a look-alike package, the exposure does not stop at one laptop. Stolen AWS keys, GitHub tokens and npm tokens reach cloud accounts, source repositories, and the packages a team itself publishes, so one poisoned dependency can extend into every system and customer downstream. Concentration makes it worse: thousands of teams pull from the same two registries, so a single believable typo-name can scatter across many victims at once.
What teams should take from it
Treat the package registry as a supplier and put a gate in front of it: pin exact versions, block install-time scripts, and verify a package name before it enters a build. Then assume any secret that ever sat in a build environment is reachable, so keep credentials short-lived and rotate them on a schedule, not only after an incident. To see how continuous vendor and dependency monitoring works, Acuna's supplier-risk resource sets out the practice.
FAQ
Were Paysafe, Skrill or Neteller breached?
No. The packages only impersonated their SDKs. The companies' own systems were not involved, according to Socket's report.
What was actually stolen?
Environment secrets on any machine that installed and ran a package: Paysafe API keys, AWS keys, and GitHub and npm tokens, plus basic host details such as hostname and username.
What should a team do if it installed one?
Rotate every secret on the affected machine or build server, search dependency trees for the 17 package names, block them at the registry proxy, and check continuous integration (CI) logs for those names alongside PAYSAFE_API_KEY.
Want this applied to your supplier ecosystem? See the platform in action and map your top vendor risks live in one walkthrough.
