Topic starter
18/08/2026 2:40 pm
TL;DR: Twenty npm packages published in late July and early August 2026 hid malware that executed on import, not during install, so --ignore-scripts did not block it; Xygeni’s analysis shows staged payload retrieval, endpoint-security enumeration, AMSI and ETW patching, and in-memory execution.
Editorial analysis by NHI Mgmt Group, based on content published by Xygeni: “QuietPolyfill: An NPM dropper that resurrected”.
By the numbers:
- 20 npm packages published across two days in late July and early August 2026 presented themselves as internal libraries but executed malicious code on import.
- The payload retrieved a third binary that was several megabytes in size, with examples ranging from 4.3 MB to 13.3 MB.
Key questions
Q: What breaks when malicious npm packages execute on import instead of install?
A: Install-time controls often miss import-time payloads because the malicious code lives in the published bundle and runs when the module loads.
Q: Why do scripts-only defences fail against supply-chain malware?
A: Because they assume the dangerous behaviour happens in preinstall, install, or postinstall hooks.
Q: What are the signs that an npm package may be behaving like a dropper or data exfiltration payload?
A: Common warning signs include obfuscated code, repeated package descriptions across unrelated projects, lifecycle hooks that invoke Node automatically, and outbound requests soon after install.
Practitioner guidance
- Audit package entry points for hidden execution Review package main files, index.js endings, and any bottom-of-file require patterns that invoke local modules after export declarations.
- Extend dependency policy beyond lifecycle scripts Do not rely on --ignore-scripts as a complete supply-chain control.
- Block or alert on staged binary retrieval from packages Flag JavaScript dependencies that fetch platform-specific executables, assemble hostnames at runtime, or fall back to DNS-based delivery.
Bottom line: The central failure in this case is not a missing install hook check, but a governance model that stopped at installation and ignored module import as an execution trigger.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
18/08/2026 3:25 pm
Import-time execution is now a software governance problem, not just a malware trick. Build and install controls are still necessary, but they do not address code paths that execute on module load. That creates a blind spot in software supply-chain governance because package trust is being inferred from install behaviour rather than runtime behaviour. Practitioners should treat entry-point auditing as part of supply-chain assurance, not a niche code review task.
A question worth separating out:
Q: How should security teams respond when a package suppresses telemetry and security tools?
A: Treat the package as a live compromise path, not just a bad dependency. Contain affected build and runtime hosts, preserve process and network telemetry before it is overwritten, and search for import-time execution on similar packages. Telemetry suppression means the window for reliable evidence is short, so triage has to start from the first observed import event.
👉 Read our full editorial: Import-time npm malware shows why scripts-only defences fail