Topic starter
02/08/2026 11:59 am
TL;DR: A malicious npm package used install-time execution, registry-based privilege escalation, steganographic PNG payloads, and AV-aware branching to deliver a Pulsar RAT, according to Veracode Threat Research. Hidden payload delivery is now a supply-chain and identity governance problem, because developer trust in packages and script execution still outpaces control coverage.
Editorial analysis by NHI Mgmt Group, based on content published by Veracode: “Hiding in Plain Pixels: Malicious NPM Package Found”.
By the numbers:
- The batch file was 1,653 lines long, but only about 21 lines actually did anything.
Key questions
Q: What breaks when npm package installation is allowed to execute lifecycle scripts by default?
A: A malicious dependency can run code before installation completes, which turns normal package resolution into a payload delivery mechanism.
Q: Why do hidden payloads in image files evade normal supply-chain controls?
A: Because many controls inspect obvious executables and scripts, not PNGs or other benign-looking content retrieved during installation.
Q: What are the signs that a malicious npm package is trying to hide its execution and remove evidence?
A: Common signs include preinstall scripts, temporary drop files, script names that mirror legitimate package files, silent execution flags, and cleanup routines that delete artifacts after use.
Practitioner guidance
- Restrict install-time script execution Block or tightly control npm lifecycle scripts in developer and CI environments, especially postinstall hooks that can execute before code review or signing checks.
- Detect package-driven outbound downloads Alert on package install processes that fetch external images, archives, or executables from file-sharing and image-hosting domains.
- Harden build and developer host telemetry Monitor for AMSI tampering, suspicious conhost or powershell invocation, registry-based UAC bypass attempts, and process hollowing indicators.
Bottom line: The core problem is not just malicious code inside a package, but the assumption that installation itself is a safe moment for execution.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 1:06 pm
Package trust has become an identity problem, not only a software integrity problem: the decisive control gap is the assumption that a package can be trusted once its name looks plausible. When install-time code can run before human review, the package itself behaves like an ephemeral non-human identity with delegated execution rights. That makes provenance, lifecycle control, and script policy part of identity governance, not an adjacent concern. Practitioners should treat package trust as a governed authorization decision.
A question worth separating out:
Q: Why do native build files increase the risk of secret theft in CI and developer environments?
A: Native build files can run before application code, which gives attackers an early chance to read cloud credentials, CI tokens, SSH keys, and other secrets from the environment. Those secrets are often long-lived or over-scoped, so one malicious install can become a platform-wide identity event. The risk is highest where build agents share credentials across projects.
👉 Read our full editorial: Malicious npm packages now hide malware in image payloads