Defending Lodestar Against NPM Supply Chain Attacks

It was a concerning metric to know that when Flashbots publicized data on how node operators' client diversity changed throughout the year, we felt it was important to reiterate the importance of staking on multi-node combination setups or outright primarily running minority clients to protect the delegated Ethereum stake of your clients. It has always been a difficult question to answer for us at Lodestar, but if node operators were, in fact, reconfiguring their node infrastructure to select a new primary consensus client, why were they considering further centralizing their stake in majority clients, putting further undue risk on Ethereum?

In addition, throughout our time meeting with large node operators at Devconnect in 2025, it was noted that Lodestar (a TypeScript consensus client currently transitioning to the Zig programming language) was often misconstrued as being unsafe due to the nature of the ecosystem we currently support on mainnet. We want to reassure those who passively dismiss Lodestar as being an unsafe client to reconsider and allow us to demonstrate why our client's priority on safety surpasses the risk of switching to a majority client.

The JavaScript and TypeScript ecosystem has faced unprecedented supply chain attacks in recent years, raising legitimate concerns about the security of production systems built on NPM dependencies. Lodestar operates critical blockchain infrastructure securing millions of dollars in staked Ethereum today through ChainSafe. This makes the question of supply chain security not just important—it's existential. Yet, despite running on the Node.js runtime and depending on the node package manager ecosystem, Lodestar implements a comprehensive, multi-layered security strategy that makes it remarkably resilient against supply chain attacks.

This blog post explains why Lodestar is safe for node operators to use in production, even in the face of sophisticated NPM supply chain threats. We'll examine real-world attacks that have compromised the ecosystem, detail the specific protections Lodestar employs, and demonstrate how our security-first architecture provides robust defense-in-depth against malicious dependencies.

A History of NPM Supply Chain Attacks

Before diving into Lodestar's defenses, it's crucial to understand the threat landscape. The NPM ecosystem has experienced a dramatic escalation in both the frequency and sophistication of supply chain attacks over the past several years. Most recently, the "Shai-Hulud" Worm and a phishing campaign against the maintainer "qix".

Notable NPM Compromises: Learning from the Past

The event-stream Incident (2018): Perhaps the most infamous NPM supply chain attack began when the maintainer of event-stream, a popular package with 2 million weekly downloads, transferred ownership to a malicious actor who appeared to be a legitimate contributor. Over 2.5 months, this attacker added a dependency called flatmap-stream, containing obfuscated malicious code specifically targeting the Copay Bitcoin wallet. The attack remained undetected for months, resulting in approximately 8 million downloads of the compromised package before discovery.

This incident revealed a critical vulnerability: maintainer fatigue and social engineering could compromise even well-established packages. The malicious code was surgically targeted, demonstrating that attackers invest significant resources in understanding their targets.

ua-parser-js Compromise (October 2021): In October 2021, the widely used ua-parser-js package (7 million weekly downloads) was compromised when attackers hijacked the maintainer's NPM account. Three malicious versions were published, containing cryptocurrency miners and credential-stealing trojans. The attack was live for approximately 4 hours before detection, during which the compromised versions were downloaded thousands of times.

Forensic analysis revealed that threat actors had advertised access to a developer account for an NPM package matching ua-parser-js's profile on Russian hacking forums for $20,000 two weeks before the attack, suggesting a deliberate targeting of high-value packages.

The September 2025 Phishing Attacks: On September 8, 2025, the JavaScript ecosystem experienced one of its most significant supply chain attacks when sophisticated phishing campaigns compromised multiple maintainer accounts. Attackers registered the domain "NPMjs.help" and sent urgent security notifications claiming 2FA updates were required. Josh Junon, maintainer of critical JavaScript infrastructure packages, described receiving what appeared to be legitimate emails during a stressful morning—a perfect example of how social engineering exploits human factors.

The attack compromised at least 18 widely-used packages, including debug, chalk, and ansi-styles, collectively receiving over 2.6 billion weekly downloads. The malicious code was active for only about 2 hours before being removed. Still, it targeted cryptocurrency transactions using sophisticated address replacement algorithms that employed the Levenshtein distance to create similar-looking addresses.

Shai-Hulud: The Self-Replicating Worm (2025): Perhaps most concerning is the Shai-Hulud campaign, which represents an evolution in attack methodology. This self-replicating worm specifically harvests NPM publishing credentials to automatically spread itself to other packages. By targeting the pre-install phase, it executes before static scanning tools can analyze the code, and it requires zero human interaction beyond the initial npm install command.

The Shai-Hulud 2.0 campaign has compromised hundreds of packages, including the widely used @ctrl/tinycolor library, which receives millions of weekly downloads. The automated propagation mechanism means the scope continues to expand, making this an ongoing threat rather than a discrete incident.

