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.
NHIMG editorial — based on content published by Corgea: the July 2026 typosquatted payment SDK campaign targeting npm and PyPI
By the numbers:
- Only 44% of organisations are currently using a dedicated secrets management system.
- 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
Questions worth separating out
Q: What breaks when a fake SDK can read environment secrets during runtime?
A: The trust model breaks because package approval does not matter if the imported code can still access cloud keys, registry tokens, and GitHub tokens at execution time.
Q: Why do CI runners and developer workstations increase supply-chain identity risk?
A: They often hold the very credentials attackers want: npm tokens, GitHub context, cloud metadata access, Vault secrets, and Kubernetes service account material.
Q: How can organisations know whether package-related secret exposure is actually under control?
A: Look for three signals: fewer long-lived credentials in developer paths, narrower privilege on the secrets that remain, and visible enforcement for package provenance in pipelines.
Practitioner guidance
- Separate build secrets from runtime secrets Stop injecting broad cloud, registry, and GitHub credentials into every CI job and application host.
- Review package provenance before import Require maintainer verification, package namespace checks, and repository correlation for any new payment-related dependency.
- Monitor outbound traffic from dependency execution paths Alert on application or CI hosts reaching unexpected domains, especially ngrok-backed infrastructure or hosts unrelated to the documented vendor API.
What's in the full report
Corgea's full analysis covers the operational detail this post intentionally leaves for the source:
- Package-by-package indicators of compromise for the malicious npm and PyPI releases
- Exact detection queries for lockfiles, dependency trees, and runtime network telemetry
- Sample payload structure and exfiltration indicators for host-level forensics
- Response steps for isolating CI runners, developer workstations, and compromised build chains
👉 Read Corgea's analysis of the Paysafe typosquat supply-chain campaign →
Typosquatted payment SDKs: what practitioners need to do now?
Explore further
Brand-shaped typosquats are now a secrets governance problem, not only a software provenance problem. The malicious packages worked because they matched how developers think about payment integrations, which means package naming itself becomes an attack surface. For IAM and NHI programmes, the control gap is not simply dependency approval but whether runtime code can reach secrets that should never be broadly accessible. Practitioners should treat package trust and secret exposure as one governance domain.
A few things that frame the scale:
- Only 44% of organisations are currently using a dedicated secrets management system. That leaves most environments with inconsistent secret handling across CI, workstations, and runtime services.
- The average time to mitigate a leaked secret is 36 hours, highlighting the operational burden of manual remediation processes.
A question worth separating out:
Q: What should teams do after a malicious dependency is discovered?
A: Contain the affected endpoints, revoke any credentials that were reachable from those systems, and rebuild trust from known-clean environments. Then review where secrets are stored, not just which package was compromised. If the same workstation holds cloud, SSH, and SaaS credentials, the incident response plan must cover all three identity domains.
👉 Read our full editorial: Typosquatted payment SDKs turn application secrets into supply-chain theft