From event-stream to xz: Four Supply Chain Attacks and the Signals They Left Behind

Every famous supply chain attack gets retold as a parable about clever attackers. The more useful retelling is about signals: in each case, public metadata — maintainer changes, publishing anomalies, contributor concentration — was flashing before the payload fired. Here are four canonical incidents and what each one teaches about reading a repository before you trust it.

## event-stream (2018): the handover attack

event-streamwas a popular npm streaming utility whose original author had long moved on. A helpful stranger, “right9ctrl”, offered to take over maintenance — and the author, reasonably by the norms of the time, handed it over. The new maintainer added an innocent-looking dependency, flatmap-stream, then shipped a version of it containing an encrypted payload that targeted one specific victim: the Copay bitcoin wallet, harvesting keys from wallets with large balances.

The signal:a dormant, single-maintainer package suddenly under new ownership, immediately growing a brand-new dependency published by an account with no history. Ownership transitions are the single most dangerous moment in a dependency's life.

## ua-parser-js (2021): the hijacked account

ua-parser-js, a user-agent parser downloaded millions of times a week, shipped three malicious versions in October 2021 — not because the maintainer turned, but because his npm account was compromised. The rogue releases installed a cryptominer and a password stealer on infected machines.

The signal: package versions published with no corresponding activity in the source repository — no commits, no tags, no release notes. When the registry and the repo disagree, believe the repo and treat the package as hostile until proven otherwise.

## node-ipc (2022): the maintainer as the threat

In March 2022 the sole maintainer of node-ipc added code (tracked as CVE-2022-23812) that detected Russian and Belarusian IP addresses and overwrote files on those machines — protestware shipped as a patch release into thousands of downstream projects, including major frameworks.

The signal: a bus factor of one is not only a continuity risk; it is a control risk. One person with sole publish rights can ship anything, for any reason, to your production systems in an afternoon. The bus factor analysis covers how to measure exactly this concentration.

## xz-utils (2024): the long con

The most sophisticated of the four. Over roughly two years, an identity known as “Jia Tan” built trust in the xz compression project — real patches, patient presence — while sock-puppet accounts pressured the overloaded solo maintainer to share commit access. Once inside, the attacker shipped a backdoor (CVE-2024-3094, CVSS 10.0) hidden in build scripts and test files, targeting sshd on major Linux distributions. A Microsoft engineer noticed SSH logins were half a second slow and unraveled the whole thing — weeks before the compromised versions would have reached stable distros everywhere.

The signal: the attack exploited visible facts — a critical library, one exhausted maintainer, a sudden new co-maintainer doing most of the committing. Everything an audit of contributor concentration and maintainer transitions is designed to surface.

## The pattern across all four

• -Popularity was the delivery mechanism, not a defense. Every one of these packages was popular; that is precisely why they were targeted. Download counts and star counts measure blast radius, not safety.
• -Maintainer transitions are the risk window. Three of the four attacks began with a change in who controls publishing — a handover, a hijack, an earned promotion.
• -Single-maintainer projects concentrate every risk. Burnout, coercion, ideology, account theft: one point of failure for all of them.
• -The metadata was public the whole time. None of these signals required insider access — only someone looking.

## Be the someone looking

You cannot code-review every dependency. You can absolutely audit the humans and the history around the ones that matter.

Before a new dependency lands in your lockfile, spend two minutes on its people: how concentrated are recent commits, did maintainership recently change, do releases match repository activity, are there known vulnerabilities on record? The TrustOSS analyzer runs that audit for any public GitHub repository — health score, deep scan with bus factor and OSV vulnerability checks, and a star audit to verify the popularity is organic. The full evaluation checklist covers the rest.