Topic starter
02/08/2026 11:22 am
TL;DR: A malicious npm package named paperclip2 hid a reverse shell in package.json rather than JavaScript, while two related packages reused the same postinstall payload, according to OXSecurity. The case shows how dependency and package-script abuse can bypass scanners that focus on executable code, not configuration files.
Editorial analysis by NHI Mgmt Group, based on content published by OXSecurity: “Malware Detected: Reverse Shell Without JavaScript Files in npm”.
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.
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.
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.
Practitioner guidance
- 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.
Bottom line: 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.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:40 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Paperclip2 npm malware shows how config-file payloads evade scanners