Stellarshift and Tailwind npm Malware Alert

Short answer: Six malicious npm packages were disclosed on September 2, 2026, including four packages in the @stellarshift scope, real-router-utils, and tailwindcss-fluid-styles. Remove the affected versions immediately; if an affected package ran on a workstation or build host, isolate that system and rotate credentials from a separate, trusted machine.

The Stellarshift npm malware is especially notable because its install hook targets managed developer workstations that have Lark or Feishu and FortiClient installed. The separate Tailwind-themed package uses Ethereum transactions to resolve command-and-control infrastructure, launches a hidden process, and then erases its malicious loader from its own source file.

Which malicious npm packages and versions are affected?

The authoritative OpenSSF/OSV records identify these exact packages and versions:

There is no patched release identified for any of these records. The safe remediation is removal and replacement, not an upgrade within the same package line. Do not confuse tailwindcss-fluid-styles with Tailwind CSS itself: the advisory concerns this specific third-party package name and version.

When were the advisories originally disclosed?

The primary OSV records for the four @stellarshift packages were originally published at 2026-09-02 17:38 UTC. real-router-utils was published at 2026-09-02 22:09:01 UTC, and tailwindcss-fluid-styles at 2026-09-02 22:10:01 UTC. These dates are from the original 2026 advisory records, not a later roundup or a resurfaced incident.

Developers can review the primary records for @stellarshift/abi-tools (MAL-2026-15821), real-router-utils (MAL-2026-15825), and tailwindcss-fluid-styles (MAL-2026-15826). The four Stellarshift records share the same targeting and loader pattern.

How does the Stellarshift npm malware work?

Each Stellarshift package advertises a plausible cryptocurrency utility, such as ABI hashing, chain metadata, EVM address validation, or token-unit conversion. The malicious behavior is unrelated to those stated functions.

During installation, a postinstall hook reconstructs an obfuscated URL from an XOR-encoded integer array. On Unix-like systems the loader can pipe the downloaded response directly to bash; on Windows it uses a hidden PowerShell command. The remote bytes are not pinned by a hash or verified with a signature, so whoever controls the endpoint can change what runs.

The loader also tries to avoid ordinary analysis environments. The records say it checks for CI variables and targets macOS or Windows systems where both a Lark or Feishu collaboration client and FortiClient VPN are present. It launches the child process detached, suppresses output, hides the window on Windows, swallows errors, and exits successfully so the package installation can appear normal.

This targeting matters during triage. A clean CI run does not prove a developer laptop was safe, because CI is deliberately skipped. Conversely, finding the package in a lockfile proves dependency exposure but does not by itself prove the second-stage payload executed on every host. Treat any matching managed workstation as high priority.

Why is tailwindcss-fluid-styles different?

tailwindcss-fluid-styles@2.0.7 does not rely on a lifecycle hook. Its malicious blob executes at the top level when src/index.js is loaded, which may happen when a Tailwind configuration or build imports the plugin.

The decoded loader queries Ethereum RPC endpoints and reads the latest transaction associated with a hardcoded address. It decodes transaction data into two IP addresses used as command-and-control hosts. It then retrieves XOR-encrypted payloads from /0x/cls and /0x/ls, evaluates one, and starts the other through a detached node -e process with hidden output.

After running, the module rewrites its own file to remove the encoded loader. That anti-forensic step means inspecting the package after first execution may show only a benign-looking Tailwind plugin. Absence of the original blob on disk is therefore not reliable evidence that the host was never exposed.

How can you check whether a project is exposed?

1. Ask the package manager for the full dependency tree

npm ls --all @stellarshift/abi-tools @stellarshift/chain-metadata \
  @stellarshift/evm-address-kit @stellarshift/token-units \
  real-router-utils tailwindcss-fluid-styles

Repeat this in every repository, including local tools, documentation sites, prototypes, and CI helper projects. A non-zero exit can mean npm found an invalid tree, so read the output instead of treating the exit code alone as the verdict.

2. Search lockfiles and workspace manifests

