Summary
- Socket found 17 malicious npm and PyPI packages impersonating Paysafe, Skrill, and Neteller SDKs.
- The packages targeted developer secrets, credentials, and tokens rather than end-user payment data alone.
- The campaign reinforces the need to treat package installation as a credential-exposure event in software delivery environments.
Attackers have used fake software development kits impersonating payment brands to target developer credentials across npm and PyPI, extending software supply chain risk into payment-adjacent engineering workflows.
Socket said it found 17 malicious packages typosquatting Paysafe, Skrill, and Neteller SDKs. The packages were published on 7 July and were designed to steal developer secrets and tokens, with stolen data exfiltrated to AWS infrastructure. The campaign affected both npm and the Python Package Index, with the npm packages published in several malicious versions and the PyPI packages appearing in one malicious version each at the time of Socket’s analysis.
The package names were chosen to look plausible to developers integrating payment-related services, including names such as paysafe-node, paysafe-api, paysafe-payments, skrill-sdk, and neteller. In one example analysed by Socket, a fake Paysafe client mimicked the behaviour of a real REST client by reading environment variables and exposing payment and customer methods, while returning simple success responses rather than making genuine outbound calls to Paysafe endpoints.
Socket’s technical write-up shows how these campaigns create damage without compromising a production payment gateway directly. A malicious package can harvest secrets from developer machines, build environments, test systems, or continuous integration pipelines where API keys, SSH keys, cloud tokens, and service credentials may be present.
Payment branding makes the lure more effective because it targets a context where developers expect to handle credentials. Teams integrating payment applications often work with environment variables, sandbox keys, test merchant accounts, webhooks, and deployment scripts. A package that appears to be a payment SDK can therefore ask for or access sensitive configuration in a way that looks normal during development. Once a secret is stolen from a developer context, the downstream risk can move into cloud services, repositories, deployment infrastructure, and customer-facing systems.
UK and European organisations face exposure across software delivery and third party governance. Payment integrations are often built by internal product teams, contractors, agencies, or outsourced development partners. A malicious dependency installed during a sprint or proof of concept may not be visible to central security teams until credentials are abused. The incident also complicates assurance for firms subject to PCI DSS, GDPR, DORA, NIS2, or internal supplier-security requirements, because developer secrets can become a route into regulated environments.
The campaign adds weight to controls that remain unevenly implemented. Organisations need package allowlists for sensitive projects, lockfile review, dependency provenance checks, registry monitoring, short-lived credentials, scoped tokens, secret scanning, and rapid credential rotation when malicious package exposure is suspected. Development environments should not hold broad production credentials, and CI/CD systems should limit what any package install process can read or exfiltrate.
The npm and PyPI ecosystems have introduced stronger controls over time, but attackers continue to exploit naming trust, installation habits, and the speed of modern development. Typosquatting remains effective because dependency decisions are often made quickly, sometimes under pressure to ship integrations. The combination of plausible brand names and credential harvesting gives attackers a low-friction route into environments that may be better protected at the perimeter than at the developer workstation.
Organisations that installed the named packages should remove the malicious dependencies, inspect development and CI logs, and rotate exposed credentials. The broader exposure sits in the software delivery chain, where a single package install can become a credential event if sensitive secrets are available to the development environment.
