Typosquatted npm packages expose secrets and tokens at scale

At a glance

What this is: This is an Anomali analysis of malicious typosquatted npm packages that install infostealers and collect browser data, SSH keys, OAuth/JWT tokens, and system secrets across Windows, Linux, and macOS.

Why it matters: It matters because package trust has become an access-governance problem as well as a software-supply-chain problem, and stolen developer secrets can become the first credential in a broader compromise.

Context

Typosquatted packages exploit a simple trust gap: developers assume a package name in a registry is legitimate if it looks familiar. In practice, that assumption fails when attackers register lookalike modules and use post-install scripts to run code on the developer endpoint before any code review or runtime control can intervene.

The identity angle is material here because the payload is not just malware delivery, it is credential and token theft. Browser-stored credentials, SSH keys, OAuth and JWT tokens, and system keyrings all represent non-human or user-bound secrets that can be reused for access long after the initial package install has been forgotten.

Key questions

Q: What breaks when a typosquatted package can run install-time scripts?

A: The trust boundary breaks at the point of installation, because the package manager can execute attacker code before code review, sandboxing, or runtime monitoring sees the payload. That turns dependency resolution into a code-execution event, so package provenance, allowlisting, and lifecycle-script controls become part of the defensive model, not just developer convenience.

Q: Why do stolen developer tokens and SSH keys create so much downstream risk?

A: Because they often represent already-authenticated access that can be replayed from outside the endpoint, bypassing the original workstation compromise. A stolen token may unlock source control, cloud consoles, or internal services without another login step, which is why revocation speed and token lifetime matter more than endpoint cleanup alone.

Q: What are the signs that npm-based secret theft is in progress?

A: Look for package installs that spawn unexpected child processes, post-install script activity, unusual access to browser stores or keyrings, and outbound transfers after a dependency event. On the identity side, watch for token use from new hosts, impossible travel patterns, or repository access that does not match the developer's normal workflow.

Q: How should teams govern developer secrets when software installs can steal them?

A: Treat developer endpoints as part of the access-control plane. Limit where credentials can be stored, shorten token lifetime, scope keys narrowly, and require rapid revocation when a workstation or package trust event is suspicious. That approach reduces the value of any one stolen secret and limits the blast radius of supply-chain abuse.

Technical breakdown

How typosquatted npm packages turn install time into execution time

Typosquatting works because package managers trust names, maintainers, and dependency metadata more than the human eye does. When a developer mistypes a popular module name, the install process can trigger post-install hooks, which means attacker code runs automatically during dependency resolution. Obfuscation, staged payloads, and packed binaries are then used to delay detection until after the host has already executed the malicious loader. In this model, the registry becomes an access vector, not just a distribution channel.

Practical implication: treat package installation as code execution and constrain it with provenance, allowlisting, and script restrictions.

Why browser stores and keyrings are high-value targets

The payloads described here target browser credential stores, SSH keys, OAuth and JWT tokens, and operating-system keyrings because those assets often unlock downstream services without needing a password prompt. Browser-stored tokens may already represent authenticated sessions, while SSH keys and cloud tokens can provide direct access to repositories, build systems, and infrastructure. Once harvested, these secrets persist beyond the infected endpoint and can be replayed from attacker infrastructure, which makes detection on the original machine only part of the problem.

Practical implication: inventory where secrets are stored on endpoints and shorten the lifetime of credentials that can be reused outside the device.

Why staged exfiltration makes this kind of compromise harder to spot

The article describes data being collected locally, staged in temporary directories, compressed, and then exfiltrated over attacker infrastructure. That sequence matters because it reduces obvious indicators like a single large theft event and allows the malware to blend into normal developer activity. In supply-chain abuse, defenders often see only the endpoint symptoms, while the real impact is distributed across the accounts and services those secrets unlock. This is why endpoint telemetry and identity telemetry need to be analysed together.

Practical implication: correlate endpoint collection events with unusual token use, login anomalies, and repository access from new locations.

Threat narrative

Attacker objective: The attacker wants reusable secrets and tokens that can be turned into broader access to developer, source-control, and cloud environments.

1. Entry occurs when a developer installs a typosquatted npm package that masquerades as a legitimate module.
2. Credential_harvested follows as the package's post-install logic loads an infostealer that collects browser data, SSH keys, OAuth and JWT tokens, and system keyring secrets.
3. Data_exfiltration happens after the malware stages the harvested material in temporary directories, compresses it, and sends it to attacker infrastructure.
4. Impact is downstream account and environment compromise because stolen secrets can be replayed to access repositories, developer tools, cloud services, and other connected systems.

