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.
At a glance
What this is: Aikido explains that binding.gyp can become an install-time execution path in npm packages, letting malicious code run before a developer executes any application code.
Why it matters: This matters because package reviews that only inspect package.json can miss build-time execution paths, leaving cloud credentials, CI tokens, SSH keys, and other secrets exposed during dependency installation.
Context
binding.gyp is a native-module build file, but in npm ecosystems it can behave like an execution surface rather than a passive configuration artifact. The security gap is that review processes often focus on package.json lifecycle hooks and miss build metadata that npm will still process at install time.
For IAM and NHI practitioners, that matters because install-time execution can reach cloud credentials, CI tokens, SSH keys, and other secrets before any application logic runs. The governance problem is not just malicious code in a package, but hidden runtime authority inside the build path that conventional dependency checks may not inspect.
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. binding.gyp can trigger code during native builds, so the real execution path lives in the build toolchain. That means scanners, approvals, and CI policy have to inspect build metadata as well as scripts.
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. That makes the installation step a credential exposure window, especially on build hosts and developer workstations where secrets are already present.
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. Effective review has to follow the full inclusion and expansion chain, not just the manifest a human opens first.
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.
Technical breakdown
Why node-gyp turns build metadata into execution
node-gyp is the native build tool npm invokes for packages that ship C or C++ add-ons. When it sees binding.gyp, it reads the file and processes build instructions before compilation. That means the file is not just descriptive metadata. It can drive commands, conditional logic, and file inclusion as part of the install flow. Security teams often assume only package.json scripts can execute at install time, but native-module packages expand the attack surface into build configuration that many scanners treat as low risk.
Practical implication: Treat any package with binding.gyp as install-capable code and review its build path with the same suspicion applied to lifecycle scripts.
Command expansion and eval() make the file more dangerous than it looks
GYP supports command expansion tokens such as <!(...) and related forms that execute shell commands while the file is being parsed. The article also shows that binding.gyp is parsed through Python eval() with stripped builtins, which creates an additional sandboxed expression path that can still be escaped. The critical point is that these behaviours happen at parse time, before any source compilation, so a malicious payload can hide inside values that look like harmless build settings.
Practical implication: Scan for command expansion syntax and arbitrary Python expressions anywhere in gyp content, not only in expected build keys.
Includes, actions, and rules extend the trust boundary
binding.gyp does not have to hold the payload alone. Included files, auto-included config.gypi files, dependency-linked gyp files, and home-directory includes can all carry executable content into the build. The same is true for actions, rules, and postbuilds, which are documented command-running features rather than tricks. This makes the trust boundary much wider than a single manifest: one package can pull in execution through several files and several stages of the native build process.
Practical implication: Inventory all gyp-linked files and treat included or auto-included build inputs as part of the package's executable attack surface.
Threat narrative
Attacker objective: The attacker wants to execute code during dependency installation so it can steal secrets and spread through trusted package distribution paths.
- Entry occurs when a compromised package lands in the dependency tree and npm detects a binding.gyp file during install.
- Credential access follows because the malicious build path runs before user code and can reach cloud credentials, CI tokens, SSH keys, and similar secrets on the host.
- Impact is install-time secret theft and worm propagation, with the package executing quietly while the build appears normal.
Breaches seen in the wild
- Miasma and Hades Supply Chain Worms: Self-propagating supply chain worms Miasma and Hades compromise npm, PyPI, and Azure credential stores.
- coa and rc npm hijacks 2021: A compromised npm developer account pushed password-stealing versions of coa and rc, packages with 23 million weekly downloads.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
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.
The real failure mode is hidden authority in trusted build tooling: binding.gyp is dangerous because npm and node-gyp are expected to process it during normal installs. That makes the malicious path blend into legitimate package behavior, which is exactly why supply-chain malware keeps finding it effective. The practical conclusion is that trust in the toolchain must be bounded by inspection of all install-time execution paths, including build files and includes.
Secret exposure during install is an NHI governance problem, not just malware detection: the article explicitly lists cloud credentials, CI tokens, and SSH keys as targets reachable before application execution starts. That means service credentials and developer credentials share the same exposure window when install-time code runs. Identity teams should align package controls with NHI secret governance because the compromise often begins before runtime controls can intervene.
Install-time execution has become a credential theft pattern: the Miasma campaign shows that attackers are no longer relying only on obvious postinstall hooks. They are moving into build semantics, sandbox escapes, and auto-included files to preserve quiet execution. That shifts the defender's job from script review to detection of unexpected build-time behaviour across the dependency lifecycle.
Recursive build parsing creates a persistence-friendly trust gap: includes, transitive includes, and automatically loaded gypi files let malicious logic sit several files away from the manifest a reviewer opens first. The practical implication is that any package audit workflow that cannot follow file inclusion chains is blind to a meaningful class of supply-chain abuse.
What this signals
Install-time execution is now part of dependency governance: package risk can no longer be assessed by lifecycle scripts alone, because native build files can run code during install. Security and platform teams need controls that inspect build metadata, transitive includes, and auto-loaded gyp inputs as part of supply-chain hygiene.
Build-time authority and secret governance now overlap: when a package can execute before application startup, any local NHI secrets on the host become part of the threat model. That makes developer workstations and CI runners a governance boundary, not just an endpoint or build concern.
For practitioners
- 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.
- Inventory all auto-included build inputs Map included gyp files, dependency-linked gyp files, and any home-directory includes that node-gyp may load automatically during install.
- Gate installs on secret exposure risk Where packages can execute at install time, assume local cloud credentials, CI tokens, and SSH keys are reachable and isolate installation environments accordingly.
Key takeaways
- binding.gyp creates a hidden execution path in npm installs, so package review must extend beyond package.json.
- The attack matters because install-time code can reach cloud credentials, CI tokens, and SSH keys before application logic runs.
- Native build files, includes, and parse-time expansion syntax are the controls teams need to inspect if they want to reduce this risk.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article shows install-time code stealing cloud, CI, and SSH secrets from package environments. |
| NHI-03 — Vulnerable Third-Party NHI | Compromised packages and included files function as third-party machine identities in the supply chain. | |
| NHI-07 — Long-Lived Secrets | The article's secret theft impact is amplified when exposed credentials remain usable after install. | |
| Recommendation — Scan install paths for secret leakage and revoke any credential exposed during package execution. Vet third-party package trust paths as NHI dependencies and block unreviewed execution surfaces. Shorten credential lifetime for build hosts and rotate any secrets reachable during dependency installation. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The campaign uses install-time execution to harvest credentials and spread through trusted package paths. |
| Recommendation — Map install-time payloads to credential access and lateral movement techniques in detection coverage. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Credential lifecycle control is central when install-time code can access tokens and keys on the host. |
| Recommendation — Apply IA-5 to rotate and revoke secrets that may be exposed during package installation. | ||
Key terms
- Build-Time Code Execution: Build-time code execution occurs when a package install or build process runs commands before the software is fully installed. This is risky because dependency fetches, lifecycle scripts, and helper tools can execute with developer or root privileges. It turns ordinary package management into a potential host compromise path.
- Build Metadata: Build metadata is information embedded into a compiled binary that identifies how the program was built, often including a version string or git commit. It gives runtime software a way to report its own identity without hardcoding that data separately. When present, it supports update checks and supportability.
- Command expansion: A gyp feature that runs a command and substitutes the output into the build file. It is intended for build-time flexibility, but in hostile packages it becomes a direct execution primitive that can hide shell activity inside otherwise ordinary-looking configuration values.
- Transitive Include Chain: A sequence of files pulled in by direct or indirect includes during parsing. Security risk increases when malicious logic can hide several files away from the manifest, because a shallow review misses the actual execution path.
Deepen your knowledge
NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is designed for practitioners who need a governance lens on secrets, privilege, and machine identity risk.
Published by the NHIMG editorial team on August 2, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org