Common Attack Patterns and Vulnerabilities

Analysis of these incidents reveals consistent attack vectors that NPM's default behavior enables:

1. Account compromise through phishing or credential theft: Attackers increasingly target maintainer accounts rather than exploiting code vulnerabilities
2. Abuse of postinstall scripts: Historically, over 90% of malicious NPM packages used postinstall or other lifecycle scripts to execute code immediately upon installation
3. Transitive dependencies: Malicious code often enters through dependencies-of-dependencies, which developers rarely audit
4. Speed as an attack enabler: The NPM ecosystem's default "always install latest" behavior means malicious packages propagate to production systems within minutes of publication
5. Detection windows: Most compromised packages are discovered and removed within 1-4 hours, but that's often enough time for widespread installation

Lodestar's Multi-Layered Defense Strategy

Understanding these threats, Lodestar has implemented a comprehensive security architecture that goes far beyond simply hoping our dependencies remain secure. Our approach creates multiple independent layers of defense, ensuring that even if one layer fails, others provide protection.

A TL;DR of some of these mitigations are explained in our new Lodestar Devlog.

Layer 1: pNPM Package Manager—Not Standard NPM

One of the most significant security decisions made recently in Lodestar's architecture is our use of pNPM rather than standard NPM for dependency management. This isn't just a preference—it's a fundamental security choice that provides numerous advantages against supply chain attacks.

Why pNPM Matters for Security: While NPM and yarn have improved their security features over time, pNPM was designed from the ground up with a security-conscious architecture. Its content-addressable storage model and strict dependency resolution provide inherent protections that other package managers lack.

Automatic Postinstall Script Blocking: Since pNPM v10, postinstall scripts are disabled by default in dependencies. This single feature eliminates approximately 90% of historical NPM supply chain attacks, which relied on automatically executing malicious code during installation.

When Lodestar does need to allow build scripts for trusted dependencies, we explicitly whitelist them using the allowBuilds configuration. This means if a previously safe dependency is compromised and suddenly adds a postinstall script, it won't execute, providing immediate protection against precisely the type of attack that compromised ua-parser-js.

Preventing Lockfile URL Injection Attacks: Before using pNPM, Lodestar would use lockfile-lint in our CI build pipeline to detect security issues on our yarn.lock file. Using pNPM architecture now prevents this from happening natively because pNPM does not store the download URL for registry packages in its lockfile by default. With the pnpm-lock.yaml file, there isn't a URL to point it to a malicious source.

Content-Addressable Storage with Integrity Verification: Unlike NPM's traditional node_modules structure, pNPM uses a content-addressable storage system where packages are stored once globally and hard-linked into projects. Each package is verified against SHA-512 integrity hashes in the lock file, making it virtually impossible for attackers to silently replace package contents.

If a malicious actor somehow gained access to a package and modified its contents without changing the version number (a sophisticated attack vector), pNPM's integrity verification would detect the mismatch and refuse installation.

Layer 2: The minimumReleaseAge Protection—A Time-Based Defense

In September 2025, pNPM v10.16 introduced a groundbreaking security feature that directly addresses the speed problem in NPM supply chain attacks: minimumReleaseAge.

This setting defines the minimum number of minutes that must pass after a package version is published before pNPM will install it. The Lodestar team now employs this feature to introduce a deliberate delay between publication and installation.

How minimumReleaseAge Creates a Protective Buffer: Looking at the attack timeline data, we see a clear pattern: the September 2025 attack was live for 2 hours, ua-parser-js for 4 hours, and even the most successful attacks are typically discovered within 24 hours. By setting minimumReleaseAge: 2880 (48 hours), we create a buffer during which:

1. Security researchers and automated scanning tools detect malicious code
2. The NPM security team removes compromised versions
3. The community raises alerts and creates security advisories
4. Lodestar's dependencies remain on known-safe versions

Practical Impact: This simple configuration would have completely prevented Lodestar from being affected by the September 2025 attack (2-hour window), the ua-parser-js compromise (4-hour window), and the majority of other supply chain attacks. As cybersecurity expert Brian Fox noted, even a 24-hour delay "dramatically lowers the chance you'll ever install a compromised package."

Flexibility for Urgent Security Patches: Critics might argue that delaying updates could prevent timely security patches. pNPM addresses this through minimumReleaseAgeExclude, which allows us to whitelist specific packages that should update immediately. For critical security dependencies or our own ChainSafe-maintained packages, we can bypass the delay while maintaining protection for the broader dependency tree. Lodestar currently does not whitelist any specific packages, and we've rarely found the need to urgently update dependencies, thanks to our conservative dependency tree and lock files, as explained below.

