Supply chain · npm · High

Malicious npm package 'app-rrhh' (v999.0.0) identified in dependency confusion attack

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

A malicious npm package, 'app-rrhh' version 999.0.0, has been identified as part of a dependency confusion attack. This package executes a preinstall script that leaks installer identity data (username and hostname) to an attacker-controlled server upon installation, confirming code execution and exposing sensitive internal information.

  • Package: npm / app-rrhh
  • Affected versions: = 999.0.0
  • Severity: critical
  • Reach: ~0/wk
  • Exposure: 60/100 (High)

What happened — Dependency confusion

The npm package 'app-rrhh' version 999.0.0 contains malicious code. Specifically, its `package.json` includes a `preinstall` script. When `npm install` is run, this script executes a `curl` command. This command sends the installer's operating system username and hostname over plaintext HTTP to a Burp Collaborator subdomain, `ebtld4p8aq3rl950g6jgn217aygp4fs4.oastify.com`. This action confirms code execution on the installing host and leaks installer identity data to an attacker-controlled destination. The package's name, version, and description are consistent with a dependency confusion attack designed to prioritize this public malicious package over a private internal package of the same name.

How the attack works

This is a dependency confusion attack. Attackers publish a public package with the same name as a private internal package used by an organization, often with a higher version number. When a build system or developer environment attempts to resolve the dependency, it might inadvertently pull the malicious public package instead of the intended private one. In this instance, the malicious package executes a script during installation, establishing an outbound connection to an attacker-controlled server and exfiltrating system information.

Who's exposed

Profiles most at risk

  • Development teams using the npm ecosystem
  • Organizations with private npm packages that might share names with public packages
  • CI/CD pipelines configured to pull dependencies without strict version pinning or registry scoping

Conditions that increase exposure

  • Unpinned dependencies in `package.json` that allow resolution to higher versions
  • Lack of a `package-lock.json` or equivalent lockfile to ensure consistent dependency resolution
  • Build environments or developer machines configured to query public npm registries before or in parallel with private registries
  • Internal package names that are not unique and could be mimicked on public registries

Blast-radius scenarios

  • If the package is installed, an attacker confirms code execution on the host and obtains the installer's username and hostname, which could be used for further reconnaissance or targeted attacks.
  • The blast radius includes any system (developer workstation, CI/CD runner, server) where this malicious package is installed, potentially leading to initial access or information leakage.

What to do (defensive)

Detect

  • Scan `package.json` files for `app-rrhh` version `999.0.0`.
  • Monitor network traffic for outbound connections to `ebtld4p8aq3rl950g6jgn217aygp4fs4.oastify.com` or other Burp Collaborator domains during dependency installation.
  • Review `npm install` logs for execution of unexpected `preinstall` scripts or `curl` commands.
  • Implement software composition analysis (SCA) tools to identify known malicious packages in your dependency tree.

Contain

  • Block network access to `ebtld4p8aq3rl950g6jgn217aygp4fs4.oastify.com` at the firewall or proxy level.
  • Configure npm to use a private registry exclusively, or scope public registry access to prevent dependency confusion.
  • Ensure all internal package names are unique and not published to public registries.
  • Isolate build environments to prevent exfiltration or lateral movement if a malicious package is installed.

Remediate

  • Immediately remove `app-rrhh` version `999.0.0` from all projects and environments.
  • Update `package.json` files to pin exact versions of all dependencies, especially for internal packages.
  • Utilize `package-lock.json` or `npm-shrinkwrap.json` to ensure deterministic dependency resolution.
  • Audit all systems where `app-rrhh` version `999.0.0` may have been installed for signs of compromise or further malicious activity, assuming the leaked identity data could be used for follow-on attacks.

Frontier verdict — High

Prioritize immediate removal of 'app-rrhh' v999.0.0 and implement robust dependency resolution controls to mitigate critical dependency confusion risks.

Sources

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