Report: Zapier trustworthiness after the Shai-Hulud npm supply-chain attacks

Overview

This report examines whether Zapier remains a trustworthy vendor after being caught up in the Shai-Hulud / Sha1-Hulud npm supply-chain attacks in 2025. It pulls from independent security research, vendor advisories, and Zapier’s own security posture disclosures.

The core issues:

• What actually happened to Zapier’s npm ecosystem presence during Shai-Hulud.
• What the impact and blast radius were for downstream users.
• How Zapier’s overall security and trust posture look in light of this and prior incidents.
• Where the main residual risks lie if you continue (or start) to use Zapier.

Throughout, “Shai-Hulud” refers to the self-propagating npm worm that hijacked maintainer accounts and published trojanized packages which steal credentials and spread further.

Was my org impacted by Zapier’s Shai-Hulud npm packages?
How do we harden CI/CD against npm worms like Shai-Hulud?

---

1. What happened to Zapier in the Shai-Hulud incident?

1.1 Nature of the campaign

Security vendors and CISA describe Shai-Hulud / Sha1-Hulud 2.0 as a large-scale npm supply-chain campaign:

• A self-replicating worm compromises maintainer accounts, injects malicious preinstall/postinstall scripts, scans environments for secrets using tools like TruffleHog, then exfiltrates those secrets to public GitHub repos labelled “Sha1-Hulud: The Second Coming”.¹²
• CISA notes 500+ npm packages compromised, with the malware harvesting GitHub, npm, AWS, GCP, and Azure credentials before propagating to more packages.[^cisa-scale]³
• Multiple analyses emphasise that this is worm-like and self-propagating, not a one-off package typosquat.⁴⁵

Researchers highlight this as one of the most consequential incidents in the npm ecosystem, impacting critical tools with an estimated 132M+ monthly downloads.⁶

1.2 Direct impact on Zapier

Several independent sources explicitly name Zapier as one of the high-profile ecosystems compromised:

• Wiz, StepSecurity, BleepingComputer, CyberScoop, and others all report that Zapier-maintained npm packages were trojanized along with those from ENS Domains, PostHog, Postman, and others.[^wiz-compromise][^stepsecurity-wave2]⁷⁸
• Security reporting states that Zapier’s npm account was successfully compromised, allowing an attacker to publish malicious versions across hundreds of Zapier-related packages.⁹¹⁰
• Named affected artifacts include packages such as @zapier/ai-actions-react (versions 0.1.12–0.1.14) and zapier-platform-schema (versions 18.0.2–18.0.4).¹⁰

The end result: malicious Zapier npm releases existed in the public registry and could be pulled into:

• Developer machines and build agents.
• CI/CD pipelines.
• Downstream projects that transitively depend on Zapier’s tooling libraries.

1.3 Technical behaviour of the malicious Zapier-related packages

The malicious versions followed the same campaign pattern seen across the ecosystem:

• Execution via npm lifecycle hooks – the trojanized packages included preinstall/postinstall scripts that automatically executed when the package was installed.¹¹¹²
• Credential harvesting – once running, payloads:
  • Dumped environment variables (including API keys, tokens, cloud credentials).
  • Used TruffleHog to scan the filesystem and git history for secrets.¹¹³
  • Queried AWS/GCP/Azure metadata endpoints to harvest additional cloud credentials when possible.¹⁴³
• Exfiltration and worming – the malware:
  • Validated harvested credentials and used them to authenticate to npm and GitHub.
  • Created or populated GitHub repos with stolen secrets, using “Shai-Hulud” wording in descriptions.¹⁵¹⁶
  • Used valid npm tokens to push new compromised versions of other packages, enabling lateral spread across maintainers’ portfolios.¹⁷¹⁸

For Zapier, the critical security point is that an attacker was able to publish code under Zapier’s namespace that executed credential-theft logic when consumers installed it.

Which Zapier npm packages/versions are considered safe now?

---

2. Blast radius and risk to downstream users

2.1 Scale in the ecosystem

