event-stream 2018: The npm Package Takeover That Hid Cryptocurrency-Stealing Code
The event-stream incident showed how transferring maintainership of a trusted npm package could let a malicious dependency enter downstream applications and target cryptocurrency wallets.
The attack began with a trusted package whose original maintainer had largely moved on
The npm package event-stream was widely used even though its original author, Dominic Tarr, no longer spent much time maintaining it. In 2018, another person volunteered to help and eventually received publishing access. That handoff seemed like ordinary open-source stewardship. It became the key trust transition in a supply-chain attack. npm’s investigation later found that the new maintainer introduced a dependency named flatmap-stream into event-stream@3.3.6.[1] The malicious behavior arrived not by compromising npm’s registry infrastructure but by obtaining legitimate authority over a respected package.
Maintainer succession is a security event
Open-source projects need new maintainers, but transferring publish rights changes who can inject code into every downstream build. That transition deserves identity verification, limited permissions, review, and ideally more than one trusted person.
The malicious payload was hidden in a dependency rather than in the visible package
The dangerous code lived in flatmap-stream@0.1.1, a dependency added by the new maintainer. npm reported that the payload was designed to activate specifically in Copay cryptocurrency-wallet environments, inspect Bitcoin and Bitcoin Cash balances, harvest account information and private keys under targeted conditions, and send the stolen data to an external server.[1] This targeting helped the malware remain less obvious to ordinary users of event-stream. The package could behave normally in most applications while carrying a payload intended for one valuable downstream consumer.
Transitive dependencies create camouflage
Reviewers may inspect the package they intentionally installed while missing code pulled in several levels deeper. Attackers can exploit that attention gap by placing malicious logic in a new dependency, optional component, build step, or generated artifact.
GitHub issues reconstructed how trust changed hands
The event-stream repository’s issue history records the maintainer discussion and later community investigation after suspicious code was discovered.[2] A separate issue tracked the security implications and the need to warn downstream users.[3] These records matter because the compromise was partly social: an abandoned-maintenance problem created an opening for someone willing to do useful-looking work. Supply-chain defense therefore cannot focus only on code scanners. It must also account for project health, maintainer turnover, and unexplained changes to publishing authority.
Burnout can become a supply-chain risk
Popular packages often outlive the enthusiasm or availability of their original authors. Ecosystems need sustainable ways to transfer responsibility without forcing one exhausted maintainer to choose between abandonment and quickly trusting a stranger.
Snyk’s postmortem highlighted the long exposure created by package popularity
Snyk documented the attack timeline, the maintainer transition, and the enormous download volume around event-stream during the period.[4] High download counts create leverage: a malicious change deep in a common dependency can reach many environments before anyone notices. Yet popularity can also increase scrutiny once anomalies are reported. The security challenge is reducing the time between a risky change and ecosystem-wide detection.
Package telemetry can act as an early-warning system
Registries and consumers can flag unusual maintainer changes, new install scripts, obfuscated code, sudden dependency additions, or releases that differ sharply from historical behavior. None proves malicious intent, but each can trigger stronger review.
GitHub’s advisory formalized the affected and remediated versions
The GitHub Advisory Database identifies event-stream@3.3.6 as affected by the malicious dependency and points users to a safe later release.[5] Advisories turn an incident into machine-readable dependency intelligence that scanners and automated update systems can act on. That response is crucial because most developers cannot manually inspect every transitive package in every project. The ecosystem needs shared vulnerability metadata that maps a discovered supply-chain compromise back to exact package versions.
The attack showed why code signing alone is not sufficient when the signer is compromised
A signed package proves who published it, not that the publisher still represents the original project’s intent. In event-stream, malicious code arrived through legitimate package-maintainer authority. Stronger signing would have authenticated the compromised trust relationship perfectly. Supply-chain security therefore requires provenance plus governance: who is authorized, how that authority changed, what review occurred, and whether the built artifact corresponds to reviewed source.
Dependency minimization and pinning reduce exposure but do not eliminate it
Lockfiles can prevent an unexpected version from appearing during one build, and reducing dependency count can shrink the attack surface. But neither strategy fully solves maintainer compromise. A team eventually updates, new lockfiles are generated, and compromised packages may look legitimate. Mature defenses combine version pinning, integrity hashes, update review, sandboxed build steps, secret minimization, and monitoring for advisories. The objective is to make one malicious maintainer less able to convert publishing rights into valuable secrets.
Why event-stream belongs in software-failure history
event-stream belongs in software history because it exposed a nontechnical dependency hidden inside package managers: trust in maintainers. The registry functioned, signatures and versions behaved normally, and the malicious dependency was intentionally published through legitimate credentials. What failed was the social and governance layer around a neglected but widely trusted package. The enduring lesson is that software supply chains are people chains too. Organizations need visibility into who can publish dependencies, how that authority changes, and how quickly suspicious releases can be detected and removed.
Works Cited
- 01npm — Details About the event-stream Incident blog.npmjs.org
- 02GitHub — event-stream Issue #116 github.com
- 03GitHub — event-stream Issue #115 github.com
- 04
- 05
CodeHistory is a living archive. Citations document the evidence used for this edition; later evidence may refine the account.