On July 7, 2026, a threat actor published 17 malicious packages in a single coordinated wave — 13 on npm and 4 on PyPI — impersonating official software development kits for Paysafe, Skrill, and Neteller, three of the most widely used digital wallet and payment brands in e-commerce and online gaming. The packages looked like payment SDKs, exposed the method surface developers expect from payment SDKs, and returned convincing success responses. They never contacted a payment platform. Instead, they harvested API keys, AWS credentials, GitHub and npm tokens, and any environment variable that looked like a secret, and shipped the haul over HTTPS to a command-and-control endpoint hidden behind an ngrok tunnel.

Socket, whose AI-driven registry scanner detected the npm cluster within six minutes of publication, published the full analysis on July 8. The speed of detection is the good news. The bad news is everything else: the campaign required no compromise of any legitimate maintainer, no stolen credentials, no zero-day. The attacker simply registered plausible names that three major payment brands had left unclaimed on public registries and waited for developers to install them.

This article covers what the campaign did, why payment-brand impersonation is a structurally attractive attack, and — the part that matters for readers of this site — why “a developer installed a malicious package” is no longer just a security incident. Under the EU Cyber Resilience Act, NIS2, PCI DSS 4.0, and the US federal secure software attestation regime, it is increasingly a compliance failure with a paper trail.

The Campaign: Fake SDKs That Say Yes

Socket’s analysis identifies the full package set. On npm: paysafe-checkout, paysafe-vault, paysafe-js, paysafe-api, paysafe-node, paysafe-cards, paysafe-fraud, paysafe-kyc, paysafe-payments, skrill, skrill-sdk, skrill-payments, and neteller — each published in four malicious versions (1.0.0 through 1.0.3). On PyPI: paysafe-kyc, paysafe-payments, paysafe-sdk, and paysafe-api, each at version 1.0.0. The simultaneous publication, shared code patterns, and shared infrastructure mark this as one actor running one playbook across two ecosystems.

The deception was functional, not just cosmetic. The paysafe-node package, for example, read PAYSAFE_API_KEY and PAYSAFE_ENV from the environment and exposed the methods a developer would expect — payments.create, payments.get, customers.create, customers.get — returning { success: true, method, path } without ever making a real API call. A developer prototyping a payment integration could wire it in, watch their tests pass, and move on. That is the trap: a fake SDK that appears to work survives in a codebase far longer than one that throws errors.

While presenting that facade, the malware did its actual job:

  • Secret harvesting. It swept environment variables whose names contained KEY, SECRET, TOKEN, PASS, AUTH, or API (values capped at 100 characters) — a pattern that scoops up PAYSAFE_API_KEY, AWS_SECRET_ACCESS_KEY, GITHUB_TOKEN, NPM_TOKEN, and essentially every credential a CI runner or developer laptop holds in its environment.
  • Host fingerprinting. Hostname, username, current working directory, timestamp, the package name, and the first ten characters of any Paysafe API key were bundled into the exfiltration payload.
  • Exfiltration. Data went out as HTTPS POST requests to caliber-spinner-finishing.ngrok-free.dev — an ngrok tunnel whose underlying resolved IP, Socket notes, had a prior reputation for hosting other stealer infrastructure including NjRAT.
  • Evasion. The C2 domain was obfuscated through three encoding layers (XOR decryption, character-code subtraction, and string reversal), and the malware exited early on machines with fewer than 2 CPU cores or hostnames/usernames containing strings like sandbox, cuckoo, vmware, or vbox — basic but effective analysis-environment detection.

One behavioral detail is worth flagging because it changes the victim profile. The npm variants triggered only when a Paysafe API key was present and the fake SDK was actually invoked — targeting developers genuinely building payment integrations, precisely the machines and pipelines holding live payment credentials. The PyPI variants fired on import, unconditionally — casting a wider net that catches anyone who so much as installs and initializes the package. Reported download counts were not published, and given the six-minute detection window the direct blast radius may be small. The template, however, is now proven and public.

Why Payment Brands, and Why This Keeps Working

This campaign sits in a well-established lineage. It is the same registry-abuse pattern we analyzed in the GemStuffer RubyGems campaign, where 150+ malicious gems turned a package registry into an exfiltration channel — different ecosystem, same structural weakness. Public registries are open publication platforms with weak identity guarantees, and name availability is first-come, first-served.

Payment brands are especially productive lures for three reasons.

First, the names were available. Paysafe, Skrill, and Neteller distribute their real SDKs through their own channels and documented package names. The obvious, guessable names — neteller, skrill, paysafe-api — were sitting unregistered on npm and PyPI. This is brand impersonation more than classic typosquatting: the attacker did not need a developer to mistype anything, only to search the registry for a payment brand and trust the top result. Any company whose brand implies an SDK, and which has not defensively registered the plausible package names, has left this door open.

