DMARCPulse
Get started — free
All posts Supply-Chain Attacks on npm and PyPI: Why Email Authentication Protects Developer Accounts

Supply-Chain Attacks on npm and PyPI: Why Email Authentication Protects Developer Accounts

DMARCPulse Team

When the Package Becomes the Weapon

Three malicious versions of node-ipc — an npm package with millions of weekly downloads — were found to contain a stealer and a backdoor. The TanStack incident revealed how a single compromised developer account can trigger a supply-chain attack that reaches organizations like OpenAI and beyond. Both cases follow the same playbook: an attacker takes over a legitimate account, pushes a poisoned version to the registry, and waits for CI/CD pipelines around the world to pull it automatically.

This is not a theoretical scenario. It is happening regularly, and the attack surface keeps growing.

How Accounts Get Compromised — and Where Email Fits In

The most common entry points for account takeovers on npm and PyPI are:

  • Phishing emails that convincingly impersonate npm or PyPI notifications
  • Credential stuffing using passwords from previous data breaches
  • Fake security alerts that trick developers into entering credentials on a spoofed page

The second and third vectors are directly tied to email. If an attacker can send a message that looks like an official npm notification — same sender address, same layout — the odds are good that a developer clicks without a second thought.

That is exactly where email authentication comes in.

What DMARC, SPF, and DKIM Actually Prevent

SPF defines which mail servers are allowed to send on behalf of a domain. DKIM cryptographically signs every outgoing message. DMARC ties both together and gives receiving mail servers a clear instruction: what should happen when a message fails SPF or DKIM?

Without DMARC enforcement on npm’s or PyPI’s notification domain, an attacker can send an email that lands in a developer’s inbox looking like this:

From: no-reply@npmjs.com
Subject: Security alert: Unrecognized login detected

With DMARC set to p=reject, that spoofed message is rejected by the receiving mail server before it ever reaches the inbox. The developer never sees it.

For registries like npm and PyPI, the implication is clear: their notification domains must have DMARC at p=reject or at minimum p=quarantine, with full SPF and DKIM coverage across all legitimate sending paths.

BIMI as an Additional Trust Layer

BIMI (Brand Indicators for Message Identification) goes one step further. When DMARC is correctly configured, mail clients like Gmail or Apple Mail can display the sending organization’s verified logo next to the message. For a developer receiving dozens of notifications a day, that is an immediately recognizable trust signal.

A spoofed npm email cannot display a verified BIMI logo — that requires a valid VMC (Verified Mark Certificate) tied to the domain. So if a developer sees the official npm logo in their inbox, they know: this message genuinely came from npmjs.com.

What Developers and IT Teams Should Do Now

Responsibility sits on two sides.

For registries and platforms (npm, PyPI, GitHub): Notification domains must be fully secured with SPF, DKIM, and DMARC at p=reject. BIMI should be implemented to give developers a visual verification mechanism. DMARC aggregate reports help detect unauthorized sending attempts early.

For developers and IT admins: Anyone running their own domains for internal notifications, CI/CD alerts, or package registry integrations should apply the same standard. An internal notification domain without DMARC is an open door for spear-phishing against your own development team.

Beyond that: review DMARC reports regularly. If unknown IP addresses suddenly start attempting to send mail on behalf of your domain, that is an early warning signal — long before any developer clicks a phishing link.

The Bigger Picture: Supply-Chain Security Starts in the Inbox

The attacks on node-ipc and TanStack make one thing clear: supply-chain security is not purely a code problem. Before an attacker can push a malicious package, they need to take over an account. And for that, they almost always need a convincing phishing attack — delivered by email.

Neglecting email authentication on notification domains hands attackers a ready-made weapon. DMARC at p=reject, properly configured DKIM and SPF, and BIMI for visual verification are not nice-to-haves. They are the first line of defense against the account takeovers that make supply-chain attacks possible in the first place.

Want to know how your domain is currently configured? Check it for free with the DMARCPulse Domain Check — SPF, DKIM, DMARC, and BIMI status at a glance.