SLSA Build Level 3 was supposed to be the strong verification standard. If your package carried a valid Level 3 attestation, the build provenance was supposed to be trustworthy. The Shai-Hulud/Megalodon attack, per the Cloud Security Alliance’s formal post-mortem, demonstrates that this assumption is now documented as exploitable.
Per the CSA report, Wave 1 (“Mini Shai-Hulud”) compromised 172 npm and PyPI packages across 404 malicious versions. Named packages reported to be affected include the official Mistral AI SDK (`mistralai==2.4.6`), TanStack, Guardrails AI, and UiPath. For context: if your team uses the Mistral Python SDK, TanStack query libraries, or Guardrails AI in any pipeline that was active during the Wave 1 window, audit your dependency lockfiles now. Don’t wait for your next scheduled review.
The SLSA exploit is the finding that changes the conversation. Per the CSA post-mortem, the attackers compromised a legitimate build pipeline, they didn’t forge external signatures. They generated valid SLSA Build Level 3 provenance attestations from inside a hijacked build system. That’s a category shift. Previously, SLSA attestation bypass meant detecting a forgery. Now it means detecting a compromised pipeline that still produces technically valid attestations. The verification toolchain hasn’t changed. The threat model has.
Wave 2 escalated further. Per the CSA report, 5,718 malicious commits were pushed to 5,561 GitHub repositories in under six hours. That velocity, roughly one repository per four seconds, suggests an automated campaign with pre-staged access, not manual exploitation. The scale and speed together indicate a level of infrastructure investment beyond opportunistic attack.
Immediate Security Actions, Shai-Hulud/Megalodon
- Audit dependency lockfiles for mistralai==2.4.6, TanStack, Guardrails AI, UiPath
- Reassess SLSA Build Level 3 attestation as standalone trust signal
- Audit Claude Code and VS Code environments active during compromise window
- Review CI/CD pipeline access logs for Wave 2 window (6-hour commit flood)
The persistence risk
The CSA post-mortem flags that persistence hooks may exist in Claude Code and VS Code if either tool was active during the compromise window. If you run either tool against code that was in a compromised repository during the Wave 1 or Wave 2 windows, treat that environment as potentially affected until you’ve audited it.
Why it matters
Our prior coverage on May 16 documented the TanStack attack and the broader three-attack pattern as it was breaking. What the CSA formal post-mortem adds is scope and technical classification. The individual incidents are now confirmed as a single coordinated two-wave campaign. The SLSA bypass is newly classified as a first-documented case. These aren’t incremental updates, they change the required response.
Context
The CSA report places this alongside the Hugging Face pickle attacks from earlier this month and the TanStack compromise as part of an accelerating pattern of AI supply chain targeting. The targets aren’t random, they’re AI developer toolchain components with high install volumes. That’s a selection criterion, not a coincidence.
Warning
The SLSA Build Level 3 bypass documented by the CSA is the finding that changes your trust model, not just your package list. A valid attestation no longer means a clean build if the pipeline itself was compromised. Update your supply chain security assumptions accordingly.
What to watch
The CSA AI Controls Matrix and STAR for AI program will likely incorporate findings from this post-mortem into updated supply chain security guidance. Watch for updates to SLSA specification maintainers’ response to the Build Level 3 bypass documentation, the spec itself may need revision.
TJS synthesis
Security teams need to act on three fronts immediately: audit any pipeline that included `mistralai==2.4.6`, TanStack, Guardrails AI, or UiPath during the compromise window; reassess SLSA Build Level 3 attestation as a sufficient trust signal in isolation; and if Claude Code or VS Code was active against affected repositories, treat those environments as compromised pending investigation. The formal CSA post-mortem gives you the documentation authority to make this case to leadership.