Supply chain · npm · High
Malicious npm Package `@dransay/feature-flags` Leaks IP During Install
Threat Engine Auto-Feed · data current as of 2026-10-08
A malicious version of the npm package `@dransay/feature-flags` (99.0.0) was published to the public registry. This package includes a `preinstall` hook that leaks the installer's public IP address and a timestamp to a third-party server, indicating potential compromise or reconnaissance against build environments.
- Package: npm / @dransay/feature-flags
- Affected versions: = 99.0.0
- Severity: critical
- Reach: unknown
- Exposure: 65/100 (High)
What happened — Malicious package
The npm package `@dransay/feature-flags` version 99.0.0 was published to the public npm registry. This version contains a `preinstall` script that executes `beacon.js`, which performs a DNS lookup and HTTPS GET request to a hardcoded external domain. This action leaks the installer's public IP address and a timestamp to an out-of-band interaction collector.
How the attack works
This is a malicious package attack leveraging a preinstall hook. When the package is installed, the hook automatically executes a script. This script then initiates network communication to an external server, exfiltrating system information (in this case, the public IP and a timestamp) without requiring the package's main functionality to be imported or run.
Who's exposed
Profiles most at risk
- Development teams using the npm ecosystem, particularly those with internal `@dransay/*` scoped packages.
- CI/CD pipelines that resolve npm dependencies from the public registry.
- Any environment where `npm install` is executed for projects that may inadvertently pull in this specific package version.
Conditions that increase exposure
- Unpinned dependencies or reliance on `latest` tags for `@dransay/feature-flags`.
- Lack of a package-lock.json or similar lockfile to ensure deterministic dependency resolution.
- npm configurations that prioritize the public registry over internal mirrors for scoped packages.
- Build environments that allow outbound network connections during dependency installation.
Blast-radius scenarios
- An attacker gains reconnaissance information (public IP, timestamp) about the build environment where the package was installed.
- Confirmation that a specific internal scoped package name is being resolved from the public registry, potentially indicating a misconfiguration or supply chain vulnerability.
- The leaked IP could be used for further targeted attacks or to map an organization's infrastructure.
What to do (defensive)
Detect
- Scan `package.json` files for `@dransay/feature-flags` version 99.0.0.
- Monitor network traffic during `npm install` for outbound connections to `db3klhbi6i9hark1kegg174t38h33b6wt.oast.site`.
- Review npm logs for `preinstall` script execution related to `@dransay/feature-flags`.
Contain
- Block network access to `db3klhbi6i9hark1kegg174t38h33b6wt.oast.site` at the firewall or proxy level for build environments.
- Configure npm to use a private registry or mirror for all `@dransay/*` scoped packages, ensuring public resolution is not possible.
- Implement strict package integrity checks and lockfiles (e.g., `package-lock.json`) to prevent unexpected version resolution.
Remediate
- Immediately remove `@dransay/feature-flags` version 99.0.0 from all project dependencies.
- Audit all build environments and developer machines for installations of the affected package.
- Force a cache clear for npm (`npm cache clean --force`) and reinstall dependencies after removing the malicious package.
- Review and strengthen npm configuration to prevent resolution of internal-scoped packages from public registries.
Frontier verdict — High
Prioritize immediate removal of `@dransay/feature-flags` v99.0.0 and harden npm configurations to prevent IP leakage and supply chain reconnaissance.
Sources
For detection-engineering and awareness only · point-in-time · not security advice · sourced from the GitHub Advisory Database.