17 Fake Payment SDKs Landed on npm and PyPI Today, Hunting Your AWS and GitHub Keys. Four Were Already in Our Deny-List. We Added the Other Thirteen.
- Patrick Duggan
- 5 minutes ago
- 3 min read
This morning we published a post arguing that a threat-intel shop should be honest about when it is ahead and when it is not, because a ledger that only ever shows wins is a marketing document. A few hours later the universe handed us a live test, and this is the honest scorecard.
Socket disclosed seventeen malicious packages today, all impersonating legitimate payment SDKs — Paysafe, Skrill, and Neteller — across npm and PyPI. The packages do exactly what that class of attack always does now: they pose as the SDK a developer would reach for and quietly harvest the secrets on the machine that installs them. In this case, Paysafe API keys, AWS keys, GitHub tokens, npm tokens, and host and user metadata. The npm variants were patient — they only fired when a real Paysafe key was already present, which is a targeting choice, not a courtesy. The PyPI variants detonated on import. Credit for the discovery and the teardown is Socket's, cleanly and without an asterisk.
The honest scorecard
When the report crossed our desk we did the obvious thing: checked it against our own package deny-list before assuming anything. Here is what we found, and it is exactly the mixed result the morning's post promised to own.
Four of the seventeen were already blocked. The PyPI packages — paysafe-api, paysafe-kyc, paysafe-payments, and paysafe-sdk — were already in our feed, ingested automatically from the OSV malicious-package catalog as advisories MAL-2026-6926 through 6929, pinned to the exact malicious version. Any customer pulling our package deny-list was already failing a build that reached for those, before this morning's news and before we lifted a finger. That is the automated half of the operation doing its job quietly, which is the only way it is worth doing.
Thirteen were not. The npm side — paysafe-checkout, paysafe-vault, neteller, skrill-payments, paysafe-js, paysafe-api, paysafe-node, paysafe-cards, paysafe-fraud, paysafe-kyc, skrill, skrill-sdk, and paysafe-payments — were fresh. Not in OSV yet, not in our feed. On those, we were not ahead of Socket, and there is no version of the story where we should have been: they did the primary research and published it hours ago. So we did the thing we can actually do fast — we operationalized it. Those thirteen names are now in our package deny-list, confidence 90, sourced and credited to Socket, so that any consumer of the feed now fails a build the moment it tries to install one.
Four already caught by automation, thirteen added on read. That is not "we saw it coming." It is "a quarter of it was handled before we woke up, and the rest was handled within the hour." We will take that, and we will describe it at exactly that size.
Why the deny-list is the whole point
The reason this matters beyond the scorecard is that a package name is the cheapest, most reliable indicator in all of supply-chain security. There is no fuzzy heuristic here, no false-positive risk to manage: skrill-sdk is not a real Skrill SDK, full stop, and a build that installs it should die. That is what a package deny-list is — a list of names your pipeline refuses to pull. It is not glamorous and it does not need to be. It needs to be current, and it needs to be in the build.
This is the same shape we took apart in May, when a fake SICOOB banking SDK was exfiltrating Brazilian banking certificates through what looked like ordinary telemetry. It is the same shape as the Shai-Hulud campaign chewing through developer GitHub accounts, and the same shape that put ten Accenture developers' tokens in an infostealer log. Typosquat a trusted SDK, wait for a developer to install it, walk out with the keys. The payment-SDK flavor is just today's coat of paint on a machine that has been running all year.
If you build anything, the takeaway is boring and it works: block by name, before install. Feed your pipeline a current deny-list and fail the build on a match. We keep ours current so you do not have to chase every advisory yourself — and when we are late, as we were on thirteen of these, we close the gap the hour we see it and tell you plainly that is what happened.
Held to about ninety-five percent confidence, as always. The research is Socket's; our contribution is speed to protection, not discovery. Four of seventeen were already ours through automation, thirteen we added on read, and all seventeen now fail a build. That is the honest whole of it.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Comments