DuckDB NPM packages 1.3.3 and 1.29.2 compromised with malware

Original Article ↗ Hacker News Discussion ↗

Incident and npm response

  • Malicious versions of several DuckDB npm packages were published after a maintainer was phished, similar to a Chalk/debug compromise the day before.
  • Initial claim that “no one downloaded” the bad versions was walked back; npm download stats are delayed. Third‑party monitoring observed installs while they were live.
  • Maintainers tried to unpublish but npm initially blocked it due to dependencies; they instead pushed newer safe versions and npm later removed the compromised ones.
  • Multiple comments criticize npm/GitHub/Microsoft as slow to respond and inconsistent with their “security first” messaging.

How the phishing worked

  • Maintainer received a convincing “npm security” email from a typo‑squatted domain (npmjs.help) with a realistic tone and layout.
  • The site was a near‑perfect clone of npm, acting as a relay: credentials and 2FA codes entered on the fake site were forwarded to real npm, allowing the attacker to reset 2FA and create a new API token.
  • People note the many missed red flags (weird domain, browser not autofilling credentials), but others argue real services routinely train users to ignore such red flags by using odd domains and link shorteners.

2FA vs passkeys, hardware tokens, and password managers

  • Strong current in favor of passkeys/FIDO2/YubiKeys for “critical” packages, arguing they’re origin‑bound and effectively unphishable for this attack class.
  • Counterpoints:
    • Passkeys historically had portability/backup issues and can feel tied to big ecosystems, though some say migration and multi‑device setups are now workable.
    • Hardware tokens need multiple keys and form‑factor compatibility (USB‑C, NFC, mobile).
    • Even strong auth can be bypassed via other flows (e.g., OAuth device code phishing) and doesn’t eliminate all account takeover.
  • Several argue good password manager autofill (not copy‑paste) already gives strong phishing resistance by refusing to fill on the wrong domain; others note autofill often breaks, training users to override it.

Proposed registry/platform mitigations

  • Enforce passkeys or FIDO2 (not TOTP) for high‑impact npm accounts.
  • Freeze publishing for some period after 2FA reset, auth factor changes, or new token creation; require a second maintainer to re‑authorize.
  • Quarantine new versions from being treated as “latest” for automation for N hours/days, while still allowing explicit installs.
  • Require signed artifacts and provenance:
    • End‑to‑end signing from developer keys (ideally offline/HSM‑backed) to registry.
    • Verify that npm releases correspond to signed VCS tags; flag or block if not.
  • Some suggest multi‑maintainer approvals (“maker‑checker”) for publishing popular packages.

Email and phishing‑surface issues

  • Calls for signing all maintainer‑facing emails (GPG or similar) so unsigned “npm security” messages can be distrusted.
  • Others argue SPF/DKIM/DMARC and even GPG don’t help if users ignore sender domains, and that real companies already use confusing third‑party domains, seed distrust, and normalize sketchy patterns.
  • Several recommend treating all “pushed” messages (email/SMS) as untrusted: no clicking links, always navigating manually via bookmarks and trusted domains.

Broader ecosystem & dependency risk

  • Many see this as another example that npm’s huge, fine‑grained dependency graphs amplify supply‑chain risk: one compromised maintainer infects millions.
  • Comparisons to Debian/PyPI:
    • Debian’s slow, curated releases seen as much safer, though not perfect (e.g., xz and OpenSSL history mentioned).
    • PyPI is viewed as somewhat better due to stronger governance, simpler dependency graphs, and typo‑squatting defenses, but still has phishing incidents.
  • Some suggest delaying auto‑upgrades and strictly honoring lockfiles (npm ci), avoiding tools that “helpfully” override locks, and possibly only adopting versions after a “cooling‑off” period.

DuckDB‑specific security criticism

  • One commenter argues DuckDB shows a pattern of lax security, pointing to the recommended curl https://install.duckdb.org | sh installer.
  • Others push back:
    • The real risk is ultimately trusting the project at all; whether you pipe to sh or download then execute is a marginal difference unless you verify signatures.
    • DuckDB binaries are also available via other channels (e.g., package managers, GitHub releases).
  • Some still prefer distro packages or signed installers over remote scripts, emphasizing immutability, third‑party review, and reduced attack surface.