Layer 3: Lock Files—Immutable Dependency Resolution

Lock files are often misunderstood or underutilized, but they represent a critical security boundary in dependency management. Lodestar's pnpm-lock.yaml file serves as a cryptographic contract defining exactly which package versions are installed.

How Lock Files Prevent Supply Chain Attacks: When Lodestar's CI/CD pipeline builds the client, it uses pnpm install --frozen-lockfile, which:

1. Installs only the exact versions specified in the lock file
2. Verifies each package against its SHA-512 integrity hash
3. Refuses to proceed if any package hash doesn't match
4. Prevents "unexpected" updates that could introduce malicious code

This means even if an attacker compromises a dependency and publishes a malicious version, Lodestar won't install it unless a developer explicitly updates the lock file—providing a critical checkpoint for human review.

Lock Files as Audit Trails: Beyond security, lock files create a transparent audit trail. Every dependency change generates a diff in version control, allowing reviewers to see exactly what packages changed, when, and in which pull request. This visibility is essential for catching suspicious updates.

Protecting Against Weak Hash Algorithms: Older NPM lock files used SHA-1 hashing, which is vulnerable to collision attacks. pNPM's lock files use SHA-512, a cryptographically strong algorithm that makes it computationally infeasible for attackers to create a malicious package with the same hash as a legitimate one.

Layer 4: Lean Dependency Tree with Conservative Upgrades

One of Lodestar's most important, yet often overlooked, security features is our intentionally minimal dependency footprint and conservative upgrade philosophy.

Principle of Minimal Dependencies: Every dependency is a potential attack vector. Lodestar's monorepo architecture allows us to share code between packages without creating unnecessary external dependencies. By implementing core functionality ourselves rather than pulling in third-party packages, we dramatically reduce our attack surface.

This contrasts sharply with the "NPM install all the things" culture that has led to projects with thousands of transitive dependencies—each one a potential entry point for malicious code.

Conservative Update Strategy: While staying current with security patches is crucial, Lodestar doesn't chase every minor version bump. Our update philosophy prioritizes stability and thorough review:

1. Security updates are applied promptly after verification
2. Minor updates are batched and tested comprehensively
3. Major updates undergo extensive testing and code review
4. Breaking changes are carefully evaluated before adoption

This approach means Lodestar doesn't automatically pull in the "latest and greatest" version of every dependency the moment it's published—providing natural immunity against attacks that target newly-published versions.

Monorepo Advantages for Dependency Management: Lodestar's monorepo structure managed by pNPM workspaces provides additional security benefits:

• Centralized dependency versioning: All packages use the identical versions of shared dependencies, reducing the complexity of security auditing
• Workspace protocol: Internal package dependencies use workspace:*, ensuring they resolve to local versions and preventing dependency confusion attacks
• Single point of dependency review: Changes to dependencies affect the entire project, making them visible and subject to team review

Layer 5: Institutional Security Practices

Beyond tooling, Lodestar benefits from ChainSafe's institutional commitment to security best practices that extend across the entire development lifecycle.

Continuous Integration Security Checks: Every pull request to Lodestar triggers automated security scans:

• Dependency vulnerability scanning detects known CVEs
• License compliance checks ensure no malicious license changes
• Automated testing verifies no regression or unexpected behavior
• Code review by experienced protocol engineers on the team

Production Installation Guidance: Importantly, Lodestar's documentation actively discourages using npm install for production deployments. Instead, we recommend:

1. Docker containers: Pre-built, verified images from Docker Hub
2. Build from source: Clone the repository and build directly
3. Official binaries: Download signed releases from GitHub

This guidance acknowledges that, despite our defensive measures, eliminating all NPM supply chain risk requires controlling the entire build and distribution pipeline.

Two-Factor Authentication and Access Controls: All Lodestar developers with publishing access to NPM packages are required to use two-factor authentication. This directly addresses the attack vector that compromised the September 2025 packages. Additionally, all of our published packages must have reviewer approval, and no developer can accidentally or maliciously push code to main branches.

Trustless Publishing and Provenance: Lodestar packages are now published trustlessly to NPM through OpenID Connect (OIDC), as NPM has forced revocation on its classic long-lived access tokens.

Layer 6: Community-Driven Transparency and Client Diversity

Lodestar's open-source nature and role in Ethereum's client diversity strategy provide unique security advantages that proprietary software cannot match.

Open Source Transparency: Every line of code, every dependency, and every change to Lodestar is publicly visible on GitHub. This radical transparency means:

• Security researchers can audit our dependency choices
• The community can report suspicious changes
• Malicious modifications would be immediately visible
• Trust is built on verifiability, not blind faith