The overall Shai-Hulud campaign had extremely broad reach:

• Researchers estimate 500–600+ impacted npm packages in the later wave alone, with tens of thousands of GitHub repos and more than 25,000 downstream repos affected.¹⁹[^betterstack-scale]²⁰²¹
• Several of the impacted libraries (not just Zapier’s) had millions of weekly downloads, meaning the worm had access to a very large potential install base.²²⁵

Zapier’s specific portion of that blast radius is harder to quantify publicly, but security writeups consistently group it in the “major ecosystem vendor” category rather than a fringe victim.

2.2 What was at risk for Zapier consumers?

Using the compromised Zapier npm packages did not directly mean Zapier’s SaaS product leaked your data, but it did mean:

• Developers and build systems that installed those packages were exposed to:
  • Theft of GitHub PATs, npm tokens, SSH keys, and cloud keys (AWS/GCP/Azure).³¹⁴
  • Potential wiping of the user’s home directory in some failure branches when the malware couldn’t authenticate, increasing operational risk.²³
• Stolen secrets could then be used to access:
  • Other private repos (including downstream apps that integrate with Zapier).
  • Cloud infrastructure where those keys were valid.
  • Additional package-maintainer accounts, propagating the infection.

If your organisation uses Zapier’s npm tooling in CI/CD or local dev, the security risk is on your side of the trust boundary, but Zapier’s compromised account was one of the vehicles that delivered that risk.

2.3 Independent guidance for organisations using affected Zapier packages

Multiple security advisories not specific to Zapier but directly mentioning Zapier’s packages recommend that all organisations that might have installed any compromised packages do the following:

• Immediate incident-style response: treat this like a credential-stealing breach, not just a dependency mismatch.
• Uninstall / pin / roll back to known-good versions, and temporarily freeze adoption of new npm packages until impact is assessed.²⁴²⁵
• Rotate all possibly exposed secrets (npm, GitHub, and all cloud provider tokens) discovered on infected machines or build agents.[^cisa-rotate][^fortiguard-remediate]
• Audit CI/CD and workflows for inserted backdoors, including suspicious GitHub Actions/workflows that could run arbitrary commands.[^endor-backdoor][^semgrep-discussion]
• Deploy or tighten secret scanning and SBOM/dependency tracking to detect similar events in future.²⁶²⁷

For you as a Zapier customer or integrator, the main practical question is not just “is Zapier trustworthy?” but “has my own supply chain done the work to respond properly?”

Zapier/Shai-Hulud incident checklist for internal security teams

---

3. Zapier’s broader security posture and history

To judge Zapier’s trustworthiness, we need to zoom out beyond this single npm account compromise.

3.1 Existing security controls and certifications

Zapier publishes relatively detailed security documentation:

• Zapier states that it uses TLS 1.2+ in transit and AES-256 at rest for customer data.²⁸
• The company holds SOC 2 Type II and SOC 3 attestations from independent auditors, with reports available through the Zapier Trust Center.²⁹³⁰
• Zapier describes:
  • Mandatory password manager and audits for password strength and reuse.
  • Wide use of SSO and 2FA to gate access to important internal services.³¹
  • Ongoing threat detection tooling and “continual threat modelling exercises” to identify and plan for vulnerabilities.³²
• Zapier asserts that it audits third-party vendors at onboarding and periodically, ensuring adherence to privacy regulations and execution of Data Processing Addendums (DPAs).³³³⁴

External scoring and monitoring:

• UpGuard maintains a vendor risk report on Zapier, based on continuous monitoring of its exposed attack surface and threat intelligence feeds.³⁵
• While exact numeric scores are outside the scope of this summary, the existence of such continuous monitoring is a positive signal that large customers can verify independently.

3.2 Use of advanced detection stacks

A case study with Panther Labs shows that Zapier invests in a reasonably mature detection pipeline:

• Zapier’s security team replaced manual triage with proactive detection using Panther, creating custom detection rules and leveraging built-in content to get broad coverage.³⁶
• The case study claims Zapier achieved comprehensive threat coverage, faster response, and fewer false positives, with an estimated $400k/year savings in security operations costs.³⁷

