Fake Paysafe, Skrill, and Neteller Packages Steal API Keys and Tokens from Developers

Security researchers have found 17 malicious npm and PyPI packages that impersonated developer tools for Paysafe, Skrill, and Neteller while stealing API keys, tokens, passwords, and cloud credentials from developer environments.

The campaign was reported by Socket, which said the packages were published on July 7, 2026 and targeted developers building payment integrations. According to the Socket report, the packages looked like payment SDKs but performed credential theft instead of real payment processing.

The malware searched environment variables for sensitive names such as KEY, SECRET, TOKEN, PASS, AUTH, and API. That means a developer who installed one of the packages may have exposed more than payment credentials, including AWS keys, GitHub tokens, npm tokens, and CI/CD secrets.

What happened

The malicious packages used typosquatting and brand impersonation. They carried names that looked useful to developers searching for Paysafe, Skrill, or Neteller SDKs across npm and PyPI.

Socket said 13 npm packages were published with four malicious versions each, from 1.0.0 through 1.0.3. Four PyPI packages were published with one malicious version each.

A separate BleepingComputer report also noted that the packages pretended to expose expected SDK functions while returning fake success responses, helping the malware stay less obvious during testing.

Registry	Number of malicious packages	Targeted brands	Main goal
npm	13	Paysafe, Skrill, Neteller	Steal secrets from JavaScript and Node.js environments
PyPI	4	Paysafe	Steal secrets from Python environments
Total	17	Payment SDK users	Credential and token theft

Why developers were targeted

Payment integrations often require access to sensitive credentials. Developers may store API keys, sandbox credentials, live payment tokens, and cloud secrets in local environment files, CI/CD systems, or build hosts.

The fake packages tried to exploit that trust. A developer looking for a payment SDK could install a package that appeared to match the brand or function they needed, then run test code that quietly triggered exfiltration.

The legitimate Paysafe server-side SDK documentation lists official SDK options for Java and PHP. That makes package verification important when developers find unofficial or similarly named packages in public registries.

How the fake SDKs worked

One example cited by Socket was the npm package paysafe-node. It exported a PaysafeClient-style class, read variables such as PAYSAFE_API_KEY and PAYSAFE_ENV, and offered methods that looked like payment and customer API calls.

Instead of calling real Paysafe endpoints, the package returned fake success responses. This could make a test script appear to work while the hidden code collected environment data in the background.

The npm packages were designed to exfiltrate data when the fake SDK was used with a Paysafe API key. The PyPI packages were more aggressive because they activated when imported, even if no live Paysafe credential was present.

• The packages collected hostnames, usernames, working directories, timestamps, and matching environment variables.
• They looked for values with names containing KEY, SECRET, TOKEN, PASS, AUTH, or API.
• They could capture payment keys, AWS secrets, GitHub tokens, npm tokens, and CI secrets.
• They sent the stolen data to an attacker-controlled endpoint.
• They used fake API responses to reduce suspicion during developer testing.

Affected malicious package names

Security teams should search dependency files, lock files, CI logs, local development machines, and registry proxy logs for the package names tied to the campaign.

Registry	Malicious package name	Impersonated area
npm	paysafe-checkout	Paysafe checkout integration
npm	paysafe-vault	Paysafe vault or token storage integration
npm	neteller	Neteller payment or wallet integration
npm	skrill-payments	Skrill payment integration
npm	paysafe-js	Paysafe JavaScript integration
npm	paysafe-api	Paysafe API integration
npm	paysafe-node	Paysafe Node.js integration
npm	paysafe-cards	Paysafe card payment integration
npm	paysafe-fraud	Paysafe fraud or risk integration
npm	paysafe-kyc	Paysafe KYC integration
npm	skrill	Skrill integration
npm	skrill-sdk	Skrill SDK integration
npm	paysafe-payments	Paysafe payments integration
PyPI	paysafe-kyc	Paysafe KYC integration
PyPI	paysafe-payments	Paysafe payments integration
PyPI	paysafe-sdk	Paysafe SDK integration
PyPI	paysafe-api	Paysafe API integration

Why this campaign is dangerous

The attack focused on developer environments, where secrets often have broad access. A stolen token from a laptop or CI runner can unlock source code, package publishing access, cloud accounts, deployment systems, or payment API access.

That gives the campaign a wider blast radius than a simple fake payment library. Even if a victim never used Paysafe in production, the malware could still steal unrelated credentials from the same environment.