Client Diversity as a Security Feature: Lodestar is one of six production-ready Ethereum consensus clients, and the only one written in TypeScript. This diversity is itself a security feature: if a bug or vulnerability affects one client, the Ethereum network continues operating because validators using other clients remain functional.

The same principle applies to supply chain attacks. If an NPM supply chain attack specifically targeted Rust or Go dependencies (affecting other clients in different languages), Lodestar would be unaffected. Conversely, if a TypeScript-specific attack occurred, the network's other clients provide continuity.

Community Vigilance: The Ethereum community actively monitors client health and security. With node operators running Lodestar in production, from solo stakers to institutional operators, any anomalous behavior or suspected compromise would be quickly detected and reported.

Why TypeScript on Node.js is Actually an Advantage

Some might argue that using TypeScript on Node.js creates inherent supply chain risks compared to compiled languages like Rust or Go. However, this perspective overlooks several key advantages that TypeScript offers for blockchain development.

Type Safety for Critical Infrastructure: TypeScript's static type system catches entire classes of bugs at compile time that would become runtime errors in JavaScript. For blockchain infrastructure handling real financial value, this additional verification layer is crucial.

Smart contracts and consensus clients operate in an environment where bugs can be catastrophic, resulting in the loss of funds, breaking consensus, or enabling exploits. TypeScript's type-checking provides an additional safety net that reduces these risks.

Accessible Security Auditing: TypeScript code is significantly more readable and auditable than compiled languages. Security researchers, external auditors, and community contributors can more easily understand and verify Lodestar's implementation, improving the quality of security reviews.

Ecosystem Maturity: The size of the TypeScript/JavaScript ecosystem means that security tools, scanners, and monitoring solutions are extremely mature. Projects like Snyk, Socket Security, and GitHub's Dependabot provide sophisticated supply chain security specifically for NPM packages.

Developer Accessibility: TypeScript is one of GitHub's most popular languages, making it accessible to a broad developer community. This accessibility means more eyes on the code, more potential contributors for security improvements, and a larger pool of developers who can audit and verify Lodestar's security.

Practical Recommendations for Node Operators

For node operators considering Lodestar, here are practical steps to maximize security:

1. Use Docker, Signed Binaries or Build from Source: For production deployments, use ChainSafe's official Docker images, run GitHub-signed binaries or build Lodestar from source rather than using npm install.
2. Enable Dependency Scanning: Use tools like pnpm audit or GitHub Dependabot to monitor for known vulnerabilities in dependencies.
3. Review Lock File Changes: When updating Lodestar, carefully review changes to pnpm-lock.yaml to understand what dependencies changed.
4. Follow Our Channels: Follow Lodestar's X account and GitHub security advisories for Lodestar.
5. Contribute to Client Diversity: By choosing Lodestar alongside other clients, you strengthen the entire Ethereum network's resilience against client-specific bugs and attacks.

Why TypeScript/Lodestar Isn't Safe is Irrationally Justified

Supply chain security encompasses a spectrum of risk management strategies, rather than being a binary proposition of safe or unsafe. While no system can claim absolute immunity from sophisticated attacks, Lodestar's multi-layered defense architecture demonstrates that a TypeScript/Node.js infrastructure can achieve security postures comparable to or exceeding those of other compiled language alternatives.

By combining pNPM's inherent security advantages with time-based protections through minimumReleaseAge, cryptographic integrity verification via lock files, minimal dependencies, conservative upgrade practices, and the transparency of open-source development, Lodestar has constructed a robust defense-in-depth strategy against NPM supply chain attacks.

The Ethereum network's security, and the billions of dollars it secures, depends on the resilience of its consensus clients. Lodestar's security-focused architecture, institutional practices, and community-driven transparency make it a safe, reliable choice for node operators seeking to participate in Ethereum's consensus while contributing to critical client diversity. If you don't believe us, you can check our statistics on Rated.Network as we continue to stake thousands of Ether as a Lido Node Operator with Lodestar architecture.

The threat of supply chain attacks is real and evolving, but so are our defenses. Through continued vigilance, conservative dependency management, and leveraging the security features of modern tooling, like pNPM, Lodestar demonstrates that a TypeScript consensus client can operate at the highest levels of security, performance and reliability demanded by critical blockchain infrastructure.

About ChainSafe

ChainSafe is a leading blockchain research and development firm specializing in protocol engineering, infrastructure development & operations, co-development and web3-enabled gaming.

Alongside its contributions to major ecosystems such as Ethereum, Polkadot, Filecoin, and more, ChainSafe creates solutions for developers and teams across web3. 

As part of its mission to build accessible and improved tooling for developers, ChainSafe embodies an open source and community-guided ethos to advance the future of the internet.

Website | Youtube | Twitter | Linkedin | GitHub