Paperclip2 npm malware shows how config-file payloads evade scanners

At a glance

What this is: OXSecurity found a malicious npm package that hid a reverse shell in package.json, not JavaScript, alongside two related packages carrying the same postinstall payload.

Why it matters: This matters because dependency review, malware scanning, and software supply chain controls that focus only on executable code can miss config-file payloads and install-time abuse.

Context

The core governance gap here is that package review processes often assume malicious code will appear in obvious executable files. When attackers place payloads in package.json and trigger them through postinstall scripts, tools that scan source code but not installation behaviour can miss the abuse.

This is a supply chain and execution-path problem as much as a malware problem. For teams managing software integrity, the relevant question is whether package intake, lockfile review, and install-script inspection are all part of the control boundary, not just static code scanning.

Key questions

Q: What breaks when npm packages hide payloads in package.json instead of JavaScript?

A: Static scanning becomes unreliable because the package can appear empty or low risk while still executing commands during installation. Security teams need to treat package manifests as executable surfaces and inspect lifecycle hooks, not just source files, or malicious dependencies will slip past controls that assume code is the only thing that matters.

Q: Why do install scripts create such a large supply chain risk?

A: They turn package installation into code execution, often inside environments that contain secrets and elevated build privileges. A compromised dependency does not need to alter application logic to cause damage. It only needs one automatic execution opportunity to steal credentials, stage malware, or spread through transitive packages.

Q: What are the signs that a dependency is abusing postinstall hooks?

A: Look for packages with no meaningful source files, unusual lifecycle entries in package.json, outbound connections during installation, and processes that appear immediately after dependency resolution. Repeated payloads across related package names are another indicator that the malicious behaviour is being reused for broader delivery rather than isolated in one release.

Q: Should teams compare package reputation with install-time behaviour or only one of them?

A: They need both. Package reputation can help prioritise review, but install-time behaviour determines whether a dependency can execute code, reach external systems, or launch shells. A package with a clean reputation but hidden postinstall commands still represents execution risk and should not be treated as benign without verification.

Technical breakdown

How postinstall scripts turn harmless-looking packages into execution

In npm, package.json is not just metadata. It can define lifecycle scripts such as postinstall, which run automatically after dependency installation. That means a package can contain no JavaScript source at all and still execute code during install. In this case, the malicious behaviour sits in a one-line postinstall command, so the package can look inert to scanners that focus on .js files, yet still trigger network access and shell execution when installed. The technical risk is not the file type, but the execution path created by the package manager.

Practical implication: Treat lifecycle scripts as executable content and inspect them before allowing packages into build or runtime pipelines.

Why config-file payloads evade code-focused scanning

Security tooling often classifies risk by file extension, language syntax, or obvious code patterns. That works poorly when the malicious payload is embedded in configuration or metadata files that the package manager interprets as instructions. package.json can define commands, dependencies, and install-time behaviour, so it becomes part of the attack surface. If a control only parses source files and misses install scripts, the package can evade detection while still achieving code execution. This is a software supply chain integrity issue, not just a malware-signature issue.

Practical implication: Extend scanning and policy checks to package metadata, install hooks, and dependency manifests, not only source files.

Why repeated payloads across related packages raise supply chain risk

The article notes that two related packages reused the same reverse shell one-liner. That pattern suggests the malicious behaviour is being replicated across package names rather than tied to a single compromised release. For defenders, this matters because one bad package name is rarely the whole story. Malicious actors often distribute the same payload through multiple package identities to widen exposure and reduce the chance that a single takedown fully removes the threat. Inventory and detection therefore need package-family visibility, not just per-package alerts.

Practical implication: Correlate package names, scripts, and maintainers so one payload does not survive under multiple dependency identities.

Threat narrative

Attacker objective: Gain remote shell access from the victim environment and use that foothold to control the host or harvest accessible secrets.

1. Entry occurs when a developer or build pipeline installs a malicious npm package that appears to contain only configuration data.
2. The package uses a postinstall script in package.json to execute a reverse shell and connect out to the attacker-controlled host on port 7007.
3. The same payload appears in two related packages, broadening distribution and increasing the chance of execution across multiple environments.
4. The objective is remote command execution from the victim system with follow-on control over the host and any accessible secrets or build assets.

