Fake Tailwind npm Packages: 10 Typosquats, 1 Working Cover (2026)

The npm package tailwindcss-form-styles did something clever. Its src/index.js re-exported the genuine Tailwind forms plugin, so if you installed it and added it to your config, your forms styled correctly and nothing looked wrong. Appended to that working cover was an obfuscated blob ending in eval(atob(...)) over roughly 41KB of base64. Its advisory notes the payload "fires as soon as any Tailwind build loads this plugin."

It was one of ten fake Tailwind plugins published to npm since October 2025. Tailwind is in almost every frontend that Bolt, Lovable, v0 and Cursor generate, and founders add plugins to it by asking the assistant for one.

The names

Every date below comes from the npm registry and the OSV advisories, read on 22 September 2026.

Read that list slowly, because the confusability is the attack. tailwindcss-form-styles and tailwind-forms-styles are two different malicious packages, published three weeks apart, differing by two characters. So are tailwindcss-form-ui and tailwindcss-forms-ui. The real package is @tailwindcss/forms.

Names also rotate fast. tailwindcss-form-ui came off npm at 14:44 UTC on 17 September, and tailwindcss-form-utils went up at 14:54, ten minutes later. tailwindcss-forms-ui followed the same night.

None of these needed an install script

Most npm supply-chain advice assumes the payload fires during installation. That is where npm install --ignore-scripts earns its reputation.

Not one of the seven advisories with technical detail mentions postinstall or preinstall. Every one describes execution at require time or plugin-load time. MAL-2026-14189 is the most explicit:

Following the README's instruction to register the default export as a Tailwind plugin causes Tailwind to invoke getPlugin, executing attacker-controlled JavaScript with full Node.js capabilities on the developer's machine.

And MAL-2026-14568, on the working-cover package:

The eval fires as soon as any Tailwind build loads this plugin, resulting in attacker-controlled code execution in the installer's build environment (developer machines and CI runners).

So the sequence is: you install a package, which does nothing. You add it to tailwind.config.js, exactly as its README says. That is the step that runs the code, on your machine and on every CI runner that builds the project.

We already track three execution triggers across the 2026 npm compromises: install hooks, build-time execution through node-gyp, and import-time payloads. Plugin registration is a fourth, and it is the one most likely to reach a founder, because editing a config file feels like configuration rather than like running something.

What actually links them

The advisories publish SHA-256 hashes of the files they sampled. Cross-referencing those hashes across the seven 2026 records shows two payloads that are byte-identical across multiple packages:

f5fd0ca9d764...  tailwind-forms-styles, tailwindcss-form-ui, tailwindcss-form-utils
fd1ef3edfc6c...  tailwind-form-kit, tailwindcss-forms-ui

Identical files, not similar ones. MAL-2026-14568 goes further and notes an embedded campaign tag string, A10-npm_new2. Four of the advisories also record that the package's own package.json pointed its repository field at tailwindlabs/tailwindcss-forms, borrowing the real project's credibility, and one mirrored its README verbatim.

tailwind-extension-kit is the odd one out and probably a different actor. It shares no file hashes with the others, used a hardcoded IP endpoint rather than the blockchain dead-drop the rest used, and executed through new Function rather than child_process. It has a Tailwind-themed name and nothing else in common.

What we do not know, stated plainly

Download counts for these packages, from 1 August to 22 September 2026, were small:

For comparison, @tailwindcss/forms does about 3.3 million a week. The two packages that lived roughly an hour got zero downloads between them, and a meaningful share of the rest is likely security vendors pulling samples rather than anyone's actual project. Nobody was mass-compromised here.

So this is not a "you probably have this installed" story. It is a "the next one of these is coming and your main defence does not apply" story.

Two other limits worth knowing. Once npm removes a package, the tarballs are gone, so nobody can go back and audit which versions were clean. And two of the advisories list their affected range as everything from version 0 onward, so a scanner will flag every version of those packages, including the first. Do not read a version's absence from an advisory as evidence it was safe; the version lists record which files got sampled.

How to check, in about two minutes

grep -nE "tailwindcss-forms-kit|tailwindcss-form-bundler|tailwind-extension-kit|tailwindcss-form-styles|tailwind-forms-styles|tailwind-form-kit|tailwindcss-form-ui|tailwindcss-form-utils|tailwindcss-forms-ui" \
  package.json package-lock.json yarn.lock pnpm-lock.yaml 2>/dev/null

That covers nine of the ten. The tenth, tailwindcss-forms, is left out on purpose: as a bare string it also matches tailwindlabs/tailwindcss-forms, the legitimate repository path that shows up in plenty of innocent lockfiles, so searching for it mostly produces false alarms.

No output means none of them reached your dependency tree, which is the likely outcome. If something matches, rotate every credential that machine could reach and do it from a different machine, because the advisories say to treat the host as fully compromised. Deleting the package does not un-steal anything already sent.

Then read your Tailwind config against what each package really is:

grep -n -A15 "plugins" tailwind.config.js

The useful heuristic is scope. Tailwind Labs publishes its own plugins under @tailwindcss, so the real forms plugin is @tailwindcss/forms, currently 0.5.11, with its repository at tailwindlabs/tailwindcss-forms. An unscoped package whose name is a longer, more descriptive-sounding version of a first-party one is the exact shape this cluster used. tailwind-forms-styles reads like a better name than @tailwindcss/forms, and that is the trick.

Two things this is not

If you search for Tailwind and blockchain malware you will hit a March 2026 story about attackers force-pushing commits that modified tailwind.config.js and .gitignore in compromised repositories. That one used Tron and Aptos, involved no npm packages, and is unrelated to this cluster despite sharing all three keywords.

You will also hit material-tailwindcss, a typosquat from September 2022 that did use a postinstall hook. Also unrelated, and a good illustration of why the install-script assumption became the default.

Why this keeps landing on vibe-coded projects

Typosquatting is not new. What changed is who picks the package name.

Ask an assistant to add form styling to a Tailwind project and you get a name in a code block plus an instruction to register it in your config. You cannot tell a real plugin from a fake one by reading the name, because the fake was designed to read as more legitimate than the real one. Then you follow the README, and on these packages that was the moment the code ran.

The defence is dull and it works: check the name against the registry before installing, prefer the scoped first-party package when one exists, and keep a lockfile so you know exactly what landed.