Your organization would have caught the event-stream incident only if someone reviewed new dependencies added to existing packages, looked at who had taken over maintenance, and watched build time behavior. Most teams review their own code carefully and skim lockfile changes. This checklist tests that gap without blaming anyone.
What happened, briefly?
npm's own analysis, published after the event, gives the sequence. On 9 September 2018 a new maintainer released event-stream 3.3.6, which added flatmap-stream as a direct dependency. The attacker had posed as a maintainer to gain control of the package. On 26 November 2018 npm's security team was notified of the malicious package and removed flatmap-stream and event-stream 3.3.6.
The payload was narrow. According to npm, it targeted developers at one company with a very specific development setup, modifying code when a release build script ran for the Copay application. Copay later confirmed the malicious code shipped in versions 5.0.2 through 5.1.0.
Nothing here required an exotic exploit. A trusted package changed hands, a new dependency appeared, and the code ran at build time. About eleven weeks passed between the release and the report.
The checklist
Answer each as yes, partly, or no. Be honest, because partly is the usual answer.
Ownership
- Do we know when a package we use changes maintainer, and does anyone see that signal?
- Do we treat a critical package with one maintainer as a risk worth recording?
Change review
- When a lockfile changes, does a person look at newly added packages, not only version bumps?
- Would a brand new transitive dependency with a low download count stand out in the pull request?
- Do we update dependencies on a schedule with review, rather than automatically on every release?
Build behavior
- Do our builds run in an environment with no outbound network access beyond what they need?
- Do install scripts and build scripts run with the fewest privileges possible?
- Would a build step that decrypts data or compiles code in memory appear in any log or alert?
Detection and response
- Can we answer "do we use this package, at this version?" in minutes, across every repository?
- Do we have a way to find it in built artifacts, not only in source?
- Is there a named owner for responding when a package we use is reported?
Why this is not victim blaming
The people who used event-stream were doing what the ecosystem encourages: reusing a popular package. The package had no obvious red flag until the change. The checklist exists because the control that would help, looking at changes in what you depend on, is dull work that rarely gets scheduled.
What to do
- Turn on alerts for maintainer changes and new dependencies in your package manager or scanner.
- Make lockfile diffs a required review item, with a note on any new package added.
- Build with a pinned, locked install so what you test is what you ship.
- Restrict build network access and keep secrets out of build steps that do not need them.
- Keep an SBOM per release so "are we affected?" becomes a search.
- Run a tabletop once a year using this incident as the scenario.
Quick check
Would vulnerability scanning have flagged event-stream 3.3.6?
Not before it was reported. Scanning that compares against known advisories needs an advisory to exist. Change review, maintainer signals and malware detection cover the earlier window.
Is pinning versions enough?
Pinning stops silent upgrades, but it does not tell you whether a version you chose is safe. Pair it with review and with ongoing checks against new advisories.
Sources
Last reviewed: 18 October 2026.
