Typosquatted npm packages expose secrets and tokens at scale

At a glance

What this is: Anomali highlights malicious npm packages that impersonate legitimate modules and install infostealers on developer systems.

Why it matters: This matters because developer environments often hold the secrets and tokens that govern production access, so package trust failures can become identity compromise and lateral movement risk.

By the numbers:

• 27 days
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.

👉 Read Anomali's coverage of typosquatted npm packages and infostealer delivery

Context

Typosquatted packages are a supply-chain control failure that turns routine developer behaviour into a credential collection event. The primary security issue is not package installation itself, but the trust boundary around post-install execution, provenance, and the secrets stored in developer tools. In environments where OAuth tokens, SSH keys, browser sessions, and keyring entries are present, a single mistaken install can become an identity security incident.

This is also an NHI problem because developer workstations increasingly hold non-human identities in the form of API tokens, automation credentials, and cloud keys. When malware harvests those secrets, the impact reaches far beyond a single endpoint. The typical starting position is still too permissive: organisations trust package names, developers trust registries, and security teams often trust the endpoint until a detection fires.

Key questions

Q: How should teams reduce risk from malicious npm package installs?

A: Treat package installation as a controlled operation, not an implicit trust event. Restrict secret exposure in build environments, separate publish rights from routine development access, and make secret rotation and revocation part of incident response, especially for systems that handle CI/CD credentials.

Q: Why do developer machines create such a large secrets risk?

A: Developer machines often hold the credentials that connect code, CI, cloud, and SaaS systems. If malware steals browser tokens, SSH keys, or API secrets from one endpoint, attackers can reuse them across multiple services. That is why endpoint compromise in development environments frequently becomes identity compromise in production.

Q: What breaks when organisations trust package names too much?

A: Package-name trust breaks because it assumes humans will spot tiny spelling differences and that registries only contain benign software. In practice, attackers exploit speed and familiarity, then execute code during install before review can happen. The control failure is not visibility alone, but admission without verification.

Q: How quickly should teams respond when a secret may have been harvested?

A: Teams should treat suspected secret exposure as an immediate revocation and rotation event, not a ticket for later review. The response should include token revocation, credential replacement, and review of downstream service access. Delay increases the chance that a stolen secret will be reused before detection catches up.

Technical breakdown

Typosquatting as initial access in package ecosystems

Typosquatting works by registering package names that closely resemble trusted modules so developers install them without noticing the difference. The malicious code is usually hidden in install or post-install scripts, which means compromise can happen before the developer opens the package. In modern JavaScript ecosystems, that matters because package managers execute code during install by design. The attack is effective even when the package appears syntactically valid and the registry entry looks ordinary.

Practical implication: restrict installs to approved sources and block or inspect post-install scripts in build environments.

How infostealers turn developer machines into secret harvesters

Once executed, the payload commonly searches for browser-stored credentials, SSH material, cloud tokens, and local keyring data. That turns the workstation into a secret aggregation point, where one malicious dependency can capture multiple identity types at once. The abuse is especially damaging because these secrets often authenticate against SaaS, source control, and cloud control planes. From there, attackers can pivot from a developer laptop into production systems without needing to break encryption or exploit a second vulnerability.

Practical implication: treat developer endpoints as secret-bearing systems and monitor them for credential access and archive creation.

Why provenance and runtime monitoring both matter

Package provenance helps answer whether the dependency is legitimate, while runtime monitoring helps detect what the package actually does after install. Both are needed because a signed or popular package name is not a control. Attackers increasingly combine obfuscation, temporary staging directories, and compressed exfiltration to reduce detection. The control failure is assuming that source reputation alone is enough to prevent secret theft.

Practical implication: pair provenance controls with endpoint and network detections for unusual script execution and outbound transfers.

Threat narrative

Attacker objective: The attacker wants to harvest reusable secrets from developer environments and convert a single package install into broader infrastructure access.

1. Entry occurs when a developer installs a typosquatted npm package that mimics a trusted module name and triggers malicious post-install code.
2. Credential access follows as the malware collects browser secrets, SSH keys, OAuth tokens, and keyring material from the endpoint.
3. Escalation and impact occur when those stolen secrets are reused to access source code, cloud services, or internal systems, expanding the compromise beyond the original workstation.

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

