What Happened
Between late 2024 and early 2025, attackers compromised 57 npm packages using a technique that bypasses common security controls. Instead of hiding code in lifecycle scripts like preinstall or postinstall, the attackers placed their payload in binding.gyp files—configuration files that node-gyp reads when compiling native addons.
The malware steals credentials from your development environment during npm install, exfiltrates them to attacker-controlled GitHub repositories, then uses those credentials to publish more infected packages. StepSecurity first reported the campaign; Snyk is tracking hundreds of malicious versions across the affected packages.
Timeline
Here's what we know about the attack timeline:
- Initial compromise: Attackers accessed maintainer accounts for legitimate npm packages.
- Payload injection: Malicious binding.gyp files were added to package distributions.
- Propagation phase: Stolen npm tokens were used to publish new malicious versions and compromise additional packages.
- Detection: StepSecurity identified the campaign and published their findings.
- Current status: 57 confirmed affected packages; Snyk is tracking ongoing malicious publications.
The attack likely ran undetected for weeks or months. Your security tools that scan package.json scripts would not have flagged these installations.
Which Controls Failed or Were Missing
Lifecycle script monitoring: Most package security tools focus on detecting suspicious code in package.json lifecycle scripts. This attack executed during the compilation phase triggered by node-gyp, which reads binding.gyp to determine build steps. Your CI/CD pipeline likely logs npm install output but doesn't parse binding.gyp files for malicious commands.
Credential scope limitations: The stolen npm tokens had permissions to publish packages. If your team uses personal access tokens or automation tokens without scope restrictions, a single compromised developer machine can lead to a supply chain compromise across your entire package ecosystem.
GitHub traffic allowlisting: The attackers exfiltrated credentials to GitHub repositories. Your egress filtering probably allows all traffic to github.com without distinguishing between legitimate repository access and data exfiltration to attacker-controlled repos.
Native addon compilation oversight: When node-gyp runs, it executes arbitrary shell commands specified in binding.gyp. Your build environment likely allows this by default—it's necessary for legitimate native modules. But you probably don't have runtime monitoring that distinguishes between "compile this C++ code" and "curl credentials to an external server."
What the Relevant Standards Require
NIST 800-53 Rev 5 SR-3 (Supply Chain Controls): Requires organizations to "employ [Assignment: organization-defined controls] to protect against supply chain threats to the system, system component, or system service." The control enhancement SR-3(1) specifically addresses diverse supply sources and suppliers. Your binding.gyp scanning gap represents a failure to protect against known supply chain threat vectors.
PCI DSS v4.0.1 Requirement 6.3.2: States that "security vulnerabilities are identified and addressed" with specific mention of "bespoke and custom software." If you process payment data and use npm packages in your build pipeline, you must identify malicious code execution vectors—including those triggered during native addon compilation.
ISO/IEC 27001:2022 Control 8.31 (Separation of development, test and production environments): Requires logical or physical separation. If your development machines with npm credentials can reach production systems or publish production packages, a credential theft during npm install can propagate directly to production deployments.
OWASP ASVS v4.0.3 Section 14.2 (Dependency): Requires that "all components, libraries, and frameworks come from trusted sources, over secure channels, and are maintained." The binding.gyp vector shows that "trusted sources" must include runtime analysis of build-time behavior, not just static analysis of declared scripts.
Lessons and Action Items for Your Team
Audit your dependency security tooling. Run this test: Create a test package with a malicious binding.gyp file that echoes "SECURITY_TEST" during installation. Install it in your CI/CD pipeline. Did your security tools flag it? If not, you have the same blind spot that allowed this attack to spread.
Implement binding.gyp inspection. Add a pre-installation check that parses binding.gyp files for suspicious patterns: curl commands, wget, base64 encoding, external network calls, credential access patterns. This requires custom tooling—commercial solutions don't cover this vector yet. Start with a simple grep for common exfiltration commands in any binding.gyp files in your node_modules.
Scope your npm tokens. Use automation tokens with publish-only access to specific package scopes. Never use personal access tokens in CI/CD. If you publish packages, create separate tokens for each package with no read access to other packages. The NIST 800-53 Rev 5 AC-6 (Least Privilege) control requires this level of access restriction.
Monitor GitHub traffic patterns. Your SIEM should alert on POST requests to GitHub repositories from build servers, especially to repos outside your organization. The attackers used GitHub as a C2 channel because it blends with legitimate traffic—but your build servers probably shouldn't be creating issues or uploading files during package installation.
Isolate build environments. Your npm install process should run in a container or VM with no access to production credentials, no ability to publish packages, and network egress limited to package registries. Use separate credential stores for development, testing, and production. This implements ISO/IEC 27001:2022 Control 8.31.
Review your package publishing workflow. If you maintain npm packages, require MFA for all maintainer accounts and use dedicated publishing infrastructure with audit logging. The self-propagating nature of this attack means one compromised maintainer account can cascade across your entire package ecosystem.
The binding.gyp vector will not be the last novel supply chain attack technique. Your security posture must extend beyond scanning the obvious hooks to analyzing actual runtime behavior during installation and build phases.
