npm Payment SDK Malware Hits zahlen, voxepay, simplipayng

On August 6, 2026, a cluster of npm packages posing as payment and checkout SDKs was flagged as critical malware. The group includes simplipayng, @simplipayng/checkout, @zahlen/checkout, @zahlen/checkout-angular, and @voxepay/checkout, all published under vendor-style scopes that read like real fintech tooling. A parallel set flagged at the same time reuses the trick with generic common modules under ticketing, hotel, and rental scopes. Fake payment SDK packages matter more than most npm malware because they aim straight at the developers who handle money, secrets, and production credentials. If one of these reached a build, treat it as a credential exposure, not just a broken dependency.

What happened

Our catalog and npm security feeds marked several npm packages as critical malware on 2026-08-06. The clearest theme is payments. The flagged names include simplipayng, @simplipayng/checkout, @zahlen/checkout, @zahlen/checkout-angular, and @voxepay/checkout. "zahlen" is German for "to pay," and both "voxepay" and "simplipayng" carry the same payment cue in their names.

A second group flagged on the same day uses the same shape with different cover stories: @nasdtickets/common, @afasinatickets/common, @hoteldev/common, @rentwise/common, @nasddatax/common, and @vboxdev/common. The pattern is consistent across both groups. Each name pairs a vendor-looking scope with a generic building block (checkout or common), which is exactly what a private, internal package tends to look like.

Exact version numbers, file hashes, and exfiltration endpoints for these specific packages are limited as of writing. We are not going to invent them. The detection and cleanup steps below work regardless of the exact payload.

The fake payment SDK pattern

This wave lines up with a technique that was documented in detail a month earlier. In July 2026, Socket's Threat Research Team reported a coordinated npm and PyPI campaign that typosquatted well known payment SDKs, including Paysafe, Skrill, and Neteller. BleepingComputer reported that those packages presented themselves as legitimate payment SDKs while quietly stealing credentials. Coverage from developer-tech and gbhackers described payloads built to exfiltrate CI/CD secrets from developer environments, and TechNadu counted roughly 17 packages across npm and PyPI in that wave.

The August 6 packages follow the same script. The names sound like fintech vendors. The modules are named checkout and common, which imitates a payment provider's private SDK or an internal shared library. We have not confirmed the same operator is behind both waves, but the method is the one Socket described.

How the payment SDK malware works

Malicious npm packages that target developers usually fire on one of two triggers. The first is an install lifecycle script (preinstall, install, or postinstall) that runs during npm install. The second is code that executes the moment your application imports the module. A facade package leans on the second trigger and often re-exports or stubs the real SDK's functions, so the build still compiles and tests still pass. That delay is the point. It buys the attacker time before anyone notices.

Once the payload runs, it reads what it can reach. Common targets are environment variables and dotfiles: NPM_TOKEN, GITHUB_TOKEN, cloud keys such as AWS_ACCESS_KEY_ID, payment provider API keys, .npmrc, and .env. In a CI job those values sit in the environment by default, so a single install on a build runner can hand over the keys to publish packages, push to source control, and reach cloud accounts. That is why the payment angle is not a coincidence. Payment and checkout code paths live next to the most valuable secrets a company holds.

There is one bit of good news on the install-script front. Recent npm releases block lifecycle install scripts by default, which closes the postinstall path for many teams. It does not close the import-time path. Code that runs when a module is required still runs, so a facade package can steal secrets the first time your app or test suite loads it.

Who is affected

Three groups carry the most risk. First, teams integrating payments who copy an install command from a search result, a forum answer, or an AI assistant without checking the exact package name and publisher. A scope like @zahlen or @voxepay looks plausible next to real vendor scopes. Second, organizations whose private package scopes resemble any of the flagged names. If you publish internal packages under a scope such as @rentwise or @hoteldev, a public package with the same scope and a common module is a dependency confusion risk worth checking. Third, any CI/CD pipeline that installs dependencies with secrets present in the environment.

How to check if you are affected

Start with your lockfiles and installed tree. Lockfiles are the source of truth because they record exactly what was resolved, including transitive dependencies.

# Search lockfiles and manifests for the flagged names
grep -REn "simplipayng|@zahlen/|@voxepay/|@nasdtickets/|@afasinatickets/|@hoteldev/|@rentwise/|@nasddatax/|@vboxdev/" \
  package.json package-lock.json npm-shrinkwrap.json yarn.lock pnpm-lock.yaml 2>/dev/null

# Confirm whether any resolved in the installed tree
npm ls simplipayng @simplipayng/checkout @zahlen/checkout @zahlen/checkout-angular @voxepay/checkout 2>/dev/null

If you run CI, grep the build logs for the same names and for install-time network calls. A package that phones home during npm install or first import is the signal you care about.

# Look for suspicious outbound calls in build logs
grep -REn "curl|wget|https?://|child_process|exec\(" ci-logs/ 2>/dev/null

Remediation

If any flagged package appears, treat the host or runner that installed it as compromised and move fast on secrets.

# 1. Remove the malicious packages
npm uninstall @zahlen/checkout @zahlen/checkout-angular @voxepay/checkout @simplipayng/checkout simplipayng

# 2. Wipe the installed tree and reinstall from a trusted lockfile
rm -rf node_modules
npm cache clean --force
npm ci

Then rotate every secret that was reachable from the environment where the install ran. That means npm tokens, GitHub or GitLab tokens, cloud keys, and any payment provider API keys.

# Rotate npm tokens
npm token list
npm token revoke <tokenId>

Regenerate cloud and payment keys in their respective consoles, invalidate CI secrets, and check for unexpected new npm package versions or Git pushes made with the stolen tokens. Add the flagged names to a blocklist or your registry policy so they cannot be reinstalled by accident. If you maintain private scopes that collide with the flagged ones, publish placeholder packages or set scope-level access controls so public look-alikes cannot win resolution.

FAQ

Are simplipayng, zahlen, and voxepay npm packages safe to use?

No. As of August 6, 2026, simplipayng, @simplipayng/checkout, @zahlen/checkout, @zahlen/checkout-angular, and @voxepay/checkout are flagged as critical malware. They are not maintained payment SDKs. If you need a payment integration, install the SDK named in your provider's official documentation and verify the publisher on npm before running npm install.

How do I know if I installed a fake payment SDK?

Search your lockfiles and node_modules for the exact names, not just the scope. The grep and npm ls commands above will tell you if a flagged package resolved anywhere in your tree, including as a transitive dependency. Check CI logs too, because a build runner can install and execute a package without it ever showing up on a developer laptop.

What is a payment SDK facade?

A facade package copies the public shape of a real SDK (its exports and function names) so your code compiles and runs while malicious code executes in the background. Because the build succeeds and tests pass, the package looks legitimate. Socket described this facade behavior in the July 2026 payment SDK campaign, where packages impersonated providers such as Paysafe, Skrill, and Neteller.

What should I rotate after installing a malicious npm package?

Rotate anything the install environment could read. At minimum that is npm tokens, source control tokens (GitHub or GitLab), cloud provider keys, and payment provider API keys. Rotate secrets stored in the CI environment as well, then review recent npm publishes and Git activity for actions taken with the old credentials.