Malicious npm packages now hide malware in image payloads

At a glance

What this is: Veracode describes a malicious npm package that used install-time execution and hidden PNG payloads to deliver malware while evading detection.

Why it matters: It matters because package trust, script execution, and developer workstation controls now form part of the identity and supply-chain control plane, not just endpoint hygiene.

By the numbers:

• The batch file was 1,653 lines long, but only about 21 lines actually did anything.

Context

Malicious npm packages are increasingly less about a single obvious payload and more about chained abuse of package installation, script execution, hidden staging, and defensive evasion. In this case, the security gap is not just malware scanning, but the assumption that package contents and install-time behaviour are easy to inspect before execution. The identity angle is real because developer trust in package provenance and automated execution still determines what code is allowed to run inside the software supply chain.

The package used a postinstall hook to trigger code during npm install, then fetched additional content from external infrastructure and hid payloads inside image files. That pattern matters to IAM and NHI practitioners because software delivery pipelines rely on service credentials, build automation, and trusted package identities, all of which can be abused when provenance and lifecycle controls are weak.

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. That breaks the assumption that package trust equals install safety. Teams need to treat lifecycle execution as a privilege boundary and restrict scripts that are not essential to the build.

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. If the decoder is embedded in the install chain, the image becomes a transport layer for staged malware, and the real risk sits in the retrieval and execution path rather than the file type itself.

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. If a package writes batch or PowerShell files, fetches remote content, renames payloads, or removes traces immediately after execution, security teams should treat it as an active malware delivery chain rather than routine dependency behavior.

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.

Technical breakdown

How postinstall hooks turn package install into code execution

In npm, a postinstall hook runs automatically after a package is installed. That means the package does not need to contain a large obvious payload to be dangerous, because the install step itself becomes the execution point. Attackers use this to shift malicious logic into scripts that look routine, especially when package names resemble dormant or legitimate projects. The control failure is not just detection, but treating installation as a low-risk action when it is actually a privileged execution boundary.

Practical implication: Treat package installation as an execution event and restrict script execution in build and developer environments.

Why image steganography defeats superficial malware inspection

Steganography hides data inside the pixel values of an image so the file still looks harmless to standard viewers. In this campaign, the image was not a picture in the normal sense but a carrier for encrypted payload bytes encoded across pixels. That matters because many controls are tuned to inspect executables, macros, or obvious script blobs, not PNGs retrieved from a benign-looking hosting service. Once the decoder knows the extraction scheme, the image becomes an encrypted transport layer for second-stage code.

Practical implication: Inspect outbound image downloads from build and endpoint environments when those images are retrieved by scripts or package hooks.

How AV-aware branching and AMSI bypasses reshape the detection problem

The malware does not use one fixed loader path. It checks for antivirus products, then chooses different payloads and bypass logic, including AMSI suppression and process hollowing. That combination matters because it turns the campaign into an environment-aware delivery chain, where the payload adapts to what security products are present. In practice, this undermines a detection model that assumes one malicious binary will behave consistently across hosts.

Practical implication: Correlate package-install telemetry with AMSI tampering, suspicious process creation, and antivirus-specific branching behaviour.

Threat narrative

Attacker objective: The attacker aims to execute a stealthy remote access payload on developer or build hosts while avoiding package inspection and endpoint detection.

1. Entry occurs through a typosquatted npm package that runs a postinstall hook when a developer installs it.
2. Credential and environment checks steer the malware into different paths, including privilege escalation through a known UAC bypass and AV-specific evasion.
3. The loader fetches steganographic PNGs from external hosting, extracts encrypted payloads, and uses process hollowing plus AMSI bypasses to run the final RAT.
4. Impact is remote control of the victim host, with persistence and staged payload delivery designed to survive basic inspection and response.

Breaches seen in the wild

