RedC2 npm Packages: Importing Can Infect a Linux Host

Brendan Smith
Brendan Smith - Cybersecurity Analyst
5 Min Read
A calendar opens into a hidden doorway, illustrating the RedC2 package import risk.
RedC2 hides a Linux backdoor behind working npm calendar utilities.

RedC2 4.0 hides a Linux backdoor inside working npm calendar utilities, and importing a package starts the payload. TrendAI’s August 20 analysis identifies 14 packages carrying RedShell. For a developer finding one in a project, the urgent question is which Linux environment loaded it—not simply whether installation scripts were disabled.

Why an ordinary build can cross the boundary

The package entry point, dist/index.mjs, launches a bundled ELF while still exposing functional date helpers. That makes a successful test a poor safety signal. npm’s ignore-scripts setting controls package scripts; it does not turn subsequently imported JavaScript into inert data.

A developer can install dependencies with scripts disabled and later start a test, development server, or build that loads the dependency. Review those later jobs as well as installation. This differs from the Packagist postinstall-hook incident, where the installation step was central.

The streak-metrics-math package contains index.mjs and math-calc.bin alongside date utilities.
Package structure from TrendAI: working date utilities sit alongside the loader and binary.

Check the exact package and version

The confirmed versions are streak-metrics-math 1.0.0 and 1.0.1, plus version 1.0.0 of each package below:

  • kit-map-vim
  • streak-map-cache
  • streak-map-kit
  • map-streak-kit
  • streak-cache-map
  • streak-calc-metrics
  • streak-calc-math
  • streak-math-abz
  • streak-metricsaz
  • streak-math-metrics
  • streak-metricazbd
  • streak-metricsazb
  • streak-kit-map

Search saved manifests and lockfiles as text first. Do not import a suspect dependency to find its version or test whether it works.

Turn a match into an exposure decision

What you found Next decision
Name only in documentation Find the actual dependency record. A mention alone does not identify an affected host.
Lockfile or cache match Preserve it and find which jobs used that version. A stored package does not establish execution.
Installed, with no known import Pause jobs using that workspace. Review test, build and server logs before deciding it never loaded.
Imported in a Linux runtime Contain that workstation, runner or container. Inventory credentials and mounted resources available to its account.
Unexpected child process or network activity Escalate as a suspected compromise and preserve runtime evidence before cleanup.

Record the job ID, time, host, user, package version and subsequent artifact for each match. On a Windows PC using WSL, identify the Linux environment that ran Node. For a container, include mounted directories and injected secrets; an ephemeral container does not make accessible credentials disposable.

Recover the environment and the release path

  1. Stop reuse. Remove the affected runner from scheduling and isolate the suspect runtime. Keep a copy of lockfiles, job logs and relevant process/network evidence for responders.
  2. Scope access. Make a list of repository, registry, cloud, SSH and database credentials reachable by that runtime. From a clean device, revoke exposed tokens and sessions and issue replacements. Avoid writing replacement secrets back to the old runner.
  3. Rebuild cleanly. Remove the dependency from a reviewed source tree and regenerate the dependency resolution in a trusted environment. Rebuild an affected disposable runner or container from a known-good base. Deleting node_modules alone is not a recovery verification.
  4. Review persistence. For retained hosts, have responders inspect startup mechanisms and changes under the affected account. The analyzed implant supports cron, shell-startup, systemd and XDG persistence; capability does not establish which method ran on this host.
  5. Hold affected outputs. Identify packages, images or deployments produced after the suspected import. Review their provenance and contents before release, and rebuild questionable outputs. The separate Megalodon CI incident explains why the release path belongs in a dependency investigation.

The analyzed package payload is Linux-specific. The framework’s broader advertised features do not demonstrate Windows or macOS infection through these packages, nor prove every capability executed. Close the investigation with recorded host and release checks, rather than a successful dependency reinstall alone.

References

  1. Aliakbar Zahravi. Prompting the Payload: How an npm Supply Chain Attack Delivers the RedC2 AI-Powered Linux Implant. TrendAI, August 20, 2026.
  2. npm. Configuration: ignore-scripts. npm CLI documentation, accessed September 7, 2026.
Share This Article
Cybersecurity Analyst
Follow:
Brendan Smith has spent over 15 years knee-deep in cybersecurity, chasing down malware from the gritty reverse-engineering of old-school trojans all the way to wrangling full-blown incident responses for small-to-medium businesses that couldn’t afford a full-blown breach. Over at Gridinsoft, he’s the guy piecing together those double-checked guides on nasty stuff like AsyncRAT, a remote access tool used in malware campaigns—helping readers make sense of the threat and work through cleanup without the extra headache.
Leave a Comment

AI Assistant

Hello! 👋 How can I help you today?