Second, the victims are self-selecting and high-value. A developer who installs paysafe-payments is, almost by definition, building payment functionality. Their environment contains payment API keys, and their employer sits inside the payment ecosystem — a merchant, a PSP integrator, a fintech. Stealing PAYSAFE_API_KEY is a direct path to payment fraud; stealing the accompanying GITHUB_TOKEN and NPM_TOKEN is a path to something worse — publishing malicious code as the victim, converting one compromised developer into a second-order supply chain attack on everything they maintain.

Third, CI/CD is where the secrets concentrate. Modern build pipelines inject credentials as environment variables by design. A malicious package that executes during npm install or on first import inside a CI runner harvests the pipeline’s entire secret set in one pass. The environment-variable sweep in this campaign was not incidental — it is the whole business model.

The 2026 Verizon DBIR documented third-party and supply chain involvement in breaches doubling year over year. Registry malware campaigns like this one are the volume end of that statistic: cheap to run, endlessly repeatable, and — until recently — treated by most organizations as someone else’s problem.

The Regulatory Position: Your Dependencies Are Your Product

That “someone else’s problem” framing is now legally obsolete for most software producers. Across the major regimes, the direction of travel is identical: the components you pull into your product are your responsibility, and you must be able to demonstrate the diligence.

EU Cyber Resilience Act

The Cyber Resilience Act — Regulation (EU) 2024/2847, with its reporting obligations phasing in through 2026 and full application in December 2027 — is the sharpest instrument here. Manufacturers of products with digital elements must meet the Annex I essential cybersecurity requirements, and Article 13 requires that manufacturers exercise due diligence when integrating components sourced from third parties, including open-source components, so that those components do not compromise the product’s security. Annex I Part II adds vulnerability-handling requirements that include identifying and documenting components contained in the product, including by drawing up a software bill of materials.

Read against this campaign: a manufacturer whose developer installed paysafe-node from npm without any vetting process, whose build shipped with an unreviewed dependency, and who cannot produce an SBOM showing what is in the product, has a demonstrable Annex I gap — before any incident occurs. The CRA’s penalty ceiling for essential-requirement violations is EUR 15 million or 2.5% of global annual turnover.

NIS2

For essential and important entities in the EU, NIS2 Article 21(2)(d) requires cybersecurity risk-management measures covering supply chain security, including security-related aspects of the relationships between each entity and its direct suppliers or service providers. Regulators and national implementing guidance have consistently read “suppliers” to include software suppliers — and open-source components consumed from public registries are software supply, whether or not money changes hands. An entity whose developer workstations and CI systems can install arbitrary packages from public registries, with no allow-listing, review, or monitoring, will struggle to defend its Article 21 measures as “appropriate and proportionate” after a registry-malware incident.

PCI DSS 4.0

This campaign targeted the payment ecosystem, which makes PCI DSS directly relevant. Requirement 6.3.2 — one of the future-dated requirements that became mandatory with the March 31, 2025 deadline and is now fully enforced — requires entities to maintain an inventory of bespoke and custom software, and of the third-party software components incorporated into it, to facilitate vulnerability and patch management. Requirement 6.2 requires that bespoke and custom software be developed securely, with code review and developer training. An assessor examining a payment application after an incident like this will ask a simple question: does your 6.3.2 inventory list paysafe-api version 1.0.2, and if it does, who approved it and against what criteria? If the honest answer is that no inventory exists at the granularity of transitive npm dependencies, the requirement is not met.

NIST SSDF and US federal attestation

NIST SP 800-218 (the Secure Software Development Framework) dedicates a practice family to exactly this problem: PW.4, “Reuse Existing, Well-Secured Software”, which calls for acquiring and evaluating third-party components against defined security criteria, verifying their provenance and integrity, and monitoring them for vulnerabilities across the lifecycle. The SSDF stopped being advisory the moment OMB M-22-18 and M-23-16 required software producers selling to US federal agencies to submit the CISA Secure Software Development Attestation Form — a signed, enforceable statement that the producer follows SSDF-derived practices, explicitly including maintaining trusted source code supply chains and provenance for internal and third-party components. A producer whose pipeline would have ingested this campaign’s packages unchecked is attesting to practices it does not have, and false attestations carry False Claims Act exposure.

SBOM as the connective tissue

Every one of these regimes converges on the software bill of materials: CRA Annex I requires one, federal procurement expects one on request, PCI 6.3.2’s inventory is functionally one, and NIS2 supply-chain measures are unauditable without one. The operational point this campaign makes is that an SBOM is not a compliance artifact to generate at release time — it is the query surface you need on the day Socket publishes a package list. Organizations that could answer “do we have any of these 17 packages anywhere in any dependency tree?” within an hour on July 8 had an SBOM program. Organizations that needed a week of grepping did not.

Engineering Controls That Actually Address This

Regulatory language aside, the controls that would have stopped or contained this specific campaign are well understood and mostly cheap.

1. Registry allow-listing through an internal proxy. Route all package installs — developer machines and CI — through an internal registry proxy (Artifactory, Nexus, or equivalent) that mirrors approved packages only. New packages enter the mirror through a request-and-review gate. This single control defeats the entire campaign: none of the 17 packages would ever have been installable.

