Fake Paysafe, Skrill and Neteller SDKs on npm and PyPI Steal CI/CD Secrets
Seventeen packages impersonating payment-provider SDKs returned convincing fake success responses while quietly harvesting environment-variable secrets to an ngrok-tunnelled command-and-control server.
Key Takeaways
- 17 packages (13 on npm, 4 on PyPI) impersonated Paysafe, Skrill and Neteller payment SDKs, mimicking real API calls and returning fake success responses while stealing secrets.
- The malware scraped any environment variable matching `KEY`, `SECRET`, `TOKEN`, `PASS`, `AUTH` or `API` — capturing AWS, GitHub and npm credentials alongside payment keys.
- Exfiltration used three layers of obfuscation (XOR, character-shifting, string reversal) to hide a C2 address routed through an ngrok tunnel previously tied to njRAT infrastructure.
- Socket's scanning flagged the npm packages within about six minutes of publication — fast, but still enough of a window for an automated CI job to pull and execute one.
What happened
On 7 July 2026, researchers at Socket identified a coordinated campaign of 17 malicious packages — 13 published to npm and 4 to PyPI — typosquatting SDKs for the payment providers Paysafe, Skrill and Neteller. Package names such as paysafe-checkout, paysafe-vault, paysafe-kyc, skrill-sdk and neteller were designed to catch developers integrating or testing payment flows, with each npm package pushed through four incremental versions (1.0.0–1.0.3).
How the malware worked
Rather than failing or throwing obvious errors, the fake SDKs exposed the method surface a developer would expect from a real payment integration and returned believable success responses. That facade bought the payload time to run undetected in a local dev environment or, more consequentially, inside a CI/CD pipeline.
In the background, the packages scanned environment variables for names containing KEY, SECRET, TOKEN, PASS, AUTH or API — a net wide enough to catch PAYSAFE_API_KEY alongside unrelated secrets like AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN and NPM_TOKEN.
The exfiltration channel
Captured values were shipped out over HTTPS to a command-and-control host resolved through three separate decoding steps — XOR decryption, a character-code shift, and a string reversal — landing on caliber-spinner-finishing.ngrok-free.dev. Socket noted the resolved ngrok endpoint had previously been used as C2 infrastructure for the njRAT infostealer, suggesting the campaign operators reused or rented existing criminal tooling rather than standing up something bespoke.
Why this matters beyond payments teams
The payment-SDK branding is a lure, not the target. The actual objective is generic CI/CD credential theft: cloud keys, source-control tokens and registry publishing tokens are all more valuable to an attacker than a sandboxed payment-processor test key, and all sit in the same environment-variable namespace a build pipeline exposes to every dependency it installs.
What to do about it
- Check lockfiles and CI logs for any of the named npm or PyPI packages, in any of their 1.0.x versions
- Rotate every credential that was present in an environment where one of these packages executed
- Use dependency-scanning tooling (Socket, OSV-Scanner, npm/PyPI provenance checks) as a CI gate, not just a local dev habit
- Scope CI secrets narrowly and short-lived, so a leaked token has minimal blast radius and a short useful life
- Treat unfamiliar packages claiming to wrap a well-known fintech API with the same scrutiny as an unsolicited email attachment
None of this implicates Paysafe, Skrill or Neteller themselves — their real infrastructure was not compromised. The packages simply borrowed recognisable brand names to get past a developer's guard.
Frequently Asked Questions
Were Paysafe, Skrill or Neteller's own systems compromised?
No. These were typosquatted, unrelated packages published under lookalike names on npm and PyPI — Socket's report describes no compromise of the real providers' infrastructure.
What made this campaign hard to catch by eye?
The fake SDKs implemented the expected method calls and returned convincing success responses instead of errors, so a developer testing an integration would see normal-looking behavior while secrets were exfiltrated in the background.
Why go after CI/CD environment variables instead of just payment keys?
Build environments routinely expose cloud, source-control and registry credentials as environment variables to every installed dependency, making them a far more valuable and generic target than a single payment-processor key.