Malicious npm and PyPI Packages Impersonate PaySafe, Skrill and Neteller SDKs

Seventeen malicious npm and PyPI packages impersonating PaySafe, Skrill and Neteller SDKs were caught harvesting developer credentials before most were removed, but any team that installed them should rotate secrets immediately.

Omar Al-Hakeem
Senior Cyber Threat Analyst | MENA Region3 min read
Developer workstation showing code editor and terminal during a supply chain security review

Developer workstation showing code editor and terminal during a supply chain security review

A coordinated supply chain attack struck the open source software ecosystem on 7 July, when automated scanners detected 17 malicious packages published nearly simultaneously across the npm and PyPI registries. The packages were built to mimic legitimate software development kits for three widely used payment platforms, PaySafe, Skrill and Neteller, using typosquatting and deceptive naming to trick developers into pulling them into their own projects.

The mechanism is what makes this campaign notable rather than routine. In the malicious paysafe-node package, the attackers built a client that convincingly mirrors a legitimate Paysafe REST client, reading environment variables for configuration and exposing the standard API endpoints developers expect for creating and retrieving payments or customer records. Instead of making genuine outbound calls to Paysafe, the fake SDK simply returns a simulated success message. A developer testing the integration sees no errors and no reason for suspicion, while the malicious code quietly harvests credentials in the background.

Once installed, the packages hunt through environment variables for anything containing keywords such as KEY, SECRET, TOKEN, PASS, AUTH or API, putting AWS access keys, GitHub tokens and npm publish tokens directly at risk. The PyPI variants are more aggressive still, executing their payload immediately on installation without needing a live API key to trigger. To avoid detection during analysis, the malware checks the host's hardware and hostname before acting, aborting if it detects fewer than two CPU cores or spots security related keywords in the machine name, both common markers of an automated sandbox rather than a real developer environment. Stolen data is routed out through a three step obfuscation process involving XOR encryption, character shifting and string reversal, ultimately reaching an Ngrok hosted domain, a technique frequently used to slip past conventional firewall rules.

What this means if your team touched these packages

The packages were detected and flagged within minutes of publication, which limited exposure but does not eliminate it for anyone who imported or executed a package matching names such as paysafe-checkout, skrill-payments or paysafe-sdk. Any environment where one of these packages was installed or run should be treated as compromised rather than merely at risk. The immediate priority is rotating every secret on the affected machine, with particular attention to environment variables matching the malware's own targeting keywords, since those are precisely the credentials the attackers were built to find first.

Why this matters beyond the immediate incident

The npm and PyPI ecosystems continue to be a favoured entry point for attackers targeting financial technology specifically, and this campaign's structure, spanning two separate package ecosystems with distinct obfuscation keys per version, suggests a threat actor with a real understanding of both developer workflows and the defensive tooling built to catch them. The underlying risk mirrors a theme MCW has covered in the context of compromised developer and build tooling exposing customers downstream, where trust placed in a vendor's or a package's supply chain becomes the attacker's actual entry point rather than the target application itself. For fintech and payment platform developers building against these SDKs, the practical lesson is to verify package provenance before installation rather than after, checking publish history, maintainer reputation and download counts against the official SDK documentation rather than trusting a plausible sounding package name in a search result. Given the pace at which this actor iterated across ecosystems, a repeat attempt under new package names is a reasonable expectation rather than a remote possibility.

Omar Al-Hakeem

Senior Cyber Threat Analyst | MENA Region

Omar Al-Hakeem is a cybersecurity researcher specializing in threat intelligence, ransomware trends, and nation-state activity across the Middle East and North Africa. With over 12 years of experience in SOC operations and incident response, he provides deep technical breakdowns of emerging attacks and regional cyber risks. At MENA Cyber Wire, Omar focuses on real-world threat analysis and actionable defense strategies for enterprises and startups.

Intelligence Focus Areas

Supply Chain SecurityThreat IntelligenceFintech Security