Mini Shai-Hulud exposes a hard limit in supply chain security: cryptographic provenance can remain valid while the build itself is already compromised. The attack did not forge signatures. It abused legitimate CI/CD execution paths to extract trusted credentials, poison shared build state, and publish malicious npm packages under real identities.
On May 11, 2026, attackers compromised 84 npm artifacts across 42 packages, later spreading to more than 170 packages. The mechanism was not a single exploit but a chain: a GitHub Actions workflow misconfiguration allowed execution of untrusted pull request code, shared cache state was poisoned across workflows, and an OIDC token was extracted from runner memory during execution. The result was direct publishing to npm through legitimate infrastructure, carrying valid SLSA Build Level 3 attestations.
Those attestations were not forged. They were accurate records of what the compromised build system observed. That is the core tension: SLSA provenance describes a build outcome, not the trustworthiness of the environment that produced it.
What changed in Mini Shai-Hulud#
The attack chained three operational weaknesses inside CI/CD systems.
First, untrusted code execution occurred through a pull request from a fork running in a trusted repository context. Second, GitHub Actions cache scope was shared across workflows, allowing poisoned cache entries to persist across runs. Third, the build process exposed an OIDC identity in runtime memory, which attacker-controlled code extracted and used to authenticate publishing actions.
Once combined, these steps allowed attackers to bypass conditional publishing logic entirely. Instead of injecting a fake package, they used the real pipeline to publish malicious artifacts under legitimate identities.
The key outcome is structural: the pipeline behaved correctly from a logging and attestation perspective while failing at isolation guarantees.
How can valid SLSA attestations still fail?#
Valid SLSA attestations can still represent compromised builds when the build platform violates isolation assumptions required by SLSA Build Level 3.
The critical distinction is between verification and execution integrity. SLSA does not assert that a build was safe in a general sense. It asserts that a specific, controlled build process produced the artifact. If the process itself is subverted, the attestation remains valid but semantically misleading.
Definition: SLSA (Supply-chain Levels for Software Artifacts) Build Levels define progressively stronger guarantees for build integrity, focusing on provenance, isolation, and resistance to tampering inside CI/CD systems.
At Build L2, provenance binds artifacts to source repositories and build systems. At Build L3, the model tightens: build platforms must enforce strong isolation so that builds cannot influence each other, access signing secrets, or persist state across runs.
In Mini Shai-Hulud, these assumptions fail in sequence: cache poisoning violates cross-build isolation, OIDC token extraction violates secret containment, and workflow reuse of shared state violates build determinism.
The result is structurally consistent provenance attached to a structurally compromised execution environment.
What to check in build pipelines#
Security review shifts from signature validation to pipeline architecture.
Focus areas are not optional hardening. They define whether provenance has meaningful trust value.
| Control area | SLSA L2 reality | SLSA L3 requirement |
|---|---|---|
| Cache isolation | Shared or weakly scoped caches across workflows | Per-build isolation, no cross-run contamination |
| Secret exposure | Tokens accessible during build runtime | Signing identities inaccessible to build steps |
| Build influence | Prior runs can affect future runs | No persistence or cross-build influence |
| Attestation meaning | Records build execution truth | Requires controlled, non-interferable execution |
This separation explains why valid provenance did not stop the attack: L2 ensures traceability, not isolation.
Operationally, the failure mode is common in modern CI/CD systems: convenience features like shared caching and ambient identity tokens increase speed while expanding the trusted computing base.
Reference material expands on this boundary problem between signed artifacts and execution integrity: https://gigatap.top/en/articles/openssfs-april-signal-make-security-artifacts-operational, https://gigatap.top/en/articles/100-package-test-coverage-is-the-point-not-the-slogan
What not to overclaim#
SLSA does not fail as a concept. It fails when treated as a complete security boundary instead of a layered assurance model.
A valid attestation should be interpreted as: “this artifact was produced by a declared pipeline”. It should not be interpreted as: “this artifact is safe or untouched by runtime compromise.”
The gap between these two interpretations is where the Mini Shai-Hulud attack operates.
Open source security programs that treat provenance as a final guarantee ignore the execution layer entirely. That produces false confidence in environments where CI/CD systems are dynamically executing untrusted code.
Further framing on layered dependency assumptions is discussed here: https://gigatap.top/en/articles/open-source-security-needs-more-than-code
FAQ#
Why didn’t SLSA Build Level 3 stop this attack completely?#
Because many real-world CI/CD systems labeled as “L3-like” still violate isolation properties in practice. If caches, tokens, or shared runners are accessible across build boundaries, L3 guarantees are not actually enforced.
Does valid provenance mean a package is safe?#
No. It means the package came from a specific build process. If that process is compromised, provenance accurately documents a compromised outcome.
What is the main operational fix?#
Enforce strict build isolation: per-build caches, non-accessible signing secrets, and elimination of cross-run influence in CI/CD execution environments.
Is dependency confusion related to this attack?#
Only partially. Dependency confusion is solved at SLSA L2. Mini Shai-Hulud exploits a deeper layer: runtime and build platform integrity, which requires L3 controls.
What changed in perspective#
The security boundary moved. The relevant question is no longer whether an artifact is signed, but whether the system that produced it could have been influenced mid-execution.
Provenance without isolation becomes a record of compromise rather than a shield against it.