Security: bare `testing-library` npm namespace held by third party — baitsquatting risk

[zkDeej]

Hi Testing Library team,

Quick security heads-up: the bare testing-library npm namespace — the intuitive alias for @testing-library/react and related packages — is held by a third-party account (lortmann), not by the testing-library org.

AI coding agents recommend testing-library as the natural bare package name. If that account is compromised, developers running AI-generated test scaffolds would execute untrusted code in their CI environments — which typically have access to deployment keys and secrets.

Recommended action: Claim testing-library defensively under the testing-library npm org. A placeholder is sufficient.

Part of coordinated disclosure BSQT-2026-001 — publishing publicly in ~2 weeks.

— DJ (https://github.com/zkDeej)

[eps1lon]

I've contacted NPM to establish contact with the author. The library has 17k weekly downloads so we need to figure out if those are legit or accidental.

[zkDeej]

Hi @eps1lon

BSQT-2026-001 covers two distinct attack flows. testing-library / @testing-library/react falls under Flow A (install-time) only:

	Flow B — Execution-time	Flow A — Install-time
Trigger	npx <bare-name> in shell	npm install <bare-name>
Env exposure	Full shell (all secrets)	Install scripts only
Live incident?	✅ npx lhci autorun executed rogue package with credentials loaded	❌ No confirmed incident
testing-library / @testing-library/react	❌ Not applicable — test utility, no npx path	✅ Theoretical install-time confusion only
Urgency	Critical	Low

The npm outreach you're already doing is the right defensive action — just didn't want you treating this as equivalent urgency to the live incident case. Good to close if you agree.

— DJ (BSQT-2026-001)