Supply chain · npm · High

Critical npm Package 'monkey-tags-ip' Implicated in Dependency Confusion Attack

Threat Engine Auto-Feed · data current as of 2026-10-14

A malicious npm package, 'monkey-tags-ip', was published as part of a dependency confusion campaign. It exploits misconfigurations in package resolvers to be installed instead of an intended internal package, leading to exfiltration of victim IP addresses and confirmation of internal package names.

  • Package: npm / monkey-tags-ip
  • Affected versions: > 0
  • Severity: critical
  • Reach: ~10/wk
  • Exposure: 60/100 (High)

What happened — Dependency confusion

The npm package 'monkey-tags-ip' was published by user 'conx3993' as part of a dependency confusion attack. It mimics an internal package name and uses a high version number (53.4.1) to trick package managers into installing it over a legitimate internal dependency. Upon installation, a 'preinstall' hook executes a script that contacts an attacker-controlled server, revealing the victim's public egress IP and confirming the internal package name that was targeted.

How the attack works

This attack leverages dependency confusion, where a public package repository is prioritized over an internal one for a package with the same name. When a build system or developer environment attempts to resolve a dependency, if a malicious public package has a higher version or is otherwise prioritized, it will be installed instead of the intended internal package. The malicious package then executes code during installation to exfiltrate information.

Who's exposed

Profiles most at risk

  • Organizations using the npm ecosystem with internal packages
  • Development teams whose build processes or local environments resolve dependencies from both public and private registries
  • CI/CD pipelines that pull dependencies without strict version pinning or registry configuration

Conditions that increase exposure

  • Unpinned dependency versions in package.json files (e.g., using `latest` or broad ranges)
  • Lack of a package-lock.json or yarn.lock file to ensure deterministic builds
  • Package managers configured to prioritize public registries over internal ones for name resolution
  • Internal package names that are guessable or not unique to the private scope

Blast-radius scenarios

  • An attacker successfully identifies an internal package name used by an organization.
  • The malicious 'monkey-tags-ip' package is installed instead of the intended internal package.
  • The attacker gains knowledge of the victim's public egress IP address.
  • The attacker confirms the existence and usage of a specific internal package name within the victim's environment, aiding in further targeted attacks.

What to do (defensive)

Detect

  • Review npm package logs for installations of 'monkey-tags-ip', especially unexpected versions.
  • Monitor network traffic for outbound HTTPS GET requests to 'realwbx.com' from build systems or developer machines.
  • Audit package-lock.json or yarn.lock files for unexpected entries or changes.
  • Implement software composition analysis (SCA) tools to detect known malicious packages.

Contain

  • Immediately block network access to 'realwbx.com' at the perimeter.
  • Remove 'monkey-tags-ip' from any affected environments or caches.
  • Isolate systems where 'monkey-tags-ip' was installed to prevent further potential compromise.
  • Review and update npm registry configurations to prioritize internal registries for private packages.

Remediate

  • Update all project dependencies to use strict version pinning (e.g., exact versions) and commit lock files (package-lock.json, yarn.lock).
  • Configure npm clients and build tools to scope internal packages to private registries, preventing public lookups for those names.
  • Rename sensitive internal packages to reduce predictability and collision risk.
  • Educate developers on dependency confusion risks and secure package management practices.

Frontier verdict — High

This is a critical supply-chain incident requiring immediate attention due to data exfiltration and confirmation of internal package names via dependency confusion.

Sources

For detection-engineering and awareness only · point-in-time · not security advice · sourced from the GitHub Advisory Database.