• eslint-scope npm compromise 2018: A reused maintainer password let an attacker publish eslint-scope 3.7.2, which stole npm tokens from .npmrc files; npm revoked tokens across the registry.
• Rspack npm compromise 2024: A compromised npm token let an attacker publish Rspack 1.1.7 with a postinstall cryptominer that also sent cloud credentials out.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

Hidden payload delivery is now a control-surface expansion problem: the campaign shows how attackers move from obvious executables into image files, hosted content, and layered unpacking. That matters because security teams that only classify obvious binary artefacts miss the real attack boundary, which is the chain of retrieval, decoding, and execution. The named concept here is image-carried payload staging, and it should be treated as a software supply-chain abuse pattern, not a file-format curiosity. Practitioners need controls that cover content origin, script-triggered downloads, and stage separation.

AMSI bypass is no longer a single technique but a resilience pattern: the malware stacks multiple bypass paths, meaning defenders cannot rely on one inspection layer to fail closed. This is the operational lesson for broader cyber governance: when adversaries diversify execution paths, controls must be resilient across environment checks, runtime tampering, and post-install execution. In identity terms, the attacker is exploiting the trust boundary between package identity, host privilege, and runtime permission. Practitioners should assume layered evasion rather than single-vector detection.

Developer tooling now sits inside the blast radius of NHI governance: build systems, package managers, and automation runners use credentials, tokens, and delegated access to fetch, install, and publish software. When a malicious package abuses that trust path, the exposure is not just a compromised endpoint, but a compromised software delivery identity. That makes ownership, offboarding, and policy enforcement for non-human actors a governance issue. Practitioners should map package installation, CI execution, and secret exposure to the same control thinking they apply to other privileged machine identities.

What this signals

Image-carried payload staging: the article shows why defenders need to treat unusual image downloads during package installation as a supply-chain indicator, not a harmless artifact. When retrieval and decoding are embedded in a lifecycle hook, the control point moves from malware signature detection to provenance and execution policy.

Package managers now sit on the same trust boundary as other delegated automation, which means non-human identity governance has to cover build agents, install hooks, and dependency provenance together. When that boundary is weak, a package can behave like a credentialed actor with permission to pull and run code.

Security teams should expect adversaries to combine typosquatting, runtime evasion, and staged payload delivery in one chain, because single-control detection is no longer enough. The practical response is to narrow execution rights, validate package origin, and watch for anomalous install-time network activity.

For practitioners

• 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.
• Apply software supply-chain policy controls Use package allowlists, provenance checks, and dependency review gates so dormant or typosquatted packages cannot execute unchecked in the delivery pipeline.

Key takeaways

• The core problem is not just malicious code inside a package, but the assumption that installation itself is a safe moment for execution.
• The article shows a staged chain that uses postinstall execution, hidden PNG payloads, and runtime evasion to deliver a RAT.
• The control that matters most is governed package execution, supported by provenance checks, install-time policy, and telemetry on suspicious downloads.

Key terms

• Preinstall Hook: A preinstall hook is package code that runs before an application installs or starts. In supply-chain attacks, it becomes a hidden execution point that can steal secrets, alter environments, or drop further payloads before normal controls see the package's behaviour.
• Network Steganography: Network steganography hides information inside network traffic instead of inside a static file. Attackers use subtle changes in protocol fields, timing, or packet behavior to smuggle data without obvious signs of transmission. This makes detection harder because the message is dispersed across ordinary communications.
• Process hollowing: Process hollowing is a method where malicious code is placed into a legitimate process after that process is started in a suspended state. The original binary remains present, but its memory is replaced with attacker code, which helps hide the malware from basic file-centric defenses and simple reputation checks.
• AMSI Bypass: An AMSI bypass is any method used to prevent Anti-malware Scan Interface inspection from seeing script or in-memory content. Attackers may patch memory, alter return values, or interrupt scanning logic so later payload stages execute without the usual endpoint scrutiny.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is designed for practitioners who need to govern delegated access, automation, and trust boundaries across modern security programmes.