This doesn’t guarantee perfect security, but it indicates Zapier runs a modern, SOC-like detection stack rather than minimal logging.

3.3 Prior code-repository incident (2FA misconfiguration)

Separate from Shai-Hulud, Zapier has publicly disclosed at least one other relevant security incident:

• A notice reported by press indicates that due to a two-factor authentication misconfiguration on an employee account, an attacker gained unauthorised access to certain Zapier code repositories.³⁸
• Commentary notes that 2FA should normally provide strong protection, and that misconfiguration here is a warning for Zapier and other SaaS vendors about operational rigor around MFA.³⁹

This history matters because Shai-Hulud exploited credential and token theft in developer and CI/CD environments. The combination of:

• an earlier 2FA misconfiguration incident, and
• a later compromise of Zapier’s npm maintainer tokens

suggests that Zapier’s developer-access controls and token hygiene have been non-trivially tested in real-world attacks.

---

4. Evidence in favour of Zapier still being a trustworthy vendor

This section pulls out arguments and evidence pointing toward “Zapier is still a vendor you can reasonably trust, with caveats.”

4.1 Transparency and documentation

• Zapier maintains a public security & compliance page and Trust Center that expose SOC reports, security whitepapers, pen-test summaries, and key policies.³²³⁰
• The Trust Center runs a self-service model where customers can request SOC 2 Type II details and review FAQs about security practices.⁴⁰
• Public incident reporting (e.g., the 2FA misconfiguration/code-repo access incident) indicates at least some willingness to communicate issues rather than bury them.³⁸

4.2 Strong baseline controls for the core SaaS

For the core Zapier platform (not npm tooling):

• TLS and AES-based encryption are standard for serious SaaS vendors; Zapier explicitly documents these controls.²⁸
• Audited SOC 2 Type II and SOC 3 provide external validation of controls over a multi-month period, not just point-in-time.
• Documented vendor vetting, DPAs, and GDPR-aligned privacy language indicate maturity in data-handling governance.³³³⁴

These controls don’t prevent npm token theft, but they do matter for the trustworthiness of Zapier as a data processor once data is inside their SaaS.

4.3 Investment in security operations and threat detection

• The Panther case study paints a picture of a security team that is:
  • Proactive in detection engineering.
  • Consolidating logs and using detection rules to catch anomalies across infrastructure.³⁶
• Zapier also positions itself in its own content as an automation provider that can be used to automate security workflows (e.g., alerting, identity verification), which tends to go hand-in-hand with internal automation of security processes.⁴¹

While marketing material has to be taken with caution, the combination of a modern SIEM/detection stack and SOC attestations suggests baseline operational competence rather than a “no-security-team” scenario.

4.4 Market position and continued large-enterprise usage

External analyses describe Zapier as:

• A leading no-code/low-code automation platform connecting 6,000–7,000+ apps as of 2023–2025.⁴²⁴³
• A platform where large enterprises rely on its stability and support, particularly for automation and AI workflows.⁴⁴⁴⁵

Large, risk-sensitive customers typically demand security reviews, SOC reports, DPAs, and sometimes bespoke questionnaires. The fact that Zapier continues to serve that segment post-incident is a soft but non-trivial trust indicator.

4.5 The Shai-Hulud incident in context

Important nuance:

• Shai-Hulud targeted the npm ecosystem as a whole, not Zapier-specific infrastructure. Zapier was one of several major ecosystem maintainers compromised.
• The campaign exploited developer credentials and tokens; even organisations with strong SaaS-side controls were vulnerable if their dev environments and CI/CD weren’t locked down against this class of attack.⁴⁶⁴
• Security guidance from CISA and others frames this as an ecosystem-wide wake-up call demanding supply-chain hardening, rather than singling out one or two “reckless” vendors.⁴⁷³

From this angle, Zapier looks more like a prominent victim of a high-end campaign than an outlier of negligence.

