An unauthorized user obtained access to a Zapier repository “inadvertently” containing customer data. The breach was caused by a simple 2FA misconfiguration on Zapier’s side. The creator of the automation tool of the same name contacted the part of the customer base affected by the leak.
Zapier noticed the leak on Thursday. It denied access for the unauthorized user with immediate effect. The incident, Zapier says, had no impact on its databases, infrastructure or production, authentication or payment systems. However, it does admit that some customers should still be concerned, as the repository accessed was found to contain customer data copied over “for debugging purposes”. Several other repositories had the same issue.
Using real customer data for debugging purposes may simply be easier and faster than having to generate mock data for a test. Nevertheless, it appears to us that exposing such information to any system that doesn’t strictly need it is a terrible idea. Thankfully, it is at least implied to be against Zapier’s own internal guidelines. For some context, mock data is always used when the press is being demoed pretty much any IT system for obvious reasons. Internal testing, on the other hand, may give some a false sense of security about the data used, as would 2FA.
2FA error
The cause of the leak raises many questions. “How could a 2FA error cause someone accessing [Zapier’s] repos?” wonders one online user. In addition, how can sensitive data even end up in a repository where it need not be in the first place?
The latter issue isn’t unique to Zapier. For example, a DevOps Cloud Engineer at AWS in 2020 leaked personal documents as well as passwords and cryptographic keys for various AWS environments. Fortunately, an external security researcher arrived on the scene within half an hour and contacted the hypersclaer, meaning the breach was contained within a very short space of time.
Since we only hear about the times these things do go wrong, we can’t really say that breaches like these are a dime a dozen in the daily lives of IT teams. To put it bluntly, there’s just so much data to protect and only so many human errors that safeguards can defend against. But in such situations, 2FA/MFA should be a reliable protector for just about every employee. It’s unclear how 2FA was misconfigured on Zapier’s end. Possibly, the account did not belong to any single employee, but instead constituted a test account. Often enough, these accounts go missing and stay active. It may also be the case that a user had not set up 2FA correctly, allowing a single compromised device to provide both authentications required for sign-on.
Either way, it is a reminder to all to both keep track of and safely dispose of test accounts as well as adhering to [proper MFA practices. This will always be an uphill battle. It may end up costing Zapier customers in the end, should any client already be thinking about switching to one of its many alternatives.
Customer data in repository
Finally, IT vendors like to minimize the impact of any incident. Zapier, in this case, is no different. For example, it talks about “isolated instances” of finding repositories in which customer data had been found, which Zapier said were checked “out of an abundance of caution.” That last part is pertinently untrue: if your “abuntantly cautious” check leads to a discovery of this kind, you weren’t abundantly cautious at all. Rather, the company finally fixed something that had been going wrong for an unknown period of time. Checking every system to prevent further trouble is just plain common sense.
Granted, the email to customers (shared in its entirety by The Verge ) is indeed clear and easily discernible. It seems that any Zapier customer affected by the incident can see exactly what data was exposed to the leak. Anyone can contact the automation tool’s team to work out issues.
Also read: Cyber attacks in 2025: SaaS is a blind spot, China advances