Typosquatted payment SDKs turn application secrets into supply-chain theft

At a glance

What this is: This is a supply-chain analysis of malicious npm and PyPI packages that masqueraded as payment SDKs while stealing environment-stored secrets at runtime.

Why it matters: It matters because IAM, PAM, and NHI teams need to treat build-time and runtime secrets exposure as a shared control problem, not just an application dependency issue.

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.

👉 Read Corgea's analysis of the Paysafe typosquat supply-chain campaign

Context

Typosquatted packages are effective because developers often trust brand-adjacent names when they are searching for integration libraries, and that trust can be enough to expose environment variables, tokens, and cloud credentials during routine application execution. In this case, the primary issue is not package installation itself but the point at which application code imports and runs the fake SDK, which turns the dependency chain into a secrets-harvesting path for NHI and human-operated environments alike.

The identity security angle is straightforward. Secrets embedded in CI runners, developer workstations, and backend services behave as non-human credentials once they are available to code at runtime, which means dependency trust, secret handling, and privilege scope all intersect. That is why this story belongs in the NHI and IAM conversation, not only the AppSec one.

The starting position is unfortunately typical for modern delivery pipelines: secrets are widely distributed, environment variables are overused, and package provenance checks are often weaker than teams assume.

Key questions

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. The immediate failure is secret overexposure, but the larger issue is that one compromised dependency can turn a normal application or CI job into a credential harvesting point.

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. If malicious package code executes there, it can harvest live credentials and use them for lateral movement or republishing. The issue is concentration of privilege on machines that routinely execute third-party code.

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. If build and import events can still touch high-value secrets, control is not yet working. You should be able to map every sensitive secret to a short-lived, explicitly owned use case.

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.

Technical breakdown

How fake SDKs turn normal runtime calls into secret theft

The malware does not need a visible install hook if the application itself will instantiate the imported package. In both JavaScript and Python variants, the fake SDK presents a plausible client interface, then checks for API keys or environment secrets when a method is called or a module is imported. That means the attacker is exploiting the trust boundary between dependency resolution and runtime execution. The package only has to look legitimate long enough for the application to hand it access to process environment variables, working directory context, and network egress.

Practical implication: teams need to treat dependency execution paths as secret-access paths, not just package trust decisions.

Why environment variables are a high-value theft target

The payload is built around broad environment-variable harvesting because many organisations still inject credentials into CI jobs, containers, and application hosts through process environments. That gives malicious code a single place to look for cloud keys, registry tokens, GitHub tokens, internal API credentials, and payment secrets. This is especially dangerous in build and test systems, where developers expect transient use but attackers see reusable credential density. The result is a high-yield compromise path that crosses human and non-human identity boundaries.

Practical implication: reduce the number of sensitive secrets exposed to process environments and reserve them for tightly controlled, short-lived access paths.

Runtime obfuscation and sandbox evasion reduce static detection value

The samples use simple string decoding, delayed exfiltration, and lightweight sandbox checks to avoid the most basic static and dynamic detections. None of that is advanced tradecraft, but it is enough to blur the signal for teams that rely on package scanning alone. The important architectural point is that detection has to account for execution context, outbound destinations, and secret access behaviour, not only for malicious indicators embedded in package metadata.

Practical implication: combine dependency scanning with runtime network monitoring and secret-use telemetry.

Threat narrative

Attacker objective: The objective is to harvest high-value secrets from trusted application and CI environments and reuse them for downstream compromise, fraud, or lateral access.

1. Entry occurred when attackers published typosquatted npm and PyPI packages that matched real payment integration names closely enough to be trusted during dependency selection.
2. Credential access happened when the fake SDKs read PAYSAFE_API_KEY, cloud credentials, registry tokens, GitHub tokens, and other environment-stored secrets from developer, backend, and CI hosts.
3. Impact followed when stolen secrets were exfiltrated to attacker-controlled infrastructure, creating a supply-chain route from ordinary package installation to account and environment compromise.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• GitHub Dependabot Breach — GitHub Dependabot tokens stolen and abused to push malicious commits to repositories.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Environment-variable secrets create an oversized blast radius when runtime code is untrusted. These samples did not need privileged platform access because CI runners and developer hosts often already contained valuable credentials in process environments. That is a classic non-human identity failure mode: the same secret is available to too many workloads for too long. The practitioner conclusion is to reduce standing exposure and narrow which processes can see which secrets.

