npm package import execution exposes a crypto SDK supply chain gap

At a glance

What this is: A compromised npm release for the Velora DEX SDK executed when imported, showing that malicious package code can bypass install-hook assumptions.

Why it matters: It matters to IAM and NHI practitioners because developer workstations, CI jobs, and build runners often hold secrets, tokens, and privileged access that an imported package can reach.

By the numbers:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.

👉 Read Corgea's analysis of the @velora-dex/sdk npm supply chain compromise

Context

A supply chain compromise in a package registry is dangerous when execution happens at import time rather than at install time. In this case, the malicious code lived in the published npm artifact, which means the normal assumption that skipping lifecycle scripts reduces risk is incomplete for developers working with npm-based dependencies and crypto application workflows.

The identity angle is real because build systems, developer laptops, and CI runners often carry SSH keys, cloud credentials, publishing tokens, and other secrets that are useful to both attackers and downstream intrusion campaigns. For IAM and NHI teams, this is a governance problem about where machine credentials live, how far imported code can reach, and how quickly exposure is detected after a compromised package is loaded.

Key questions

Q: What breaks when malicious npm packages execute on import instead of install?

A: Install-time controls often miss import-time payloads because the malicious code lives in the published bundle and runs when the module loads. That means unit tests, bundlers, dev servers, and CI jobs can all trigger execution before a postinstall safeguard ever matters. Teams need artifact validation and runtime detection, not only script blocking.

Q: Why do compromised npm packages create supply chain risk beyond developer machines?

A: Because modern pipelines execute dependencies in build runners, test environments, containers, and production services. Once a malicious package is trusted by the installer, it can influence code paths and secrets-bearing workflows far beyond the original repository. That is why exposure must be checked in source, in artifacts, and in runtime.

Q: How do security teams know whether a package trust issue has become an identity incident?

A: It becomes an identity incident when the affected host or pipeline can reach reusable credentials, publishing tokens, or privileged service accounts. Evidence includes imported package execution, persistence on the host, and any account or token used from the same environment. That is a governance boundary breach, not only malware.

Q: Who should own response when a build tool compromise exposes credentials?

A: Ownership should sit with IAM, platform engineering, and security operations together, because the issue spans identity, build infrastructure, and downstream cloud access. The right response is cross-functional containment, not a tooling-only patch.

Technical breakdown

Import-time execution in npm packages

Most teams think of package risk as a preinstall or postinstall problem, but JavaScript modules can execute as soon as application code imports them. In this case, the malicious payload was placed in the package entrypoint, so a test run, local server, build step, or REPL could trigger it long after installation. That shifts the control question from install-time filtering to runtime trust in the artifact itself, including the published tarball, the lockfile, and the import path.

Practical implication: inspect imported dependency artifacts, not only lifecycle scripts, when building supply chain controls.

Registry artifact compromise versus source repository integrity

A registry-artifact attack means the public source repository can look clean while the package downloaded from npm contains malicious changes. That happens when the published tarball diverges from repository contents, often through compromised publishing credentials or tampered build outputs. For defenders, this is a provenance failure: source review alone does not prove what the runtime environment will execute, especially when dist files are prebuilt and distributed separately.

Practical implication: compare source, build output, and registry tarballs as separate trust checkpoints.

macOS persistence through LaunchAgents and launchctl

The observed payload used a second-stage backdoor on macOS and established persistence with LaunchAgents and launchctl. That pattern matters because endpoint compromise on a developer system is rarely just a malware issue. It becomes an identity issue when the host already contains credentials that can be used to pivot into GitHub, cloud consoles, package registries, or deployment pipelines. Persistence keeps that access alive beyond the initial execution window.

Practical implication: triage compromised developer Macs as identity-risk assets, not only as endpoint incidents.

Threat narrative

Attacker objective: The attacker aimed to gain persistent foothold on developer machines and harvest credentials that could be reused across software supply chain and crypto infrastructure.

1. Entry occurred when developers or build systems imported the compromised npm package, allowing the malicious entrypoint in dist/index.js to execute.
2. Credential access and execution followed when the package decoded a shell command and fetched a second-stage payload that could reach local secrets and environment variables.
3. Escalation and persistence were established on macOS through a backdoor that used LaunchAgents and launchctl to remain active across sessions.
4. Impact included exposure of developer credentials, CI/CD secrets, and downstream access paths into crypto application and publishing workflows.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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

NHI Mgmt Group analysis

Import-time execution is a distinct supply chain failure mode: lifecycle-script blocking is not sufficient when malicious code sits in the module entrypoint. That changes the defensive baseline for npm consumers, especially teams that assume install-time scanning captures the full risk surface. The practical conclusion is that package governance must cover runtime import behaviour, not only installation events.

