Topic starter
02/08/2026 11:28 am
TL;DR: The Miasma supply-chain worm moved install-time execution out of package.json and into binding.gyp, using command expansion, Python eval() sandbox escapes, includes, and build actions to run payloads during npm install while hiding in native-module build logic, according to Aikido. The practical lesson is that dependency review now has to treat build metadata as execution surface, not configuration noise.
Editorial analysis by NHI Mgmt Group, based on content published by Aikido: “Wait, binding.gyp Can Do What? Exploring npm's Weirdest Build System”.
Key questions
Q: What breaks when npm packages execute code through binding.gyp instead of package.json scripts?
A: Review processes break because teams often check package.json for lifecycle hooks and assume a clean manifest means a safe install.
Q: Why does install-time code execution in npm packages increase secret theft risk?
A: Because the payload runs before the developer starts the application, it can reach environment-resident secrets such as cloud credentials, CI tokens, and SSH keys.
Q: What do security teams get wrong about binding.gyp reviews?
A: They often check only the obvious fields or only the top-level file, but gyp parsing can execute commands under arbitrary keys, in included files, and through auto-loaded inputs.
Practitioner guidance
- Review native-module build paths as executable code Inspect binding.gyp, config.gypi, common.gypi, and any included files the same way you would inspect lifecycle scripts.
- Flag command expansion tokens in gyp files Block or quarantine packages that contain !(...), <!@(...), or similar parse-time execution patterns until they are validated.
- Search for embedded Python expressions in build metadata Look for eval()-style expression payloads in variables, conditions, and string values anywhere in gyp content, not only in documented fields.
Bottom line: binding.gyp creates a hidden execution path in npm installs, so package review must extend beyond package.json.
Explore further
View Full Forum → | NHI Foundation Course → | Our Services → | Read the full analysis →
02/08/2026 12:44 pm
Build metadata is now an execution surface: the article shows that dependency review which stops at package.json is structurally incomplete. Native build files can execute code at parse time, which means governance has to extend into build inputs, not just declared scripts. Practitioners should treat build metadata as part of the software supply chain trust boundary, not as passive configuration.
A question worth separating out:
Q: How should teams contain install-time execution paths in dependency workflows?
A: Use isolated install environments, block suspicious build metadata, and require deeper inspection for native packages that introduce gyp files or build actions. The goal is to keep package installation from inheriting host secrets or broad filesystem access before provenance checks complete.
👉 Read our full editorial: binding.gyp turns npm installs into code execution paths