binding.gyp:
the npm install-execution vector that skips postinstall

What happened

On June 26, 2026, an attacker pushed malicious code into four legitimate @immobiliarelabs packages, a vendor whose Backstage plugins are widely used by platform-engineering teams to wire GitLab and LDAP into their internal developer portals. This was not a typosquat, and there was no obvious account takeover notice. The malicious code was injected directly into real, trusted packages and republished across roughly 24 versions inside a single 30-second window. That burst pattern, many versions of several packages all stamped within seconds of each other, is the signature of an automated organization compromise: a stolen publish token or CI credential driving a script, rather than a human cutting a release.

The payload itself is an aggressive but otherwise conventional credential stealer. What makes this incident worth a full writeup is the delivery mechanism. The attacker chose an install-time execution path that sidesteps the single check almost every supply-chain tool depends on: the lifecycle script. Understanding why it works, and why it slipped past detectors broadly, is the useful part.

Affected packages and versions

The versions below were identified as compromised. Search your lockfiles and install logs for any of them.

The technique: execution hidden in binding.gyp

npm packages that ship native code use node-gyp to compile it, driven by a file named binding.gyp. Most engineers treat binding.gyp as inert build configuration, a manifest that lists source files and compiler flags. It is not inert. The GYP build system supports command expansions, written <!(command) and <!@(command), which node-gyp evaluates by running the command and substituting its standard output back into the build graph. Crucially, that evaluation happens while the package is being built, which on npm means during npm install. It is a general-purpose code-execution primitive that lives in a file nobody scans.

We pulled the published tarball from the npm registry and confirmed the carrier. Every trojanized version shipped this binding.gyp:

Read it plainly. When npm builds the package, node-gyp tries to resolve the sources list by running the command inside <!( ). That command is node index.js > /dev/null 2>&1 && echo stub.c: execute the bundled index.js, throw away its output, and if it exits cleanly, echo a throwaway stub.c so the build graph still receives a valid source file and the install does not error. The malicious index.js runs purely as a side effect of "resolving" the build. There is no install, preinstall, or postinstall entry anywhere in package.json. The lifecycle-script surface is completely clean.

The execution sits in the one file everyone trusts, invoked by a tool everyone trusts.

The attack chain

The flow is compact and built to run once per host, quietly, at install time.

What our engine recorded

CyberXYZ ingests every npm publish through a real-time firehose, so the malicious versions were in our data within about a minute of release. They were not flagged at first, for the same reason everyone else missed them: install-time detection was keyed on lifecycle scripts, and there are none here. Every malicious version declared no install, preinstall, or postinstall script, so the usual signal had nothing to fire on.

The right response to a missed technique is not a one-off rule, it is to close the class of evasion. We extended our analysis to read binding.gyp and treat a <!( ) command expansion that runs a bundled script (or chains and redirects) as install-time code execution, the same severity class as a malicious postinstall. Run against the live packages, it produces a clean verdict:

Legitimate native builds are not caught in the process. Real packages use command expansions to resolve include directories, for example <!(node -e "require('nan')") or a pkg-config lookup, and the analysis deliberately ignores those. It fires on a bundled script being executed (node index.js, a shell, a fetch piped to a shell) or on command chaining and redirection, the shapes that signal execution rather than a build-time query.

Indicators of compromise

Supply-chain risk analysis

Mapped to MITRE ATT&CK, the chain spans initial access through exfiltration:

Watch this attack get caught at install time in the companion case study: the @immobiliarelabs Miasma compromise.

How CyberXYZ detects this

This technique defeated postinstall-based detection broadly, and that gap is exactly what our research focuses on. We treat the install-time surface as more than lifecycle scripts:

• binding.gyp as an install hook. We parse binding.gyp and flag any <!(cmd) or <!@(cmd) command expansion that runs a bundled script or chains and redirects, as a high-severity install-execution finding in the same class as a malicious postinstall. Legitimate native-build queries such as <!(node -e "require('nan')") and pkg-config lookups are not flagged.
• Version-burst prioritization. A package publishing many versions in a short window is the organization-compromise signature. Our scanner promotes those bursts to the front of the queue, so a low-traffic but highly targeted compromise cannot be buried under the tens of thousands of routine publishes that arrive every hour.
• Oversized obfuscated payloads. A multi-megabyte single source file is itself anomalous. We flag large, heavily-obfuscated files and bound the analysis spent on them, which also closes a denial-of-service path where a crafted blob stalls a scanner.
• AI-assistant persistence. We flag package code that writes to AI-assistant configuration paths (.claude, .cursor, Copilot instructions, .aider), a persistence vector that, to our knowledge, no detection tooling watched before this campaign.

Recommended actions

Immediate. Identify any installed version of the four affected packages. On any host or runner that installed one, rotate all reachable credentials (cloud, GitHub, registry, SSH) and revoke active sessions. Review AI-assistant config files for tampering.

Short-term. Block install-time code execution in CI by disabling build scripts where native builds are not required (npm ci --ignore-scripts does not stop node-gyp, so gate native builds explicitly), and pin and review any dependency that ships a binding.gyp. Add detection for <!(cmd) expansions to your own tarball review.

Long-term. Treat the package manager as an enforcement point. An install-time firewall that vets and sandboxes packages before they reach a developer or CI, and that watches the full install-execution surface rather than just lifecycle scripts, is the durable answer to evasions like this one.