Breaches seen in the wild

• 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.
• 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.

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

Config-file payloads create a blind spot in software supply chain defence: defenders often equate malware inspection with source-code inspection, but package managers can execute instructions embedded in metadata. When the package manager, not the code reviewer, becomes the interpreter, the control boundary has to move earlier in the intake path. Practitioners should treat package manifests as executable policy surfaces, not passive metadata.

The relevant failure mode is package trust without install-time governance: the article shows that a package can look empty, yet still trigger a shell during installation. That means allowlisting package names alone is insufficient if install hooks are uncontrolled. Teams need governance that binds dependency approval to lifecycle behaviour, not just package reputation.

Supply chain review must include identity-like package provenance, not only content inspection: repeated malicious payloads across related packages show how attackers reuse distribution channels to preserve access. In governance terms, the package name is not the trust anchor if the install script can change the execution outcome. Practitioners should verify provenance, maintainers, and script behaviour as a single control plane.

Install-script abuse is now a practical control-design problem, not a niche malware trick: package ecosystems reward automation, but automation also amplifies hidden execution. The right response is to assume that dependency intake may contain non-obvious execution paths and to align software supply chain controls with that reality. For security teams, the implication is to govern package behaviour, not just package presence.

What this signals

Config-file execution is now a mainstream supply chain concern: when package managers interpret metadata as instructions, the distinction between code and configuration stops being a reliable control boundary. Teams that still anchor malware review on file extensions are defending the wrong layer.

Package provenance and install behaviour need to be governed together: dependency approval should bind maintainer trust, lockfile integrity, and lifecycle-script inspection into one decision. The practical shift is from content-only scanning to behaviour-aware intake controls.

For practitioners

• Inspect package lifecycle scripts before approval Review package.json for postinstall, preinstall, and install hooks and block dependencies that execute network or shell commands unless explicitly required.
• Scan lockfiles and manifests for named malicious packages Search package-lock.json and package.json for paperclip2, vps-maintenance, and vps-maintenance-paperclip-adapter, then remove any references and reinstall from a clean dependency baseline.
• Monitor for suspicious outbound connections on port 7007 Hunt for processes opening unexpected connections to 185.112.147.174 on port 7007 and terminate the underlying process if found.
• Gate dependencies on script behaviour and provenance Require package review controls that consider maintainer history, install hooks, and dependency provenance before packages are promoted into build pipelines.

Key takeaways

• The article shows that malicious npm activity can hide in package metadata and still execute at install time, which breaks scanner assumptions built around source code.
• The reused reverse shell payload across related packages indicates a distribution pattern, not just a single bad release, which increases the chance of exposure across environments.
• Teams should move supply chain controls toward install-script review, lockfile hygiene, and outbound connection monitoring so hidden execution paths are caught earlier.

Key terms

• Package Lifecycle Script: A package lifecycle script is code embedded in package metadata that runs at defined stages such as install, publish, or test. These scripts are useful for automation, but they also expand attack surface because malicious authors can use them to execute code, collect environment data, or reach external services.
• Config-File Payload: A config-file payload is malicious behaviour hidden inside a file normally treated as metadata or configuration rather than source code. Attackers use this pattern to evade scanners that focus on executable files, while still influencing package managers or build tools that interpret the file as instructions.
• Supply Chain Abuse: Supply chain abuse is the misuse of trusted third-party software, services, or dependencies to gain unauthorized access or distribute malicious activity. It exploits inherited trust across vendors, code libraries, update channels, or managed services, allowing attackers to reach targets indirectly through a weaker link in the delivery chain.
• Reverse Shell: A reverse shell is a connection initiated by the victim system back to an attacker-controlled host, giving the attacker interactive command access. It is especially dangerous in build and automation environments because it can bypass inbound filtering and look like ordinary outbound traffic.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, workload identity, and secrets management for practitioners who need to connect identity controls to broader security programmes. It gives security and identity teams a common foundation for governing non-human access across modern environments.