Typosquatted payment SDKs turn application secrets into supply-chain theft

At a glance

What this is: A coordinated typosquat campaign used fake payment SDKs to steal secrets from application runtimes rather than breaking payment flows.

Why it matters: IAM, AppSec, and platform teams need to treat dependency choice as a secrets exposure decision, because runtime packages can harvest API keys, tokens, and cloud credentials already present in the environment.

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.

Context

Typosquatted SDKs exploit a simple but persistent governance gap: teams trust package names, then allow imported code to run inside environments that already hold valuable secrets. In this case, the masquerade targeted payment integration terminology, which is exactly the sort of branding that developers search for when they are under delivery pressure.

The identity angle is not the package name itself but the credentials the package can reach once loaded. API keys, CI tokens, cloud credentials, and service secrets are often exposed to application code through environment variables, which means a malicious dependency can pivot from software supply chain access to non-human identity theft very quickly.

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. Once a dependency runs inside a secret-bearing process, it can read environment variables, mimic expected API behavior, and exfiltrate credentials before teams notice anything unusual. The control failure is broad secret exposure, not just unsafe packaging.

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. If a credential remains valid for weeks or months, an attacker has time to discover it, reuse it, and pivot into trusted build or release paths before detection or revocation.

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. Delayed exfiltration often looks normal at first, so teams need telemetry that ties a specific dependency to later network calls and credential reads.

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.

Technical breakdown

How typosquatted SDKs turn package trust into secret access

A typosquatted package succeeds when developers treat installation as the trust boundary. The malicious code in this campaign mimicked a legitimate client library, exposed familiar methods, and returned plausible success objects so that application logic would continue to run. That matters because the dependency does not need to break business functionality to steal data. It only needs runtime access to the process environment, where secrets are commonly injected for application, CI, and backend use. Once imported, the package can inspect host details, read secret-bearing variables, and exfiltrate them under the cover of ordinary application execution.

Practical implication: Treat dependency import as a privilege grant and restrict which packages can execute in secret-bearing environments.

Why delayed exfiltration and light obfuscation reduce detection

This campaign used delayed outbound calls and basic string decoding to avoid the most obvious static and behavioral checks. That is not advanced malware, but it is enough to bypass casual review and make sandboxing less reliable if the trigger is a method call or import path that appears harmless. The important control problem is timing. Security teams often look for install-time hooks, yet this sample waited until the application used the library and then sent data later, when the connection to the package looked less suspicious. That shifts detection from package install to runtime telemetry and dependency behavior monitoring.

Practical implication: Correlate dependency use with outbound traffic so a delayed exfiltration step still surfaces as suspicious runtime behavior.

Why application secrets are the real target in supply-chain theft

The package names were narrow, but the credential filter was broad. By searching for key, secret, token, pass, auth, and api patterns, the malware could harvest multiple secret classes from the same environment. That means the attacker was not limited to payment credentials. Any CI secret, registry token, cloud access key, or internal service credential injected into the process was potentially in scope. For governance teams, this is a supply-chain problem and an NHI problem at the same time, because long-lived machine secrets become the easiest thing for imported code to abuse.

Practical implication: Assume any runtime secret exposed to an imported package can be stolen and narrow secret scope before code reaches execution.

Threat narrative

Attacker objective: Steal secrets from environments that already trust the fake SDKs so the attacker can reuse those credentials elsewhere.

1. Entry occurred through published npm and PyPI typosquats that impersonated real payment SDKs and looked plausible to developers scanning for Paysafe, Skrill, or Neteller support.
2. Credential access happened when the malicious packages ran inside developer, CI, or backend processes and read environment-stored keys, tokens, and cloud credentials.
3. Impact was secret exfiltration from trusted application contexts, turning normal integration use into supply-chain theft without breaking the payment workflow.

Breaches seen in the wild

• Hugging Face Spaces breach 2024: Unauthorised access to Hugging Face Spaces may have exposed secrets users stored for AI apps; tokens were revoked and org tokens removed.
• postmark-mcp malicious MCP server 2025: A fake Postmark MCP server on npm quietly BCC'd every email AI agents sent through it to an attacker, using victims' own Postmark tokens.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Runtime trust is the new supply-chain attack surface for application secrets. This campaign did not depend on a noisy install hook or obvious exploit chain. It waited for normal application behavior, which means controls must move from installation-only checks to runtime detection, secret scoping, and dependency allowlisting. Practitioner conclusion: validate what code can read at execution time, not only what it can install.

Secret sprawl creates a direct bridge from software supply chain abuse to NHI compromise. The article describes API keys, cloud credentials, registry tokens, and GitHub tokens living in the same process environment. That is a governance failure because the blast radius of a single dependency now includes multiple non-human identities and access planes. Practitioner conclusion: treat environment-stored secrets as a shared attack surface that needs inventory, least privilege, and rapid revocation.

Package naming confidence is being weaponised as a social-engineering layer for developers. The malicious names were chosen to align with real integration expectations around payment services, which makes the first trust decision happen before any code is inspected. That means security programmes need more than malware detection. Practitioner conclusion: align procurement, developer education, and registry controls around identity of the package publisher, not just the package name.

From our research library:

• Only 44% of organisations are currently using a dedicated secrets management system, according to the 2024 State of Secrets Management Survey.
• Read next: Secrets Management Buyer's Guide

What this signals

Secret sprawl now behaves like a supply-chain accelerant. When application code, CI jobs, and backend services all inherit broad environment secrets, a single malicious dependency can reach far beyond the package manager. Practitioners should treat secret placement as an execution-time control, not a static inventory exercise. according to the 2024 State of Secrets Management Survey

Payment integration naming is a trust exploit in itself. Attackers are borrowing the language of legitimate SDK ecosystems so developers reach for a familiar-looking package before they verify the publisher or provenance. That means package governance must include publisher identity checks, not just vulnerability scanning, especially where secrets are present.

For practitioners

• 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. Review both npm and PyPI dependency sources because the campaign crossed registries.
• 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. The goal is to stop imported code from seeing secrets it should never touch.
• 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. Look for the decoded ngrok-backed host pattern and any unusual traffic from build or developer machines.
• Rotate every exposed machine secret after execution If one of the malicious packages ran on a host, assume the environment was compromised and rotate registry tokens, cloud keys, GitHub tokens, and internal service credentials that were present during execution. Historical logs matter more than the current registry page.

Key takeaways

• This campaign shows how typosquatted SDKs can convert ordinary application execution into secret theft when runtime environments expose high-value credentials.
• The risk is amplified when developer, CI, and backend systems share environment-based secrets, because one malicious import can reach multiple non-human identities at once.
• Teams need to move controls upstream into package allowlisting, secret scoping, and runtime telemetry, because post-install reviews alone will miss delayed exfiltration.

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.
• Secret exposure window: A secret exposure window is the period between when a credential becomes visible to an attacker and when it is detected, revoked, or rotated. In CI/CD environments that window can be extremely short, which is why detection speed and identity-linked revocation matter as much as storage hygiene.
• Offline Exfiltration: Offline exfiltration is data removal that happens outside network monitoring paths, usually through removable media. It reduces visibility because the transfer leaves little or no network trail, forcing detection systems to rely on endpoint, identity, and behavioural evidence instead.
• Machine Credential: A machine credential is a secret or identity artifact used by software rather than a person. It includes service account credentials, API keys, tokens, and certificates. In practice, the main risk is not just exposure, but unmanaged lifecycle, unclear ownership, and overbroad access.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It helps practitioners align identity controls with the environments where secrets are actually consumed.