Typosquatted packages are now a secrets governance problem, not just a supply-chain hygiene issue. The attack path ends when developer credentials are harvested, not when the package is installed. That means IAM, PAM, and secrets owners need to treat package trust as part of identity governance, because the real asset under attack is access. The practitioner conclusion is simple: package provenance must be enforced where secrets exist.

Developer endpoints are effectively NHI repositories when they hold tokens, keys, and session material. This is the point where non-human identity governance and endpoint security intersect. If a workstation can access cloud keys, Git credentials, and CI tokens, then endpoint compromise becomes an identity compromise. Organisations should map which NHI secrets can be reached from each developer tier and reduce that reach aggressively.

Package-name trust is a weak control because it assumes human review will catch subtle impersonation. Typosquatting exploits speed, familiarity, and install fatigue. The control gap is not awareness alone but enforcement at the registry, CI, and endpoint layers. The practitioner conclusion is to move from trust-based installation to policy-based dependency admission.

Continuous secret exposure monitoring is now a board-relevant control, not an operational afterthought. Once a stolen token is used, downstream blast radius depends on rotation speed, privilege scope, and revocation coverage. This is where secrets management metrics become risk metrics. The practitioner conclusion is to connect secret detection, rotation, and offboarding into a single response chain.

From our research:

• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs shows why secret rotation, provisioning, and offboarding must be tied together before exposure becomes a breach.

What this signals

Secrets exposure in the software supply chain now behaves like an identity lifecycle failure. When a developer installs a malicious package, the real question is not just whether the dependency is trusted, but whether the secrets it can reach are scoped, monitored, and revocable. That is why organisations should connect developer workstation controls to lifecycle management for cloud keys, tokens, and automation credentials. For governance context, see Ultimate Guide to NHIs , Lifecycle Processes for Managing NHIs.

Blast-radius control matters more than package reputation alone. The same secret can exist in browsers, CI runners, and local keyrings, so one compromise can cascade across multiple systems. The practical signal is whether revocation happens before reuse, not whether a scanner eventually spots the package. That is the operational line between a contained event and a wider identity incident.

Continuous visibility into where secrets live is becoming a prerequisite for resilient development. If teams cannot inventory which developer endpoints can access production-grade credentials, they cannot measure risk accurately. That gap should be treated as a governance issue, not just an engineering task.

For practitioners

• Block untrusted package execution in build pipelines Allow npm installs only from approved registries and disable or inspect post-install scripts in CI, especially where build runners can reach production secrets.
• Inventory secrets reachable from developer endpoints Map browser stores, SSH material, cloud tokens, and keyrings on developer devices, then remove any secret that does not need local presence.
• Add detections for secret-harvesting behaviour Monitor endpoints for unusual archive creation, script execution from temp folders, and outbound transfers shortly after dependency installation.
• Rotate exposed tokens as a single containment step When a malicious package is identified, revoke and rotate OAuth tokens, API keys, and SSH credentials in the same response window rather than one by one.

Key takeaways

• Typosquatted npm packages are dangerous because they target the secrets developers already hold, not just the software they install.
• The evidence problem is lifecycle speed: leaked secrets can persist for weeks, giving attackers time to reuse them across services.
• Teams should focus on package admission, secret reachability, and rapid revocation together, because no single control closes this gap.

Key terms

• Typosquatting: Typosquatting is the practice of registering software package names that look almost identical to legitimate ones so users install the wrong dependency. In security terms, it exploits human pattern-matching and automation in package managers to deliver malicious code through trusted workflows.
• Secrets Sprawl: The uncontrolled proliferation of sensitive credentials — API keys, tokens, passwords, certificates — across codebases, cloud environments, CI/CD pipelines, and configuration files. In 2024, over 50 million leaked secrets were found on the dark web.
• Post-install script abuse: Post-install script abuse happens when malicious code runs automatically during package installation and performs actions before a developer can inspect the package. It is dangerous because the install step itself becomes the execution path, letting attackers harvest data or alter the system immediately.

What's in the full analysis

Anomali's full post covers the incident detail this analysis intentionally leaves for the source:

• The package names and impersonation patterns identified in the typosquatting wave
• The specific payload behaviour that collected browser data, SSH keys, OAuth tokens, and keyring material
• The researchers' technical breakdown of the delivery chain and exfiltration methods
• The source article's broader roundup context, including the other campaigns discussed in the same briefing

👉 Anomali's full post covers the package names, payload behaviour, and roundup context behind the campaign

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It helps practitioners connect identity control to the operational realities of modern access paths.