Paperclip2 npm malware shows how config-file payloads evade scanners

At a glance

What this is: This is an analysis of a malicious npm package chain that hid reverse-shell code in package metadata and related packages, showing how postinstall scripts can turn harmless-looking dependencies into execution vectors.

Why it matters: It matters because software supply chain controls, package review, and runtime monitoring all need to account for non-code payloads, especially where build and install paths can execute hidden commands.

By the numbers:

• Combined, the three packages have been downloaded 1,049 times per week.

👉 Read OXSecurity's analysis of paperclip2 and related npm reverse-shell packages

Context

The core issue here is software supply chain abuse through package metadata rather than source code. A package can look inert to a scanner because it contains no JavaScript files, yet still execute commands during installation through scripts embedded in package.json. That gap matters to application security, DevSecOps, and identity teams because build systems and package registries often hold long-lived credentials and privileged access that attackers can reach through compromised dependencies.

For identity programmes, this is a reminder that non-human identities are part of the supply chain too. CI/CD runners, package managers, and automation accounts frequently have the access needed to fetch dependencies, publish artifacts, and touch production environments, so an apparently small dependency compromise can become an access problem as much as a malware problem.

Key questions

Q: What breaks when npm package installs are allowed to execute code before inspection?

A: The control point disappears. If install-time code can run before review, malware can harvest secrets, alter workflows, and propagate before defenders see a stable artifact. That makes preinstall hooks an execution surface, not a packaging detail. Teams should assume installation is a potential compromise event and enforce policy before code reaches that stage.

Q: Why do automated build identities increase supply chain compromise risk?

A: Automated build identities often have access to package registries, repositories, and secrets that were granted for delivery efficiency, not for adversarial resilience. When one of those identities is compromised through a poisoned dependency, attackers can move from execution to credential theft and workflow persistence without needing a second exploit.

Q: How do security teams detect malicious npm postinstall behaviour?

A: Look for packages that define lifecycle hooks, then correlate installs with unexpected child processes, shell spawning, and outbound connections from build hosts. Detection should focus on behaviour during installation, not just signature matches on known malware. A package that looks empty can still be dangerous if it executes commands on install.

Q: Should organisations trust package popularity when approving dependencies?

A: No. Download counts and apparent legitimacy do not prevent malicious install-time behaviour. A dependency can be widely installed and still contain a hidden payload in package metadata. Approval should depend on package behaviour, maintainer trust, provenance checks, and whether the install path is allowed to execute scripts.

Technical breakdown

How postinstall scripts turn npm packages into execution paths

npm packages can include lifecycle hooks such as postinstall, which run automatically when a package is installed. That makes installation a trusted execution point, even if the package itself contains no application code. In this case, the malicious package used only package.json, with the payload concealed in metadata instead of JavaScript files. Security tools that rely on file type, static code signatures, or known malicious source patterns can miss this because the dangerous behaviour occurs at install time, not in a conventional code path.

Practical implication: inspect package lifecycle scripts, not just source files, before allowing dependencies into build pipelines.

Why reverse shells in dependency packages are hard to spot

A reverse shell creates outbound communication from the compromised host to an attacker-controlled system, which can slip past controls that focus on inbound traffic. Here the package connected to 185.112.147.174 on port 7007 and then spawned a shell. That combination gives the attacker an interactive foothold on the system that performed the install. Because the payload lives in a package script, the exploit may execute before EDR, sandboxing, or human review has a chance to inspect the dependency in a normal application context.

Practical implication: monitor outbound connections and child process creation during installs, especially from build and CI hosts.

Why package metadata is a supply chain control point

Package metadata is not administrative decoration. It is executable policy in many language ecosystems because scripts, dependencies, and install behaviours can all be triggered automatically. The fact that paperclip2 had no JavaScript files shows why content-based trust models fail when packages can still execute commands through metadata. Related packages reusing the same postinstall one-liner also show how attackers scale a payload across multiple names to increase reach and evade simple blacklist checks.

Practical implication: treat package manifests as execution-bearing artifacts and govern them with the same scrutiny as application code.

Threat narrative

Attacker objective: The attacker wanted interactive remote access to the installing system so they could extend control beyond the dependency installation event.