rg -n '(@stellarshift/(abi-tools|chain-metadata|evm-address-kit|token-units)|real-router-utils|tailwindcss-fluid-styles)' \
  --glob 'package.json' --glob 'package-lock.json' --glob 'npm-shrinkwrap.json' \
  --glob 'yarn.lock' --glob 'pnpm-lock.yaml'

Check commit history too. A package that has already been removed from the current branch may still have run in an earlier build, release job, or developer checkout.

3. Review install and build telemetry

For the Stellarshift packages, look for installs on macOS or Windows workstations with Lark/Feishu and FortiClient. Review process and network telemetry for hidden PowerShell, curl piped to bash, or connections to the Tencent Cloud COS URL recorded in the advisory.

For real-router-utils, investigate requests to the advisory's webhook.site collector and assume the username, hostname, and working directory may have been disclosed. For tailwindcss-fluid-styles, look for Ethereum RPC access followed by direct-IP HTTP requests to /0x/cls or /0x/ls, plus detached Node processes.

4. Scan without executing package code

Use an advisory-backed scanner against manifests and lockfiles. InstallSafe's free npm package scanner can check named versions against OSV data without asking you to install the package. For a broader review process, see how to check whether an npm package is safe and the comparison of npm vulnerability scanners.

What should you do if you find an affected version?

1. Stop using the host. Isolate it from the network and preserve relevant logs before cleanup.
2. Remove the package and replace its function. No fixed version is listed, so do not simply move to another release under the same name.
3. Rebuild from a known-good image. This is particularly important for Stellarshift's remote shell execution and Tailwind's detached, self-erasing second stage.
4. Rotate secrets from a different trusted device. Revoke npm, GitHub, cloud, SSH, package-registry, CI, and application credentials that were accessible to the affected account or host.
5. Invalidate sessions and inspect accounts. Review new tokens, repository changes, package publications, cloud activity, and authentication events during the exposure window.
6. Regenerate dependencies. Remove affected lockfile entries, rebuild node_modules and caches from trusted inputs, and verify the new graph before restoring service.

Deleting node_modules alone is not incident response. The packages can execute remote code or launch a process outside the dependency directory, and the Tailwind-themed loader intentionally modifies its own evidence after execution.

How does a registry firewall reduce this risk?

A registry firewall places policy enforcement at the package-download boundary. Once OSV marks these exact versions as malicious, an advisory-backed firewall can reject them for developer machines, CI jobs, containers, and AI coding agents before npm receives the tarball. Central enforcement is useful because it does not depend on every project remembering to add a scanner step.

InstallSafe uses OSV.dev advisory data and blocks flagged versions while serving byte-for-byte upstream tarballs for allowed packages. That provides consistent controls across package managers and automation, and it can prevent reinstallation after disclosure. See the registry setup documentation for implementation details.

A registry firewall is not a zero-hour detector. Before an advisory exists, behavior-analysis products may spot suspicious install scripts, obfuscated endpoints, or hidden process creation earlier. Strong programs combine those behavioral signals with lockfiles, least-privilege credentials, egress controls, and install-boundary enforcement after a version is identified.

Frequently asked questions

Is Tailwind CSS itself compromised?

No evidence in these advisories says the official Tailwind CSS package is compromised. The malicious package is specifically tailwindcss-fluid-styles@2.0.7.

Are all @stellarshift versions affected?

The primary records list versions 1.0.1 and 1.0.3 for each of the four packages. Because no fixed version is identified, remove the packages rather than attempting an in-family upgrade.

Does --ignore-scripts prevent every package in this alert?

It can stop the preinstall and postinstall hooks used by five packages, but it does not stop malicious code that runs when an application or build imports tailwindcss-fluid-styles.

Does a lockfile match prove the machine was compromised?

It proves the affected dependency was resolved. Execution depends on installation and, for the Tailwind-themed package, module loading. Because the possible outcome is remote code execution, investigate conservatively.

Can removing the package clean an affected workstation?

No. Removal prevents normal future use but cannot prove that downloaded code, background processes, or stolen credentials are gone. Rebuild the host and rotate accessible secrets from a trusted system.

Can an npm registry firewall block these versions now?

Yes, if it consumes the new OSV records and enforces them before download. It would not have guaranteed detection before the September 2 disclosures.