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.
NHIMG editorial — based on content published by Aikido: Wait, binding.gyp Can Do What? Exploring npm's Weirdest Build System
Questions worth separating out
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 do native build files increase the risk of secret theft in CI and developer environments?
A: Native build files can run before application code, which gives attackers an early chance to read cloud credentials, CI tokens, SSH keys, and other secrets from the environment.
Q: How do security teams know if dependency controls are actually working?
A: Look for whether build systems prevent unauthorised version drift, whether package provenance is checked before install, and whether secret-handling code is isolated from broad application reach.
Practitioner guidance
- Treat native build files as executable surface Add binding.gyp, config.gypi, common.gypi, and included gypi files to dependency review checks, with explicit approval required for any diff that changes execution-related fields or introduces command expansion syntax.
- Block unexpected install-time execution paths Harden CI and developer workstations so npm install cannot silently execute build steps without policy checks, and flag any package that triggers node-gyp rebuild for manual inspection.
- Scan for gyp command expansion and eval abuse Search repositories and lockfiles for <!(, <!@, conditions, actions, rules, and arbitrary keys containing expansion payloads, then route matches into malware and supply-chain triage.
What's in the full article
Aikido's full blog covers the operational detail this post intentionally leaves for the source:
- Annotated examples of malicious binding.gyp payloads and the exact expansion syntax used to trigger execution.
- Deeper walkthroughs of sandbox escape techniques inside gyp parsing and where reviewers tend to miss them.
- Specific detection guidance for malware feeds and rescans when native build files are abused in npm dependencies.
- Coverage of related package-manager behaviours across npm, PyPI, and GitHub that can extend the same attack pattern.
👉 Read Aikido's analysis of binding.gyp install-time code execution in npm →
binding.gyp install-time code execution: what should teams do now?
Explore further
Build metadata is now a credential-exposure surface, not inert configuration. The article shows that attackers are moving beyond obvious lifecycle hooks and hiding execution in native build files that many teams do not inspect. That creates a broader governance problem for software supply chains, because install-time code can run before any application telemetry or endpoint policy has meaningful context. For IAM and NHI teams, the practical conclusion is that dependency ingestion is an identity event as much as a software event.
A few things that frame the scale:
- 88.5% of organisations acknowledge that their non-human IAM practices lag behind or are merely on par with their human identity and access management efforts, according to The 2024 Non-Human Identity Security Report.
- Only 19.6% of security professionals express strong confidence in their organisation's ability to securely manage non-human workload identities, according to The 2024 Non-Human Identity Security Report.
A question worth separating out:
Q: How should teams respond when a dependency may have executed during install?
A: Contain the build environment first, then assume any secrets present during the install may be compromised. Revoke and rotate cloud credentials, CI tokens, and SSH keys used in that pipeline, rebuild from trusted sources, and review package provenance before allowing the dependency back into production workflows.
👉 Read our full editorial: binding.gyp turns npm installs into code execution paths