Publisher Change

The publisher change rule detects when a package version is published by an npm account that has never published a version of that package before. This catches account takeover attacks and social engineering of package ownership transfers.

What it detects

When a package that has historically been published by a consistent set of maintainers suddenly has a version published by someone new, this rule triggers. It specifically targets the pattern where an attacker gains control of a package -- either by compromising a maintainer's npm account or by social engineering an ownership transfer.

How it works

1. The rule sorts all versions of a package by publish time
2. It builds a "historical publisher set" from the first 80% of versions by reading the _npmUser.name field
3. For the remaining 20% of versions (the most recent), it checks if any were published by an account not in the historical set
4. Versions published by a new account are flagged

The 80/20 split avoids false positives on packages with many contributors over their full history. The rule requires at least 5 published versions to have enough data for meaningful analysis -- packages with fewer versions are skipped.

Configuration

Real-world examples

This rule would have caught:

• ua-parser-js (2021) -- Account takeover led to three malicious versions shipped by a different publisher
• coa / rc (2021) -- 23M combined weekly downloads hijacked via account takeover
• eslint-scope (2018) -- Maintainer's npm credentials stolen, malicious version published
• lottie-player (2024) -- Stolen npm token used to publish versions from a new account
• eslint-config-prettier (2025) -- Phishing email tricked the maintainer into leaking their npm token
• event-stream (2018) -- Ownership transferred to a stranger who published a backdoored version

Limitations

• Requires at least 5 published versions to build a meaningful historical publisher set. Newer packages are skipped.
• The rule depends on the _npmUser field being present in the packument. If npm changes their API format, this field may not be available.
• Legitimate ownership transfers (e.g., a company hiring a new maintainer) will trigger this rule. That is expected behavior -- these events should be reviewed even when they are legitimate.

Recommended setting

Warn for most teams. Publisher changes happen legitimately (team changes, ownership transfers), but they are always worth reviewing. Teams in regulated industries or with high-value targets may want to set this to block and manually review publisher changes.