Breaches seen in the wild

• Shai Hulud npm malware campaign: Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Miasma and Hades Supply Chain Worms: Self-propagating supply chain worms Miasma and Hades compromise npm, PyPI, and Azure credential stores.

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

Secret theft is now part of software-supply-chain risk, not a separate identity problem. The malicious package is only the entry point; the real target is the credential estate sitting on developer endpoints. Browser stores, keyrings, SSH keys, and OAuth tokens behave like machine-bound access material even when they are created for humans, so supply-chain abuse and identity governance now intersect directly. Practitioners should treat dependency trust as a secrets exposure problem as well as a build-integrity problem.

Typosquatting works because package installation still receives too much implicit trust. The attack does not need a novel exploit when the install path itself can execute code through post-install scripts. That means package naming controls, provenance checks, and developer workflow restrictions are not optional hardening, they are part of access control for the software factory. Practitioners should narrow what can execute during install and detect abnormal package behaviour early.

Endpoint secret stores create a long tail of compromise beyond the infected workstation. Once tokens and keys leave the device, revocation becomes the real security boundary. The named failure mode here is secret reuse without device-bound control, which turns a single install event into multiple downstream authorisation failures. Practitioners should assume any stolen developer secret can outlive the endpoint compromise unless it is short-lived or tightly scoped.

Developers are now a governance surface, not just a user population. The article shows that the developer workstation can expose production-relevant identities, credentials, and sessions through routine software installation. That changes the programme question from malware cleanup to lifecycle control over software access, secrets storage, and token revocation. Practitioners should align supply-chain monitoring with identity governance processes, not treat them as separate workstreams.

What this signals

Package trust now reaches into identity governance. Typosquatted modules are not only a software integrity issue; they are a route to browser sessions, SSH material, and OAuth tokens that outlive the compromised install. The programme response has to combine dependency controls with secrets lifecycle controls, because revoking the package is not the same thing as revoking the access it steals.

Secret stores on developer endpoints are a governance liability when token reuse is easy. If a stolen token can be replayed from elsewhere, the environment has effectively allowed endpoint compromise to become account compromise. Practitioners should narrow token scope, reduce storage of reusable secrets, and align revocation triggers with software-supply-chain alerts.

For practitioners

• Restrict install-time script execution Block or heavily constrain npm lifecycle scripts for untrusted packages, and require review for any package that needs post-install execution.
• Allowlist trusted package sources Use private registries, package provenance checks, and name validation so lookalike modules cannot be installed by accident or through automation.
• Move developer secrets out of endpoint stores Reduce reliance on browser-stored credentials, local keyrings, and long-lived tokens by using short-lived credentials and tighter scoping where possible.
• Correlate endpoint and identity telemetry Investigate unusual token use, repository access, and cloud logins that appear after package installation on a developer system.

Key takeaways

• Typosquatted npm packages exploit trust in the install path to turn routine dependency activity into code execution and secret theft.
• The stolen material is operationally dangerous because browser sessions, SSH keys, and OAuth tokens can be replayed long after the endpoint infection is noticed.
• Reducing the blast radius requires both package provenance controls and secrets lifecycle controls, especially for developer workstations.

Key terms

• Typosquatting: Typosquatting is the practice of naming a malicious package so it looks like a legitimate dependency with a small spelling change. In software supply chains, the goal is to get developers or automation to install attacker code before provenance or behaviour checks catch the deception.
• Install-Time Execution: Install-time execution is code that runs while dependencies are being installed rather than when an application is launched. In supply chain attacks, this matters because the install phase often has access to the richest secrets in developer and CI environments, making it a high-value privilege boundary.
• Secrets Store: A secrets store is a controlled system used to hold sensitive values such as passwords, tokens, or keys for later retrieval by authorised workloads. It centralises secret handling, but its security depends on access control, encryption, and careful integration with the platform that consumes the secret.
• Token Reuse: Token reuse occurs when the same credential is used across multiple applications, pipelines, or environments. This pattern increases the impact of any single leak because compromise in one place can open access elsewhere. It is a common sign that identity boundaries are too loose for modern automation.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity in a way that helps security teams connect access control to real-world attack paths. It is built for practitioners who need to govern credentials, tokens, and service access across modern environments.