1. Entry occurred when a developer or build system installed the malicious npm package, triggering its postinstall script automatically.
2. Credential or process abuse followed as the package spawned a reverse shell from the host to the attacker-controlled IP address on port 7007.
3. Impact was remote command execution on the system performing the install, creating a foothold for further compromise of build or deployment environments.

NHI Mgmt Group analysis

Config-file payloads create a packaging blind spot: security teams still over-index on source files when judging dependency risk. A package with no JavaScript can still execute arbitrary code through lifecycle hooks, which means code review and malware scanning must extend to manifests and install logic. The practical conclusion is that package trust should be based on behaviour, not file extension.

Reverse shells in install scripts turn dependency intake into execution: once install-time code runs, the boundary between software acquisition and system compromise disappears. That matters in CI/CD, where automation identities often have broad access to repositories, artifact stores, and deployment targets. Teams should treat package installation as a privileged action, not a routine housekeeping step.

Supply chain abuse now overlaps with NHI governance: build agents, package managers, and pipeline service accounts are non-human identities with real authority, and attackers target them because they can execute or relay compromise quickly. This strengthens the case for least privilege, egress monitoring, and lifecycle control over automation credentials. The governance lesson is to manage the identities that install software as tightly as the software itself.

Dependency trust is becoming a runtime security problem, not just a provenance problem: package reputation and download volume do not prevent malicious postinstall behaviour. That shifts the control question from “is this package known?” to “what can this package do when installed?” The practical conclusion is that software admission, process monitoring, and secret protection need to operate together.

What this signals

Package install abuse should be treated as an identity-adjacent control problem: software pipelines rely on non-human identities that often have broader access than the packages they ingest. The practical shift is to govern those identities with the same rigour applied to production service accounts, including least privilege, egress control, and behavioural monitoring.

Dependency admission is moving closer to runtime authorisation: organisations can no longer assume that a safe-looking package remains inert after approval. The question is whether your pipeline can observe and stop unexpected execution at install time, before a compromised dependency inherits privileged access to build or deploy systems.

The governance gap is not just malware detection. It is the absence of lifecycle control over automation credentials that can turn a single malicious package into a trusted execution event, which is why identity and supply chain controls now need to be designed together.

For practitioners

• Block install-time script execution where possible Disable or tightly control lifecycle scripts in dependency installation workflows, especially on CI runners and build hosts that can reach sensitive systems. Review exceptions separately for trusted packages and keep an allowlist of approved install behaviours.
• Inspect package manifests for executable behaviour Add package.json review to dependency intake checks so postinstall, preinstall, and similar hooks are visible before adoption. Flag packages that contain no code files but still define install-time actions.
• Monitor outbound connections from build environments Watch for unexpected connections to unknown IPs and unusual ports, including port 7007 in this case, and correlate them with child process creation during dependency installs. Treat outbound reverse-shell patterns as a high-severity signal.
• Restrict privilege on pipeline and automation identities Limit what CI/CD service accounts, package managers, and deployment runners can access after a dependency is installed. Separate artifact ingestion from production access so a malicious package cannot inherit broad environment privilege.

Key takeaways

• Malicious npm packages can execute without shipping obvious source code, which means metadata and lifecycle hooks are part of the attack surface.
• Install-time reverse shells turn dependency intake into a system compromise path, especially on build and CI/CD hosts with privileged access.
• The right control set combines manifest review, install-script restrictions, outbound monitoring, and tighter governance over automation identities.

Key terms

• Postinstall Script: A package lifecycle hook that runs automatically after installation. It is useful for legitimate setup tasks, but it also creates an execution path that can be abused to run malicious code as soon as a dependency is installed.
• 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.
• Software Supply Chain Attack: A software supply chain attack targets the path software takes from source code to production. The attacker corrupts code, dependencies, build steps, or artifacts so that trusted delivery mechanisms spread malicious logic into environments that would otherwise reject direct intrusion.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

What's in the full analysis

OXSecurity's full article covers the operational detail this post intentionally leaves for the source:

• The exact package names, affected versions, and how the malicious postinstall script was embedded in package metadata.
• The observed network destination and process behaviour that exposed the reverse-shell activity during installation.
• The package-lock and package.json hygiene steps practitioners can use to remove affected dependencies from environments.
• The OX Research analysis of why the lack of JavaScript files may have reduced detection by code-focused scanners.

👉 OXSecurity's full article covers the package details, payload behaviour, and immediate containment steps

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity controls to the operational reality of modern security programmes.