Imperva's Cloud WAF Breach (Aug 2019): A Stolen AWS API Key From an Internal Instance

Retrospective: this article looks back at events from August 2019, written in 2026 with the benefit of hindsight.

In August 2019, Imperva, a security company known for its cloud web application firewall (formerly Incapsula), disclosed a data exposure affecting customers of its Cloud WAF. In October it published details of how it happened.

How it happened

According to Imperva's account, in 2017 the company created a database snapshot for testing as part of a migration to AWS. An internal compute instance that was accessible from the internet contained an AWS API key. In 2018, an attacker obtained that key and used it to access the snapshot. The exposed data included email addresses, hashed and salted passwords, and for some customers API keys and customer-provided TLS certificates.

Why it mattered

The incident combined several common cloud mistakes:

• A long-lived access key stored on a compute instance.
• An internal system exposed to the internet.
• Test data copied from production and left behind.
• Delayed detection — the access occurred in 2018 and was discovered in 2019 after a third party reported it.

As a security vendor, Imperva's breach also raised the question customers ask after every vendor incident: what did they have of ours, and what do we need to rotate?

Lessons in hindsight

• Replace long-lived keys with roles. Compute on AWS should use instance roles, not stored access keys.
• Treat snapshots and backups as production data.
• Remove test copies of production data when projects finish.
• Rotate customer-supplied secrets quickly after a vendor breach — Imperva forced password resets and advised rotating API keys and certificates.

In hindsight

Imperva's transparent post-mortem was praised, and the root causes appear again and again in later breaches. Stored access keys remained a leading cause of AWS compromises through the 2020s.