Skip to main content

SUP-COMPROMISE-004 Backdoored release

A direct or transitive dependency matches a curated supply-chain incident in the backdoor_release kind. The package's own author introduced attacker-friendly behaviour at the source-tree level of a specific release. This is distinct from SUP-COMPROMISE-001: the legitimate publisher account was not hijacked; the legitimate publisher is the source of the bad code.

Backdoored releases include both protest payloads (the peacenotwar family) and outright sabotage (deliberate infinite loops that broke downstream builds). The remediation pattern is the same: remove the affected version from your tree and pin forward to a clean release.

Catalogued incidents under this kind include:

  • INCIDENT-2022-colors (npm: [email protected], 1.4.2), the author-introduced infinite loop sabotage that broke thousands of downstream builds.
  • INCIDENT-2022-node-ipc (npm: [email protected]), the author-introduced peacenotwar payload that deleted files on machines geolocated to Russia / Belarus.

What Vulkro detects​

The detector walks every (ecosystem, name, version) triple and looks each one up against the curated catalog. A row whose kind is backdoor_release and whose versions[] contains the installed version produces a SUP-COMPROMISE-004 finding.

Severity: the catalog row's severity (typically Critical). Confidence: High. Evidence signal: compromised-release-exact-version-match, weight 1.0.

Non-compliant lockfile​

{
  "name": "my-app",
  "version": "1.0.0",
  "lockfileVersion": 3,
  "packages": {
    "node_modules/node-ipc": {
      "version": "10.1.1",
      "resolved": "https://registry.npmjs.org/node-ipc/-/node-ipc-10.1.1.tgz"
    }
  }
}

[email protected] is inside the catalogued peacenotwar window.

Compliant lockfile​

Pin to a clean version published before the backdoor, or to a verified clean fork that has reviewed and removed the affected source-tree changes. The advisory in the finding lists the known-good versions on either side of the window.

Remediation​

  1. Remove the affected version from your dependency tree and pin to a version published before the backdoor was introduced, or to a verified clean fork.
  2. Review logs and outbound network traffic from the time the bad version was in use. Backdoored releases sometimes contact a remote, sometimes do silent local damage; the advisory in the finding describes the specific behaviour.
  3. For machines that ran the bad version, audit the file system for any damage the payload caused (peacenotwar-style file deletion is the canonical case).
  4. Rotate credentials the host environment could have seen while the bad version was active. A non-network payload is not necessarily a non-incident: the package had reach into the same process as your credentials.
  5. Run vulkro respond against every project to find every other place the same package version is in use.

See also​

References​

Last updated on