Supply-chain security must include identity boundaries for build and test systems. When a fake SDK can reach GitHub tokens, registry tokens, and cloud keys, the real issue is not just malicious code but weak separation between workload identity, human identity, and ephemeral pipeline trust. OWASP-NHI and NIST SP 800-53 both point toward tighter authenticator management and access control. Teams should re-check where runtime credentials live before they re-check package scores.

Runtime egress control is the missing second line of defence for dependency risk. Static vetting may catch obvious typosquats, but it will not stop a package that behaves normally until it sees a key. The better control is to combine provenance checks with outbound destination restrictions, secret-use telemetry, and credential scoping that limits what a compromised package can steal. Practitioners should design for package compromise as an expected condition, not an exception.

Secrets exposure windows are now the decisive metric for this attack class. The short delay between import, method call, and exfiltration matters because it compresses detection opportunities. That shifts the governance question from whether a secret existed to how long it was reachable by code that should never have seen it. Teams should measure reachability, not just storage.

From our research:

• 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.
• From our research: 91% of former employee tokens remain active after offboarding. That persistence window is exactly why exposed secrets need lifecycle control, not ad hoc cleanup.

What this signals

Secrets exposure now has the same governance profile as identity sprawl. Once credentials live in build systems and process environments, they behave like non-human identities with weak lifecycle control. That is why teams should align dependency governance with identity governance, including scoped issuance, rotation, and revocation paths that can be executed quickly when a package is suspect.

A practical shift is emerging: package trust decisions must be paired with secret reachability controls. The right question is no longer only whether a dependency is benign, but whether it can reach credentials that should be invisible to imported code. For practitioners, this means tighter separation between pipeline identity, workload identity, and human access in high-risk delivery paths.

Teams that already use NIST SP 800-53 can map this problem to authenticator management and access control, then extend the same logic into software supply-chain review. The control objective is simple: if a dependency is compromised, the credential blast radius should still remain small enough to contain before exfiltration completes.

For practitioners

• Separate build secrets from runtime secrets Stop injecting broad cloud, registry, and GitHub credentials into every CI job and application host. Use narrowly scoped, short-lived credentials per pipeline stage so a fake dependency cannot harvest everything at once.
• Review package provenance before import Require maintainer verification, package namespace checks, and repository correlation for any new payment-related dependency. Treat brand-adjacent names such as payment SDKs, wallet libraries, and checkout wrappers as high-risk until provenance is confirmed.
• 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. A package that returns normal results but phones home is already a compromise signal.
• Scope and rotate exposed tokens immediately Assume any host that imported the malicious packages may have leaked environment secrets. Rotate registry tokens, GitHub tokens, cloud keys, and internal API credentials, then rebuild from known-good lockfiles and package manifests.

Key takeaways

• This campaign shows that a convincing package name can become a credential theft path when runtime code can see environment secrets.
• The scale of the problem is driven by secret exposure and lifecycle weakness, not just by malicious packages.
• Teams should treat package provenance, secret scoping, and outbound egress as one control plane for supply-chain risk.

Key terms

• Typosquat Package: A typosquat package is a malicious or misleading package name designed to resemble a legitimate dependency. Attackers rely on typing mistakes, autocomplete, or familiarity to get developers to install it, then use the trusted package manager path to deliver payloads or steal data.
• Runtime Secret Visibility: Runtime secret visibility is the ability to observe when and where secrets are accessed while systems are actively running. It matters because static inventories alone do not show whether a tool, workflow, or workload is reading credentials in memory, files, or logs.
• Supply Chain Credential Abuse: Supply chain credential abuse occurs when attackers compromise trusted software, dependency, or tooling paths to steal or reuse credentials. The attacker is not only targeting the software artifact but the identity material that the software can reach during normal execution.

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

👉 Corgea's full post covers the package indicators, runtime payload details, and remediation workflow.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and identity lifecycle control. It helps security practitioners connect credential governance to the wider identity programme.