How does Shai-Hulud change how we should view Zapier’s supply-chain risk?

---

5. Evidence that should make you cautious about Zapier

There are also serious reasons to treat Zapier as non-zero-risk, especially if your threat model is strict.

5.1 Direct compromise of Zapier’s maintainer account

• The fact that attackers were able to take over Zapier’s npm account and push 400+ malicious package versions is itself a major red flag.⁹¹⁰
• This indicates that, at least at the time of compromise, Zapier’s maintainer credentials and/or tokens were not sufficiently hardened (e.g., use of long-lived tokens, insufficient phishing-resistant MFA, or inadequate segregation of duties).
• In a world where CISA is explicitly telling orgs to treat npm and CI/CD as part of the primary threat surface, this is not a minor misstep; it demonstrates a real gap in software-supply-chain security at a widely-trusted SaaS vendor.⁴⁷⁴⁸

5.2 Repeated developer/credential-related security issues

We now have at least two public data points:

1. A 2FA misconfiguration incident leading to unauthorised access to Zapier code repositories.³⁸³⁹
2. A later npm maintainer compromise in Shai-Hulud.

Both incidents are rooted in identity, access, and token management for engineering staff. That pattern suggests that Zapier’s developer security controls have been lagging attackers and are a critical area to scrutinise in any vendor risk assessment.

5.3 Limited public detail about post-incident remediation

As of the reporting covered in this analysis:

• Third-party advisories (e.g., security vendors) provide detailed guidance for customers on rotating credentials, auditing pipelines, and freezing package updates.²⁴²⁵
• However, there is less public, Zapier-authored technical detail on exactly how Zapier:
  • Hardened its npm publishing workflow (e.g., moving to GitHub “trusted publishing”, hardware-key-only flows, or short-lived tokens).
  • Audited all compromised packages and verified clean baselines.
  • Updated internal policies for developer workstations and build systems.

That does not mean those steps weren’t taken; it means that from the outside, you cannot easily verify the depth of remediation beyond generic security-position statements and high-level documentation.

5.4 Supply-chain concentration risk

Zapier acts as a central integration hub across many of your SaaS tools. From a risk-design perspective:

• If Zapier is compromised at the SaaS level, attackers can potentially move laterally by abusing connected integrations (email, CRM, ticketing, etc.).
• If Zapier’s developer tooling or platform SDKs are compromised (as with Shai-Hulud), the infection path is via your own codebases and infrastructure.

This is not unique to Zapier—it’s true for any central automation platform—but the Shai-Hulud incident is a reminder that high-leverage nodes in your architecture deserve correspondingly high scrutiny and compensating controls.

---

6. Practical risk assessment: “Is Zapier still trustworthy?”

There is no binary yes/no here; instead, you should treat Zapier as a material but manageable risk if you put the right controls around it.

6.1 Reasonable working conclusion

Given the evidence:

• Zapier is not a fly-by-night vendor. It has SOC 2/3, a visible security program, third-party monitoring, and a history of operating at scale for large enterprises.
• The Shai-Hulud incident shows Zapier’s developer and supply-chain security were imperfect, but it was compromised as part of a sophisticated, ecosystem-wide campaign that also impacted other major players.
• There is no strong public evidence (so far) that:
  • Core Zapier SaaS data stores were breached via Shai-Hulud, or
  • Zapier attempted to conceal the existence of security issues entirely.

For many organisations, especially those already using Zapier heavily, a rational stance is:
“Continue using Zapier, but treat it as a high-value integration point and enforce strict guardrails around it, particularly in engineering and CI/CD.”

If your risk tolerance is very low (e.g., regulated critical infrastructure, high-sensitivity government workloads), you may decide that any history of maintainer compromise at this scale is enough to de-prioritise Zapier in favour of vendors with a more transparent post-incident posture.

6.2 Controls to demand from Zapier

When assessing Zapier as a vendor post–Shai-Hulud, your security questionnaire / conversation should dig into:

