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

Why package.json Is Part of the Attack Surface

When payloads move into package.json, the trust model changes: the manifest is no longer just metadata, it can influence installation behaviour, dependency resolution, and lifecycle execution. That matters because many controls still assume executable risk lives in JavaScript source, while package managers can run preinstall, install, and postinstall hooks before a human ever inspects the code.

The practical consequence is that a benign-looking package can carry operational behaviour that only appears during install time. Security review has to include the manifest, script fields, and dependency graph together, because a package can look small, sparse, or empty and still trigger commands that fetch content, drop files, or call out to external infrastructure.

That shift also changes what “static scanning” means. A scanner that only parses JavaScript will miss payloads encoded as lifecycle actions, nested metadata, or indirection through scripts and dependencies. For defenders, the real object under review is the whole installable artifact, not just the source tree.

What Breaks in Static Analysis and Allowlisting

Manifest-hiding breaks assumptions in software composition analysis, malware scanning, and package allowlisting. If a control judges risk by source-file inspection alone, it can under-classify a malicious dependency as low risk because the visible application logic is minimal or absent.

It also weakens rules that rely on path-based review, file-type filters, or “no suspicious code found” verdicts. In a package ecosystem, the important behaviour may be expressed as install hooks, scripts, or metadata-driven actions that execute before the application’s own JavaScript is loaded. That means reviewers need to evaluate the package lifecycle, not just the runtime code path.

This is why supply-chain attacks keep succeeding through package registries: the attacker is not always trying to hide complex malware, only enough automation to make the package useful once installed. Once that happens, the initial trust decision has already been made.

How Defenders Should Reframe Package Review

Teams should treat package manifests as executable surfaces and inspect them with the same suspicion they apply to code that runs at build or install time. That includes reviewing script fields, installation hooks, unusual dependency changes, and packages that declare very little logic but still demand broad access during setup.

In practice, the question is not “does this package contain obvious JavaScript malware?” but “what will execute when this package is installed, built, or updated?” That distinction matters because the malicious behaviour may never exist in a source file that a standard code review is likely to open first.

Reviewing manifests also helps defenders catch patterns such as dependency confusion, typosquatting, and repackaged legitimate libraries with altered install behaviour. Those cases often evade shallow controls because the package name, README, or visible code looks credible while the install path does the damage.

Risk and Threat Considerations

This technique is attractive because it exploits a blind spot in review workflows: teams often inspect application code more carefully than they inspect package metadata and lifecycle scripts. That creates a reliable path for credential theft, data exfiltration, and secondary malware delivery during installation.

Failure mechanism: The attacker places malicious behaviour in manifest-driven hooks or metadata so it executes before source-level controls, sandbox assumptions, or human review notice that anything dangerous is present.

Impact: The package can gain execution on developer endpoints or build systems, steal secrets, poison downstream builds, or persist through trusted dependency updates while appearing low risk to controls that only score visible code.

Practitioner Guidance

What to verify: Confirm that package review includes package.json script fields, install-time hooks, and dependency diffs, not just source scanning. If a package declares little or no application logic but still runs commands during install, treat that as a review trigger rather than a convenience feature.

Decision rule: If the manifest can cause execution, classify it as part of the trusted computing base for that package. If your pipeline cannot inspect or constrain that behaviour, reduce trust in the package or gate it behind stronger sandboxing and approval.

Practitioner takeaway: The main mistake is assuming executable risk only lives in visible JavaScript; in npm ecosystems, the manifest itself can be the delivery mechanism, so defenders need lifecycle-aware controls, not source-only inspection.

Related resources from NHI Mgmt Group

• What breaks when npm packages execute code through binding.gyp instead of package.json scripts?
• How should teams reduce risk from malicious npm package installs?
• What breaks when malicious npm packages execute on import instead of install?
• What breaks when npm packages hide malicious logic until runtime?