Flox | Mitigating Shai-Hulud Attacks with Hermetic Builds3.7k<br>Sign in

Features

Use Cases

Resources

Pricing

Company

Sign in

Connect

Blog / Engineering<br>Mitigating Shai-Hulud Attacks with Hermetic Builds<br>Flox Team|22 June 2026

Recently, we’ve seen the rise of supply chain worms: malware that spreads throughout the software supply chain by compromising packages, build systems, or developer workflows. During CI/CD, the build environment simultaneously has access to secrets (e.g. API keys) and external services (e.g. GitHub). That combination of secrets access and network access can be exploited to simultaneously exfiltrate secrets and spread the attack by publishing it to other dependencies.

Shai-Hulud campaigns have demonstrated this in the last few months. The original September 2025 Shai-Hulud campaign compromised 500+ npm packages, and follow-on waves have since pushed the total far higher. The worm harvests secrets at build time and then exfiltrates them by committing to remote Git repositories using a token harvested from the compromised environment. Certain variants targeted the CI/CD pipeline to add an install-time lifecycle script (preinstall or postinstall ) that runs during installation, then bump the version and republish.

Agentic software engineering increases this risk because it increases both the volume and the speed of code delivery. Agents that update manifests, modify package scripts, or operate inside authenticated CI/CD workflows can make malicious dependency changes harder to catch and faster to propagate. As agentic workflows become more common, attackers gain more opportunities not only to compromise company secrets, but also to damage a company’s reputation by poisoning public packages published under its name.

Short-lived, least-privilege tokens can reduce the blast radius in the event of compromise. Teams can also limit what CI/CD jobs can access; keep secrets out of build steps that run third-party code; verify that package versions come from trusted source repos/workflows; restrict network egress; and rotate credentials regularly … or immediately after suspected exposure. These are necessary controls, but they still don’t address the crux of the problem: a compromised build can see and use whatever the environment exposes.

An often overlooked strategy is our focus at Flox: reproducible and hermetic build environments. Hermetic build environments won’t prevent attacks like Shai-Hulud, but they will tightly limit the damage. Given that these attacks are continuing to proliferate, organizations should consider switching to reproducible, hermetic environments. Today, we’ll spell out how these environments work in context of supply chain attacks.

Understanding Shai-Hulud

Shai-Hulud exposed the inconvenient truth about modern software delivery: once untrusted code runs inside a credentialed build environment, an attacker inherits that environment’s secrets, privileges, and (not least) network access. They can use this access to publish malicious package versions under a trusted name, transforming a single compromised environment into a distribution channel for malicious code.

Previously, many developer attacks would target the maintainers. They’d try to hijack a developer’s machine and search for sensitive information. Packages that were compromised in this way include eslint-scope and ua-parser-js . They focused on two steps only: harvesting secrets and exfiltrating them by hijacking the maintainer’s publishing credentials.

Recent Shai-Hulud campaigns instead targeted the build environment. The build environment typically has publish access to packages and publish access to repositories. Worms harvest secrets and exfiltrate them; they also clone the exploit into packages, bump the version, and publish an update. Even with 2FA security, developers often haphazardly accept minor version bumps. Unfortunately, that single digit upgrade might contain a serious attack.

Intercom recently fell victim to a variation of this. Version 7.0.4 of intercom-client  contained two malicious files absent from version 7.0.3: setup.mjs  and router_runtime.js . An attacker published the new version using credentials stolen from a compromised developer account. Then, when any downstream project installed the hijacked version, these files ran during installation and exfiltrated secrets from whatever build environment they were running in to the attacker’s GitHub repositories. Those stolen secrets are what let the worm publish the next poisoned package: exactly the self-replication pattern Shai-Hulud was built around.

AI Expands the Attack Vector

This type of attack might appear like a tangential problem with respect to AI. However, AI exponentiates the risk of these types of attacks.

AI agents are actively maintaining codebases. At some companies, agents are even running CI/CD pipelines. Agents are easily manipulated and error-prone: they might easily install an infected package or publish...