Fake Paysafe and Skrill SDKs Found on npm and PyPI

Someone spent a weekend impersonating payment SDKs, and it worked well enough to warrant a warning. Researchers at Socket found 17 malicious packages sitting on npm and PyPI, pretending to be official libraries for Paysafe, Skrill and Neteller. Those three names matter because they show up in e-commerce, online betting, crypto exchanges and Forex brokerages, which is a nicely lucrative slice of the developer population to target.

The packages looked the part. They exposed the expected APIs, returned plausible success responses, and generally behaved like something a developer might spend thirty seconds checking before moving on. What they did not do was actually talk to Paysafe.

What the packages actually did

Instead of processing payments, the embedded code went rummaging through the developer's environment. It hunted for anything valuable it could find, then shipped the results off to a command-and-control server hosted, with a certain cheek, on AWS. The specific items on the shopping list:

• Paysafe API keys
• AWS credentials
• GitHub tokens
• npm tokens
• Hostnames, usernames, and metadata about how the APIs were being called

The two ecosystems behaved slightly differently. The 13 npm packages went through four versions, 1.0.0 through 1.0.3, and only triggered the theft when the fake SDK was actually called with a real Paysafe API key present. The four PyPI packages shipped a single version each and fired the moment they were imported, no key required. Both variants included light anti-analysis tricks: they refuse to run on machines with fewer than two CPU cores, or on hostnames that look like sandboxes.

Cleaning up if you touched one

Socket could not pin the campaign on anyone specific, but they did note the attacker is comfortable pivoting between package ecosystems. That is awkward if your monitoring only watches one of them, which is more common than it should be.

If any of the listed packages made it into a build, the advice is blunt:

• Rotate every secret on any machine that touched them, not just the Paysafe key.
• Search dependency trees for the offending package names, including transitive ones.
• Block them at your registry proxy so no one accidentally re-pulls them.
• Grep CI logs for PAYSAFE_API_KEY appearing near any of the package names.

Why this keeps happening

Typo-squatted and lookalike packages on public registries have become a routine way to get code running inside otherwise well-run engineering teams. The developers pulling these in are not careless. They are busy, they are shipping, and the packages are designed to pass a quick glance. A convincing README and a working API surface is often all it takes.

The interesting question is not whether developers should be more suspicious of every install, because at some point that stops being a job description and starts being a full-time hobby. It is whether the build pipeline itself is doing any of that scrutiny automatically, or whether the whole thing runs on trust and vibes. Worth a look at what yours actually validates before it lets a package near a production secret.