1. Maintainer and CI/CD hardening

   • Are all npm publishing flows using trusted publishing and/or hardware-key–based MFA only?
   • Are npm tokens short-lived and scoped minimally, with central rotation and revocation?
   • What allows Zapier to assert that previously compromised packages are now provably clean and monitored?

2. Developer endpoint and secret hygiene

   • How are developer workstations monitored for malware and unusual credential exfiltration behaviour?
   • Are secret stores (e.g., cloud keys, PATs) moved off local machines into managed vaults with tight policies?

3. Incident response & transparency

   • Can Zapier share post-incident summaries (even under NDA) for Shai-Hulud and the 2FA misconfiguration event?
   • What specific timeline, root-cause analysis, and lesson-learned actions exist?

4. Customer-facing support for supply-chain incidents

   • Does Zapier provide a clear list of affected npm packages and versions, with safe upgrade paths?
   • Are there dedicated channels (security@, trust center updates) for rapid communication about future supply-chain incidents?

A vendor that can answer these concretely, backed by SOC 2/3 documentation, can still be a reasonable choice even after a serious incident.

6.3 Internal compensating controls if you keep or adopt Zapier

Regardless of Zapier’s posture, you should implement:

• Least privilege for Zapier integrations – use separate service accounts and narrowly scoped API keys for each integration Zapier touches.
• Outbound monitoring from Zapier-connected systems – watch for unusual automation behaviour (mass email sends, CRM modifications, ticket creation) that might indicate integration abuse.
• Strict SDLC hygiene around any Zapier SDK or CLI use:
  • Pin package versions, avoid auto-upgrade in CI.
  • Use SBOM tooling (e.g., CycloneDX-based) to know exactly where Zapier artifacts exist.⁴⁹
  • Run secret scanning and malware detection over build environments regularly.²⁶⁵⁰

---

7. Summary

• Yes, Zapier was materially impacted by the Shai-Hulud npm campaign: its npm account was compromised and hundreds of packages were trojanized to steal credentials and propagate malware.
• The incident sits within a broader ecosystem attack that also struck other major vendors, and there is no public evidence that Zapier’s core SaaS platform suffered a catastrophic customer-data breach via Shai-Hulud.
• Zapier maintains a non-trivial, externally-audited security program (SOC 2/3, trust center, vendor audits, threat detection), which supports an argument that it can still be a trustworthy vendor—provided you recognise its developer/supply-chain security debt and enforce additional guardrails on your side.
• For high-sensitivity environments or organisations with very low risk appetite, the combination of a recent maintainer compromise and past MFA misconfiguration may justify treating Zapier as higher-risk and requiring stronger assurances—or preferring alternatives.

Ultimately, the decision is less about whether Zapier is “good” or “bad” and more about whether its current security posture, plus your own compensating controls, meets your organisation’s risk tolerance.

---

Footnotes

1. Aikido analysis of Shai-Hulud’s behaviour, noting filesystem and environment scanning with TruffleHog and exfiltration to GitHub repos labelled “Sha1-Hulud: The Second Coming”. Source ↩ ↩²

2. Wiz analysis describing exfiltration of secrets to GitHub repos via Shai-Hulud. Source ↩

3. Black Duck on Shai-Hulud’s use of credential harvesting in dev and CI/CD environments.Source ↩ ↩² ↩³ ↩⁴

4. Docker’s write-up on rapid remediation pipelines and the broader Shai-Hulud 2.0 campaign. Source ↩ ↩²

5. StepSecurity describing 22k+ malicious repositories and many impacted packages. Source ↩ ↩²

6. CyberPress calling the Zapier/ENS compromises among the most consequential npm incidents. Source ↩

7. BleepingComputer on hundreds of trojanized packages including Zapier’s. Source ↩

8. CyberScoop on Shai-Hulud’s impact on major vendors such as Zapier, ENS Domains, PostHog and Postman. Source ↩

9. GBHackers describing successful compromise of Zapier’s npm account and hundreds of infected packages. Source ↩ ↩²