2. Quarantine new and low-reputation packages. If a full allow-list is too heavy, enforce a cooling-off policy: no package (or version) less than N days old, with no download history, from a publisher with no track record. Every package in this campaign was hours old at version 1.0.x from a fresh account. Age-and-reputation gating is crude and would have worked.

3. Pin and lock everything. Committed lockfiles (package-lock.json, poetry.lock, uv.lock), exact-version pinning, and npm ci in pipelines ensure that what you reviewed is what you build. Pinning does not stop the initial bad choice, but it stops silent drift and makes the dependency set auditable — which is what 6.3.2 and the CRA actually demand.

4. Verify provenance. npm’s provenance attestations and Sigstore signing link a published package to the source repository and CI workflow that built it. None of these fake SDKs could have presented provenance tying them to Paysafe’s GitHub organization. Prefer provenance-attested packages; treat its absence on a payment or security-critical dependency as a review trigger.

5. Isolate CI secrets. The campaign monetized environment variables, so stop leaving them lying around: scope secrets to the specific jobs that need them rather than exporting them pipeline-wide; use OIDC federation for short-lived cloud credentials instead of static AWS_SECRET_ACCESS_KEY values; and run dependency-installation steps in a context with no secrets mounted at all — install scripts do not need your tokens.

6. Egress-filter build infrastructure. CI runners have no business initiating connections to *.ngrok-free.dev, *.ngrok.io, or arbitrary tunneling and paste-site infrastructure. Default-deny egress from build environments, with an allow-list of registries and internal endpoints, turns exfiltration into a blocked, logged, alertable event.

7. Harden developer workstations. Developers install packages outside CI constantly. Disable or sandbox lifecycle scripts where feasible (npm config set ignore-scripts true plus explicit opt-in), run installs in containers or VMs for unvetted code, and deploy EDR rules for the known patterns — child processes of npm/pip making outbound connections during install is a high-signal detection.

8. Defensively register your brand. If your company’s name implies an SDK, register the plausible package names on npm, PyPI, and other ecosystems before someone else does — even as empty placeholder packages pointing to official channels. Paysafe, Skrill, and Neteller are the case study for what happens when you do not.

Checklist for Engineering and Compliance Leads

Immediately (this campaign):

  • Search all dependency manifests, lockfiles, and SBOMs for the 17 package names above; treat any hit as an incident.
  • If found: rotate every secret from affected machines and pipelines — Paysafe API keys, cloud credentials, GitHub/npm/PyPI tokens, and anything matching the KEY/SECRET/TOKEN/PASS/AUTH/API pattern — and audit for malicious use, including unauthorized package publications under your accounts.
  • Review CI and proxy logs for outbound connections to .ngrok-free.dev domains from build infrastructure.

Structurally (the next campaign):

  • Establish or verify the internal registry proxy and package-intake review gate; block direct registry access from CI.
  • Enforce committed lockfiles and reproducible installs in every pipeline.
  • Generate SBOMs on every build and make them queryable across the portfolio within hours, not days.
  • Scope CI secrets per job; migrate static cloud keys to OIDC; strip secrets from dependency-install steps.
  • Default-deny egress from build runners.
  • Map these controls to your obligations: CRA Article 13 due-diligence and Annex I documentation, NIS2 Article 21(2)(d) supply-chain measures, PCI DSS 6.3.2 component inventory, SSDF PW.4 — and, if you sell to US federal agencies, confirm your CISA attestation is still true.
  • Register defensive package names for your own brands, and stand up registry monitoring for impersonations of them.

Conclusion

Nothing about this campaign was sophisticated in the way a zero-day is sophisticated. Seventeen unclaimed brand names, a fake API surface that says success: true, an environment-variable sweep, and a free ngrok tunnel. Socket’s scanner caught it in minutes — this time, on these registries, for these packages. The attacker’s cost to run the identical play next week against a different payment brand, or your brand, is close to zero.

That asymmetry is precisely why regulators have moved. The CRA, NIS2, PCI DSS 4.0, and the US attestation regime all encode the same judgment: an organization that ships software built from unvetted public-registry components, with no inventory, no provenance checks, and secrets sprayed across its build environment, has not been unlucky — it has been negligent in a way that is now legible to auditors and enforceable in fines. The engineering controls are known, mostly boring, and dramatically cheaper than the incident. The organizations that treat the July 7 campaign as a checklist prompt rather than a news item will be the ones that don’t headline the write-up of the next one.

Sources: Socket — Coordinated npm and PyPI Campaign Typosquats Popular Secure Payment Apps, BleepingComputer — Fake Paysafe, Skrill SDKs on NPM and PyPi steal credentials, TechNadu — 17 npm, PyPI Packages Found Typosquatting Payment SDKs, Developer-Tech — Socket: PyPI and npm payment SDK malware compromises CI/CD

This article is provided for informational purposes only and does not constitute legal advice.