Developer endpoints are identity-bearing systems, not just build tools: this attack pattern matters because the host often contains the most valuable machine credentials in the environment. SSH keys, cloud tokens, registry credentials, and CI secrets turn a single imported package into an access bridge. For IAM and PAM teams, developer device hardening is part of identity governance, not a separate endpoint problem.

Registry artifact integrity is the real trust boundary: the source repository can be clean while the distributed tarball is weaponised. That means software supply chain assurance depends on provenance checks, artifact comparison, and build attestation, not just code review. Artifact trust gap: the control failure is assuming source and runtime package contents are equivalent. Practitioners should treat published artifacts as first-class security objects.

Secrets exposure on developer Macs needs faster containment: once the package executed, the attacker’s likely objective was access to reusable credentials, not just local code execution. This is why the response window is short and why secrets rotation must be tied to host compromise, not only confirmed exfiltration. In practice, this aligns with OWASP Non-Human Identity Top 10 guidance on secret sprawl and lifecycle control, and with NIST SP 800-53 Rev 5 controls for access and integrity management.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• 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.
• Forward pivot: Review 52 NHI Breaches Analysis for the recurring credential exposure patterns that turn package compromise into access compromise.

What this signals

Artifact trust gaps are becoming a governance issue, not a niche build risk: teams that only validate package installation paths will miss import-time execution, which is the part attackers increasingly exploit. NIST SP 800-53 Rev 5 reinforces the need for integrity and access controls across the software pipeline, while OWASP Non-Human Identity Top 10 is useful for framing the secret-bearing hosts and service accounts involved.

The programme signal is straightforward: dependency scanning, secret scanning, and endpoint response now need a shared escalation path. If a developer machine imports a malicious package, the incident can move from application security into IAM and PAM within minutes. The control objective is to reduce the time between compromise and secret rotation, not to wait for perfect attribution.

Runtime package governance: the practical lesson is to treat published artifacts as active execution assets. That means provenance checks, clean rebuilds, and host-level containment should sit alongside dependency approval, especially where CI runners and developer Macs can reach production credentials.

For practitioners

• Audit import-reachable dependencies Scan manifests, lockfiles, and application entrypoints for packages that execute at import time, then prioritise any dependency with prebuilt dist files or unusual post-install behaviour. Review test, SSR, and REPL code paths as active execution surfaces.
• Compare source, tarball, and build output Verify that the published registry artifact matches the repository and the expected build output before approving a package for production use. Record the hash of the exact tarball consumed by CI and developer tooling.
• Treat developer macOS systems as credential endpoints After confirmed import-time compromise, image the host as a credential-bearing system, remove LaunchAgents persistence, and rotate GitHub, npm, cloud, and SSH credentials from a known-clean device.
• Tie secret rotation to host compromise events Do not wait for proof of exfiltration before rotating secrets that were reachable from the affected workstation or build runner. Use a predefined rotation list for tokens, deploy keys, and publishing credentials associated with the host.

Key takeaways

• The compromise mattered because the malicious npm package executed on import, which bypassed the common assumption that blocking lifecycle scripts is enough.
• The evidence points to a classic developer-credential exposure problem, where a single import can reach SSH keys, cloud tokens, and CI secrets.
• The limiting controls are artifact provenance, host containment, and rapid secret rotation tied to the affected workstation or pipeline.

Key terms

• Import-time execution: Import-time execution is code that runs when a Python module is loaded rather than when a user deliberately calls a function. That behaviour matters in security reviews because it can trigger secret access, network calls, or persistence before an application has meaningfully started operating.
• Registry-Artifact Attack: A supply chain compromise where the published package or tarball differs from the source repository or expected build output. The attacker targets the artifact that developers actually consume, which makes repository review alone an incomplete trust control.
• LaunchAgent: A LaunchAgent is a macOS persistence mechanism that starts user-level processes automatically. Attackers abuse it to relaunch malware after reboot or login, which makes a one-time infection survive long enough to steal data, fetch later stages, or maintain command access.
• Action Provenance: Action provenance is the record of who initiated a task, which identity executed it, what tool was used, and what decision was made at runtime. It is essential when delegated work crosses systems because it preserves accountability even when the original request and the final action are separated by many steps.

What's in the full analysis

Corgea's full report covers the operational detail this post intentionally leaves for the source:

• Exact package diff and package.json changes that distinguish the malicious tarball from the clean repository
• Command-and-control and persistence indicators that help responders validate host compromise on macOS
• Step-by-step detection queries for npm lockfiles, caches, and LaunchAgent artifacts
• Remediation sequencing for rotating tokens, SSH keys, and publishing credentials after compromise

👉 The full Corgea post covers the attack chain, macOS persistence indicators, and remediation steps in detail.

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 for practitioners who need stronger lifecycle control. It helps security teams connect identity governance to the operational realities of service accounts, tokens, and developer-accessible credentials.