Notifications
Clear all
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.
NHIMG editorial — based on content published by OXSecurity: OX Research found paperclip2, an npm package with no JavaScript files, hiding a reverse shell in its config file
By the numbers:
- Combined, the three packages have been downloaded 1,049 times per week.
Questions worth separating out
Q: What breaks when npm package installs are allowed to execute code before inspection?
A: The control point disappears.
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.
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.
Practitioner guidance
- 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.
- Inspect package manifests for executable behaviour Add package.json review to dependency intake checks so postinstall, preinstall, and similar hooks are visible before adoption.
- 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.
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.
👉 Read OXSecurity's analysis of paperclip2 and related npm reverse-shell packages →
Paperclip2 npm malware: what config-file payloads mean for teams?
Explore further
02/08/2026 12:40 pm
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.
A question worth separating out:
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.
👉 Read our full editorial: Paperclip2 npm malware shows how config-file payloads evade scanners