Socket’s research on the campaign also found anti-analysis checks, per-file obfuscation, and hidden command-and-control decoding, which suggests the attacker expected automated scanning and tried to evade simple signature checks.

Malware evasion and command infrastructure

The malware checked for signs of sandbox analysis before sending stolen data. It looked for fewer than two CPU cores and scanned hostnames or usernames for words associated with malware labs and virtual machines.

The command-and-control hostname was not stored plainly. Socket said the packages used several decoding steps, including XOR decoding, a character shift, and string reversal, before revealing an ngrok-free.dev hostname.

The attacker used ngrok infrastructure for exfiltration. Ngrok is a legitimate tunneling service, but attackers often abuse tunneling domains because they can hide the true location of backend infrastructure and change endpoints quickly.

Indicator type	Indicator	Use
Domain	caliber-spinner-finishing[.]ngrok-free[.]dev	Command-and-control domain used for data exfiltration
URL	hxxps://caliber-spinner-finishing[.]ngrok-free[.]dev:443/	HTTPS endpoint receiving JSON payloads
File	index.js	Malicious JavaScript file used in npm packages
File	__init__.py	Malicious Python file used in PyPI packages
Pattern	KEY, SECRET, TOKEN, PASS, AUTH, API	Environment variable keywords harvested by the malware

Why fake payment SDKs are convincing

Payment SDKs usually expose predictable functions, such as create payment, get payment, create customer, and get customer. A malicious package can copy those names without connecting to the real payment platform.

That creates a dangerous illusion. A developer may run a basic test, see a success response, and continue building while credentials leave the machine in the background.

Official Paysafe integration documentation remains the safer starting point because it points developers toward supported SDKs and official API references rather than lookalike packages published by unknown maintainers.

What exposed teams should do now

Any developer or organization that installed one of the listed packages should treat the machine and its environment variables as compromised. Removing the package alone does not remove the risk because the attacker may already have copied secrets.

Security teams should rotate every secret that may have been present in the affected environment. That includes payment API keys, AWS credentials, GitHub tokens, npm publishing tokens, PyPI tokens, database passwords, webhook secrets, and CI/CD credentials.

The response should also include registry-level controls. The npm Trusted Publishing model can reduce reliance on long-lived publishing tokens in CI/CD workflows, which limits the impact when build environments get exposed.

1. Remove the malicious package from every project, lock file, container image, and build cache.
2. Rotate all secrets from machines or CI runners that imported or executed the package.
3. Search logs for outbound HTTPS traffic to ngrok-free.dev domains.
4. Audit CI logs for PAYSAFE_API_KEY usage with any listed package name.
5. Check GitHub, npm, PyPI, AWS, and payment provider logs for suspicious access after installation.
6. Block the malicious package names at the registry proxy or dependency firewall level.
7. Review dependency approvals for payment, wallet, and financial SDK packages.

How to reduce future risk

Developers should avoid installing payment packages based on name alone. Before adding a dependency, teams should check the publisher, project history, repository links, download patterns, maintainer identity, package age, and official vendor documentation.

Organizations should also reduce the number of secrets available to local development machines and CI runners. Short-lived credentials, scoped tokens, and workload identity can reduce the value of stolen environment variables.

For Python publishing workflows, PyPI Trusted Publishers can replace long-lived API tokens with short-lived tokens issued through OpenID Connect. That approach helps reduce exposure when CI environments face dependency attacks.

• Use official vendor links when selecting payment SDKs.
• Pin dependencies and review new packages before installation.
• Scan lock files for typosquatted names and newly published packages.
• Do not store broad cloud or registry tokens in local shells without a clear need.
• Use short-lived credentials for CI/CD wherever possible.
• Monitor package installation events in developer and build environments.
• Require approval for new dependencies that touch payments, authentication, or deployment.

The bigger supply-chain lesson

This campaign shows how attackers can target the moment developers search for a library. Payment brands create attractive lures because integrations often require secrets and connect to high-value systems.

The risk also extends beyond payment companies. Any popular API, cloud service, cryptocurrency project, analytics platform, or internal SDK can become a typosquatting target if developers rely on package names without verification.

The BleepingComputer coverage reinforces the central concern: the packages were built to look useful while silently harvesting credentials from developer and CI/CD environments.

Teams that publish JavaScript packages should also review npm trusted publishing guidance to reduce dependence on long-lived tokens. Teams that publish Python packages should review PyPI trusted publishing guidance for the same reason.

The attack is a reminder that software supply-chain security starts before code reaches production. A single fake dependency can turn a developer workstation or CI runner into a credential collection point.

FAQ