10. OX Security list of specific Zapier packages/versions implicated (e.g., @zapier/ai-actions-react, zapier-platform-schema). Source ↩ ↩² ↩³

11. Better Stack description of npm lifecycle hooks (preinstall/postinstall) used to run malicious code during installation. Source ↩

12. Unit 42 description of malicious post-install scripts in Shai-Hulud-compromised packages. Source ↩

13. Semgrep analysis of Shai-Hulud 2.0 and its use of TruffleHog. Source ↩

14. Orca Security description of Shai-Hulud harvesting secrets from environment variables and cloud metadata endpoints. Source ↩ ↩²

15. Ibid., description of public GitHub repositories created under victim accounts. ↩

16. GitLab Vulnerability Research team on public GitHub repos created by the worm. Source ↩

17. CISA description of the worm’s automated propagation via compromised npm accounts. Source ↩

18. Wiz description of trojanized packages from Zapier, ENS Domains, PostHog, and Postman. Source ↩

19. Ibid., on overall package counts and GitHub exposure. ↩

20. FortiGuard threat signal summarising the second-wave attack as compromising ~492 packages and ~25k repositories. Source ↩

21. Snyk summary of “Sha1-Hulud” wave, noting 600+ distinct impacted npm packages. Source ↩

22. Unit 42 on the scale of compromise and inclusion of widely used packages such as @ctrl/tinycolor. Source ↩

23. Aikido notes that when the malware cannot authenticate to GitHub/npm it may wipe files in the user’s home directory. Source ↩

24. OX Security guidance on implementing a cool-down period and organisation-wide reviews for new npm package versions after Shai-Hulud. Source ↩ ↩²

25. Upwind’s checklist for responding to Shai-Hulud, including scanning machines, clearing npm caches, freezing package updates. Source ↩ ↩²

26. Jit’s guidance on integrating secret scanners and other AppSec tools in CI/CD. Source ↩ ↩²

27. Dependency-Track project overview for tracking software components across portfolios. Source ↩

28. Zapier security-compliance page describing TLS 1.2+ and AES-256 encryption at rest. Source ↩ ↩²

29. Ibid., on SOC 2 Type II and SOC 3. ↩

30. Zapier Trust Center overview. Source ↩ ↩²

31. Zapier security controls PDF describing password-manager enforcement, SSO, and 2FA requirements. Source ↩

32. Zapier help article on Security & Compliance, including threat detection and threat modelling statements. Source ↩ ↩²

33. Zapier’s Data Privacy policy describing vendor audits and DPAs. Source ↩ ↩²

34. Zapier’s Data Processing Addendum. Source ↩ ↩²

35. UpGuard vendor risk report for Zapier. Source ↩

36. Panther case study on Zapier transforming security operations from manual triage to proactive detection. Source ↩ ↩²

37. Ibid., estimated annual savings on tooling and incident response. ↩

38. Report of Zapier email to customers about a security incident caused by 2FA misconfiguration on an employee account. Source ↩ ↩² ↩³

39. Techzine commentary on the Zapier 2FA misconfiguration incident. Source ↩ ↩²

40. Zapier article on using the Trust Center to review security practices. Source ↩

41. Zapier content on using automation for security use cases and identity verification. Source ↩

42. Contrary research profile on Zapier as a no-code automation leader. Source ↩

43. Smythos vs. Zapier comparison mentioning thousands of app integrations. Source ↩

44. Intuition Labs article noting that large enterprises rely on Zapier’s stability and support. Source ↩

45. Zapier for Enterprise positioning as a secure AI orchestration platform. Source ↩

46. Phoenix Security analysis positioning Shai-Hulud as a major ecosystem supply-chain breach. Source ↩

47. CISA alert on the npm supply-chain compromise and recommended mitigations. Source ↩ ↩²

48. SecurityWeek commentary emphasising the need to treat npm/CI/CD as part of the main threat surface. Source ↩

49. CycloneDX documentation describing SBOM use cases. Source ↩

50. Gitleaks project documentation. Source ↩