Topic starter
19/08/2026 3:45 pm
TL;DR: A coordinated 17-package typosquat campaign on npm and PyPI impersonated Paysafe, Skrill, and Neteller SDKs to steal environment-stored secrets from developer, CI, and backend systems, according to Corgea's analysis. The pattern shows how convincing integration glue can turn normal application execution into credential exfiltration without relying on install-time hooks.
Editorial analysis by NHI Mgmt Group, based on content published by Corgea: “Paysafe, Skrill, and Neteller typosquats on npm and PyPI stole developer secrets”.
By the numbers:
- 13 npm package names were published in malicious 1.0.0 through 1.0.3 waves on 7 July 2026.
- 4 PyPI package names were published as malicious 1.0.0 releases on 7 July 2026.
Key questions
Q: What breaks when a malicious SDK is loaded into a build or runtime environment?
A: The trust boundary moves from installation to execution.
Q: Why do static secrets create so much supply chain risk?
A: Static secrets create risk because they turn a single leak into a long abuse window.
Q: How do security teams detect dependency abuse that waits until runtime?
A: They correlate package use with outbound traffic, secret access, and process lineage rather than relying only on install-time alerts.
Practitioner guidance
- Tighten package admission for payment integrations Allowlist the exact packages and publishers approved for payment-related workflows, then block lookalike names that differ only by product branding or suffixes.
- Reduce process-level secret exposure Remove broad environment injection for API keys, tokens, and cloud credentials wherever possible, and scope secrets to the smallest runtime that actually needs them.
- Hunt for suspicious dependency runtime activity Correlate package imports with outbound connections, especially to non-vendor infrastructure, and flag delayed POST requests after apparently successful SDK calls.
Bottom line: This campaign shows how typosquatted SDKs can convert ordinary application execution into secret theft when runtime environments expose high-value credentials.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
19/08/2026 4:23 pm
Typosquatted integration code is a secrets-governance problem, not just a package-screening problem. The weakness here is not only that a malicious dependency existed, but that application runtime was allowed to see secrets it did not need to hold broadly. When environment variables contain high-value machine credentials, one imported library can become a theft point. Practitioner conclusion: reduce secret exposure before code execution rather than assuming package review will catch every malicious package.
A few things that frame the scale:
- Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
A question worth separating out:
Q: What should teams do immediately after a fake package may have executed?
A: Contain the host, preserve logs, and rotate any secrets that were present in the environment while the package ran. That includes registry tokens, GitHub tokens, cloud keys, and internal service credentials. After containment, rebuild from trusted dependencies and verify the integration source.
👉 Read our full editorial: Typosquatted payment SDKs turn application secrets into supply-chain theft