npm worm on transactional mail packages: when a mailer library quietly BCCs your payroll emails

> TL;DR: A widely used transactional mailing npm package (several million weekly downloads) was compromised after an attacker stole a maintainer's npm credentials. The malicious version adds a single line of code that blind-copies (BCC) every email sent through the package to an attacker-controlled address, then self-removes from the codebase after a few days to muddy the trail. Applications sending payslips, invoices, or password reset links via this package may have leaked those documents in plaintext during the compromise window.

Why this concerns you directly

If your HR or payroll SaaS sends payslips, payment confirmations, or magic login links by email, chances are it goes through a third-party library rather than a hand-rolled SMTP server. That's exactly the surface targeted here: not your code, not your infrastructure, but a dependency you added one day with npm install and never re-checked since.

The scenario is particularly nasty for HR emails: a payslip contains a name, IBAN, net salary, sometimes a national ID number. A password reset email grants direct account access. Both are prime targets, and both typically flow through this kind of package.

How the attack worked

What makes this attack hard to detect

Unlike a classic API key theft that generates easily-spotted abnormal outbound traffic, this attack only slightly modifies an already-legitimate flow: email sending. SMTP traffic volume barely changes. No new domain shows up in your application logs — only in the BCC header of each email, invisible without manually inspecting sent content.

What to check right now

The takeaway

This isn't the first npm supply chain attack, and it won't be the last. What's different here is the target: not cloud keys or crypto wallets, but the silent exfiltration of sensitive HR documents through a channel — transactional email — that most teams never monitor at the content level. If your product emails sensitive data, the question isn't just "which package am I using" but "who can read what this package sends on my behalf."